благодаря плагину “Automated Log Work for JIRA” автоматически запускается счетчик логирования времени, который останавливается и сохраняет набежавшее значение при переводе задачи в другие статусы
Время логируется так, как-будто программист работает над задачей 24 часа в сутки или есть какие-то условия, что из суток логировать только 8 часов (или что-то подобное)?
Потому что может включать исключение других вариантов, при одновременной демонстрации того, что они имеют бессмысленные последствия, или сравнение с другими языками или другими задачами.
Перечитал два раза, но так и не понял, что тут говорится.
А это общая черта всех подобных статей против БЭМ — громкие слова, общие утверждения и отсутствие конкретных аргументов или примеров. Ну, либо аргументы, вытекающие из недопонимания методологии.
Я поработал в разных командах, и могу сказать, что насколько вредны диктаторские угрозы наказаний, настолько вредно и полное отсутствие какой-либо системы кнута и пряника.
Например, я считаю (из собственного опыта), что вредно давать человеку одинаковую премию независимо от того, как он проработал месяц. Одно время я работал в компании, где фиксированная часть ЗП была постоянной, а премия напрямую зависела от эффективности. И да, я лишался пару раз 30% или 50% премии, но у меня язык не повернется назвать это демотивацией, так как я знал на что шел, когда косячил, знал, что я сам виноват и старался в следующий месяц исправиться. Главное тут, обговорить все заранее, а не сваливать в конце месяца как снег на голову новость об урезании премии.
К сожалению (или к счастью), люди не делятся только на тех, кто «тянет» или «не тянет». Есть хорошие специалисты, которые отлично «тянут», но если видят в команде отсутствие дисциплины и атмосферу полной вседозволенности, то постепенно начинают расхолаживаться и забивать.
Много букав, а по сути тема так и не раскрыта.
Так как правильно наказывать то надо? Почему-то написано только очевидное, что и так всем понятно — «увольнение — крайняя мера», «не надо наказывать деньгами». Но ни одного конкретного примера, как наказывать/поощрять/мотивировать.
Наказывать только путем «серьезных разговоров»? Это не работает — если люди знают, что дальше разговоров никогда ничего не идет, на них это не действует.
Ну вот. Из этого вывод, что если у тимлида на кодинг остается всего 30% (к примеру) от всего рабочего времени, это никакая не проблема, а просто особенность должности. И к этому надо быть готовым — не каждый программист хочет расти в таком направлении.
К счастью, я еще не встречал команд, где обычных разработчиков выдергивают каждый день на 3 часа на митинги) Это, должно быть, очень богатые компании, если могут себе такое позволить =)
По поводу тимлида, штука вот в чем (из статьи):
тимлид — интерфейс команды разработки
То есть, главное — это донести до команды задачу, правильно распределить ее между программистами и обеспечить выполнение, а не стараться отгородиться от всего, лишь бы сидеть и самому заниматься имплементацией.
Хорошо, сегодня тимлиду удалось оптимизировать митинги внутри компании, сократив их время на 50%, а завтра появятся подрядчики, с которыми тоже нужно проводить митинги. И тимлид закроет свою IDE и пойдет это делать. Потому что управление для него приоритетней, чем непосредственно программинг.
Вот тут как раз субъективизм — Вам из статьи это показалось наиболее значимым, а мне
Например для себя я определил правило, что тимлид, в командах разработки, обязательно должен принимать непосредственное участие в разработке, то есть писать код, разрабатывать архитектуру и т.п. Это нужно для того, чтобы понимать как устроена система изнутри, без непосредственного участия в разработке такое понимание постепенно сходит на нет.
То что вам показалось значимым — это как раз пример дополнительных обязанностей, который привел автор статьи. Из того же абзаца (никакого субъективизма, все из статьи):
… это то, что тимлид взваливает на себя добровольно (или принудительно) дополнительно…
… согласно рассуждениям выше, непосредственная разработка не входит в число родных обязанностей тимлида, в некоторых проектах она может быть необоснованна.
То что вам удается обходиться 15% времени на менеджмент — это замечательно. Но, если команда состоит из средненьких программистов, среди которых есть люди с проблемным характером, да еще и руководство компании непростое и любит долгие совещания (и на каждое дергает тимлида), плюс добавим кучу мелких администратвных дел, которые могут быть повешены на тимлида, то тут хорошо, если хотя бы 40% времени останется на непосредственно программирование.
Не даром же на западе в некоторых командах есть отдельно технический лидер (который полностью отвечает за техническую сторону, архитектуру) и тимлид (который больше менеджер).
Ваш личный опыт прочесть было интересно, но я думаю, сколько людей, столько и мнений.
Ну и странный же вывод. Если бы вы внимательно прочитали статью, то увидели бы — там описано, что основная обязанность тимлида именно управлять командой. А непосредственно программирование — это второстепенно. А управление — это менеджмент. Не знаю, что тут может быть непонятно.
Дело в том, что из-за отсутствия четкого понятия, что же такое тимлид, куча народу считает, что это высшая форма программиста. На самом деле, в команде могут быть программисты, которые сильнее тимлида, но все эти управленческие заботы им даром не нужны.
И самые важные качества тимлида (судя по статье) — организаторские способности, умение завоевать авторитет, способность брать ответственность на себя, умение выстроить отношения с командой, коммуникабельность — не связаны непосредственно с программированием — это менеджерские качества.
+1 к вопросу в комментарии выше. Если мне чуть больше 25 лет, я программировал на Python X лет (я даже не из другой профессии), но последний год серьезно стал интересоваться Java, что во мне не так?
Большинство моментов в статье точно подмечены, но, читая некоторые, я недопонимаю, причем тут технический лидер. Разве обязанностью технического лидера является следить за финансами, расчетами с подрядчиками, а также решать вопросы с болезнями, опозданиями, отпусками членов команды, разруливанием конфликтов, личными проблемами? Разве это не менеджер проекта должен делать?
Так это не я, а вы предлагаете использовать вместо модификаторов каскады из вложенных селекторов (которые по вашему мнению удобнее) для модификации свойств. У меня то нет проблем.
Я говорю не о том, чтобы отказаться от ангуляра, а о том, что не надо бездумно менять классы в HTML-коде, даже не проверяя, что на них завязано в js, а потом удивляться, почему все сломалось. И просто привел ссылку, что на этот счет говорит официальная документация.
Нет, это не абсолютно другая кнопка, это абсолютно та же кнопка. И вместо кнопки может быть целый независимый блок. И я не хочу писать в нескольких местах стили для одного и того же блока.
Насчет завязывания логики на классах — я бы вообще не рекомендовал завязывать поведение на модификаторах, которые обозначают свойства вроде цвета или размера. Кроме того если разрабатывать с использованием инструментов, которые предоставляет Яндекс, то там прямо в документации говорится, что нельзя вот так брать и напрямую менять модификатор на DOM-ноде.
Причем тут глобальные стили? Грубый пример — есть кнопка, которая на странице A зеленая, если родительский элемент — div, и красная, если родительский элемент — span. Если я захочу сделать такую же _красную_ кнопку на странице Б в table, то мне либо придется следовать изначальной структуре (помещать ее в span), либо дублировать код стилей. С БЭМ у меня есть конкретный модификатор, который будет работать хоть в div, хоть в span, хоть в table. Насчет скорости — не вижу ничего смешного в том чтобы терять даже 500-100ms на ровном месте.
Также не буду говорить насчет того, что с тем же SASS можно удобно делать запись БЭМ-селекторов.
Не вижу ничего супер удобного в стилях, основанных на куче вложенных селекторов, когда стиль зависит от структуры документа. Мало того, что это медленней для страниц с большим количеством элементов, так еще и создает проблемы с переиспользованием в более-менее крупных проектах из-за того что стили одних блоков зависят от других.
мы с вероятностью в 80% перестанем ловить постоянные баги… время модернизации функционала (а мы его модернезируем постоянно) увеличится примерно на 40%
Честно говоря, больше похоже на речь ясновидящего, а не программиста) Не очень люблю давать такие громкие обещания менеджменту, потому что потом, чуть что, обязательно будут фразы «ну ты же говорил...», «уже два бага за неделю, а ты обещал...».
А если, действительно, сидеть и подробно анализировать, что время разработки увеличится именно на 40%, а не на 30, то как тут уже писали, на это времени может уйти как на сам рефакторинг :)
Я считаю, что лучший вариант — это когда бизнес и разработчики знают, как найти общий язык и хоть немного вникают в проблемы друг друга, а не живут в параллельных измерениях.
Первое что приходит в голову: у вас есть какой-нибудь класс FileSystemStorage, который используется для сохранения картинок в локальной файловой системе. Этот класс используется в 100500 местах в проекте. Потом поступает требование, чтобы для хранения использовался Amazon S3. Без интерфейса мы создаем класс AmazonS3Storage, и нам приходится менять код во всех 100500 местах, где использовался FileSystemStorage. Если бы мы делали зависимости от интерфейса, а не от класса, то нам бы понадобилось исправить всего 1 строку в конфигурации DI контейнера.
Могу сказать одно: я точно знаю, что детали приходят в негодность (так же, как и меняются бизнес-требования и технические требования в приложениях). И я не хочу из-за неисправного масляного фильтра менять весь двигатель, или покупать новую машину только из-за того, что хочу литые диски, а не железные.
Ваша проблема в том, что вы утрируете. Придумываете какие-то небылицы с превращением обычного двигателя в ядерный или бургеров в блинчики. В реальной жизни и в программировании великое благо, когда можно при необходимости легко заменять одни части другими (в разумных пределах), а не выкидывать все и писать/покупать с нуля.
Время логируется так, как-будто программист работает над задачей 24 часа в сутки или есть какие-то условия, что из суток логировать только 8 часов (или что-то подобное)?
Перечитал два раза, но так и не понял, что тут говорится.
Например, я считаю (из собственного опыта), что вредно давать человеку одинаковую премию независимо от того, как он проработал месяц. Одно время я работал в компании, где фиксированная часть ЗП была постоянной, а премия напрямую зависела от эффективности. И да, я лишался пару раз 30% или 50% премии, но у меня язык не повернется назвать это демотивацией, так как я знал на что шел, когда косячил, знал, что я сам виноват и старался в следующий месяц исправиться. Главное тут, обговорить все заранее, а не сваливать в конце месяца как снег на голову новость об урезании премии.
К сожалению (или к счастью), люди не делятся только на тех, кто «тянет» или «не тянет». Есть хорошие специалисты, которые отлично «тянут», но если видят в команде отсутствие дисциплины и атмосферу полной вседозволенности, то постепенно начинают расхолаживаться и забивать.
Так как правильно наказывать то надо? Почему-то написано только очевидное, что и так всем понятно — «увольнение — крайняя мера», «не надо наказывать деньгами». Но ни одного конкретного примера, как наказывать/поощрять/мотивировать.
Наказывать только путем «серьезных разговоров»? Это не работает — если люди знают, что дальше разговоров никогда ничего не идет, на них это не действует.
А по какой причине?
По поводу тимлида, штука вот в чем (из статьи):
То есть, главное — это донести до команды задачу, правильно распределить ее между программистами и обеспечить выполнение, а не стараться отгородиться от всего, лишь бы сидеть и самому заниматься имплементацией.
Хорошо, сегодня тимлиду удалось оптимизировать митинги внутри компании, сократив их время на 50%, а завтра появятся подрядчики, с которыми тоже нужно проводить митинги. И тимлид закроет свою IDE и пойдет это делать. Потому что управление для него приоритетней, чем непосредственно программинг.
То что вам показалось значимым — это как раз пример дополнительных обязанностей, который привел автор статьи. Из того же абзаца (никакого субъективизма, все из статьи):
То что вам удается обходиться 15% времени на менеджмент — это замечательно. Но, если команда состоит из средненьких программистов, среди которых есть люди с проблемным характером, да еще и руководство компании непростое и любит долгие совещания (и на каждое дергает тимлида), плюс добавим кучу мелких администратвных дел, которые могут быть повешены на тимлида, то тут хорошо, если хотя бы 40% времени останется на непосредственно программирование.
Не даром же на западе в некоторых командах есть отдельно технический лидер (который полностью отвечает за техническую сторону, архитектуру) и тимлид (который больше менеджер).
Ваш личный опыт прочесть было интересно, но я думаю, сколько людей, столько и мнений.
Дело в том, что из-за отсутствия четкого понятия, что же такое тимлид, куча народу считает, что это высшая форма программиста. На самом деле, в команде могут быть программисты, которые сильнее тимлида, но все эти управленческие заботы им даром не нужны.
И самые важные качества тимлида (судя по статье) — организаторские способности, умение завоевать авторитет, способность брать ответственность на себя, умение выстроить отношения с командой, коммуникабельность — не связаны непосредственно с программированием — это менеджерские качества.
Я говорю не о том, чтобы отказаться от ангуляра, а о том, что не надо бездумно менять классы в HTML-коде, даже не проверяя, что на них завязано в js, а потом удивляться, почему все сломалось. И просто привел ссылку, что на этот счет говорит официальная документация.
Насчет завязывания логики на классах — я бы вообще не рекомендовал завязывать поведение на модификаторах, которые обозначают свойства вроде цвета или размера. Кроме того если разрабатывать с использованием инструментов, которые предоставляет Яндекс, то там прямо в документации говорится, что нельзя вот так брать и напрямую менять модификатор на DOM-ноде.
Также не буду говорить насчет того, что с тем же SASS можно удобно делать запись БЭМ-селекторов.
Честно говоря, больше похоже на речь ясновидящего, а не программиста) Не очень люблю давать такие громкие обещания менеджменту, потому что потом, чуть что, обязательно будут фразы «ну ты же говорил...», «уже два бага за неделю, а ты обещал...».
А если, действительно, сидеть и подробно анализировать, что время разработки увеличится именно на 40%, а не на 30, то как тут уже писали, на это времени может уйти как на сам рефакторинг :)
Я считаю, что лучший вариант — это когда бизнес и разработчики знают, как найти общий язык и хоть немного вникают в проблемы друг друга, а не живут в параллельных измерениях.
Ваша проблема в том, что вы утрируете. Придумываете какие-то небылицы с превращением обычного двигателя в ядерный или бургеров в блинчики. В реальной жизни и в программировании великое благо, когда можно при необходимости легко заменять одни части другими (в разумных пределах), а не выкидывать все и писать/покупать с нуля.