Вместе с Женей Антоновым, небезызвестным автором канала Тимлид Очевидность, мы договорились написать пост на одну и ту же тему, а потом сравнить наши мысли.
И вот что получилось у меня:
------------------
Что если я скажу вам, что код ревью делать необязательно? Ручное тестирование замедляет процессы? Линтер не нужен? Скрам только вредит? Ваш язык не подходит для ваших задач? Покрытие тестами замерять вредно?
Наверняка вас триггернуло хотя бы одно из этих высказываний. Например: как это без код ревью, да там же говнокод польётся рекой! У всех нормальных команд оно есть!
Тогда у меня встречный вопрос: а как принималось решение о введении код ревью в процессы команды? За всех говорить не буду, но держу пари, что во многих случаях примерно так: в прошлом проекте мы так делали, а когда формировали новую команду, то тоже решили так делать.
Проблема в том, что в прошлой команде процесс принятия решения был точно такой же. И вот мы видим, что код ревью есть везде и у всех, и теперь этот подход - непреложная истина. Съехать с него почти невозможно.
Или взять хотя бы скрам - он перетекает из организации в организацию как вирус, при том, что его ценность во многих случаях сомнительна. Самое смешное, что чаще всего скрам внедряется вообще без особого обсуждения, несмотря на то, что это очень серьёзно влияет вообще на всё. Просто все так делают, и мы будем. У СЕО на прошлом проекте был скрам, теперь и у нас будет. Даже если не решает никаких проблем.
И это удивительно, ведь айтишники любят говорить (особенно в твиттере), какие они избранные интеллектуалы, но в ключевых вопросах зачастую просто следуют “за стадом”, на ходу рационализируя выбор при малейших робких сомнениях.
Лирическое отступление по поводу код ревью, потому что наверняка будут вопросы. Как и любой инструмент, код ревью может быть как на пользу, так и во вред. В проекте, где затрагивается человеческая жизнь (медицинские приборы, автопилоты автомобилей) или есть вопросы безопасности - код ревью наверно необходим. Однако в несложном продуктовом коде делать обязательный апрув, т.е. блокер, на каждой задаче - это серьёзное ухудшение пресловутого time-to-market, и возможно в команде сработавшихся профессионалов эта обязательность будет только мешать: достаточно иногда смотреть старые комиты для контроля качества кода и заранее проговаривать словами особо сложные технические решения, но не блокировать всё подряд. Другими словами, нужность код ревью зависит от проекта и задачи, но не является абсолютной истиной.
В какой момент многократно повторенная мысль становится базовой истиной, от которой потом невозможно отойти? Думаю, что всё просто. Это банальная лень, экономия энергии. Пресловутые система 1 и система 2. Подумайте, сколько всего надо, чтобы перестроиться со скрама на что-нибудь другое: все привыкли к этим пляскам, сторипоинтам, покеру и фибоначчи, знают свою роль, в jira уже всё настроено, в календаре забиты все нужные митинги. А для преобразований надо убедить каждого члена команды и руководство. Дохлый номер. То, что делают все, то истина, и так останется навсегда. Нужна по настоящему железная воля на самом верху, чтобы переубедить всех людей и поменять всю систему на какую-то другую. Потому что система сейчас устойчива (даже если не эффективна), и переход к другому устойчивому состоянию требует огромной энергии.
Кстати, командам легче перестроиться, если им дадут больше полномочий. Я вообще выступаю за по возможности полную независимость команд внутри компании, тогда им будет намного проще пересматривать и менять свои процессы, чем ворочать огромного монстра целиком.
Весто вывода: советую хотя бы иногда пересматривать вообще всё. Любые процессы и технологии, особенно те, которые раздражают, должны регулярно подвергаться сомнению.
-----------------
Вариант Жениного поста можно почитать здесь (ужасно любопытно, что там будет). В любом случае всем искренне советую подписаться на его канал Тимлид Очевидность - это много лет качественного контента на самые важные темы каждую пятницу (мне бы его дисциплину)
И вот что получилось у меня:
------------------
Что если я скажу вам, что код ревью делать необязательно? Ручное тестирование замедляет процессы? Линтер не нужен? Скрам только вредит? Ваш язык не подходит для ваших задач? Покрытие тестами замерять вредно?
Наверняка вас триггернуло хотя бы одно из этих высказываний. Например: как это без код ревью, да там же говнокод польётся рекой! У всех нормальных команд оно есть!
Тогда у меня встречный вопрос: а как принималось решение о введении код ревью в процессы команды? За всех говорить не буду, но держу пари, что во многих случаях примерно так: в прошлом проекте мы так делали, а когда формировали новую команду, то тоже решили так делать.
Проблема в том, что в прошлой команде процесс принятия решения был точно такой же. И вот мы видим, что код ревью есть везде и у всех, и теперь этот подход - непреложная истина. Съехать с него почти невозможно.
Или взять хотя бы скрам - он перетекает из организации в организацию как вирус, при том, что его ценность во многих случаях сомнительна. Самое смешное, что чаще всего скрам внедряется вообще без особого обсуждения, несмотря на то, что это очень серьёзно влияет вообще на всё. Просто все так делают, и мы будем. У СЕО на прошлом проекте был скрам, теперь и у нас будет. Даже если не решает никаких проблем.
И это удивительно, ведь айтишники любят говорить (особенно в твиттере), какие они избранные интеллектуалы, но в ключевых вопросах зачастую просто следуют “за стадом”, на ходу рационализируя выбор при малейших робких сомнениях.
Лирическое отступление по поводу код ревью, потому что наверняка будут вопросы. Как и любой инструмент, код ревью может быть как на пользу, так и во вред. В проекте, где затрагивается человеческая жизнь (медицинские приборы, автопилоты автомобилей) или есть вопросы безопасности - код ревью наверно необходим. Однако в несложном продуктовом коде делать обязательный апрув, т.е. блокер, на каждой задаче - это серьёзное ухудшение пресловутого time-to-market, и возможно в команде сработавшихся профессионалов эта обязательность будет только мешать: достаточно иногда смотреть старые комиты для контроля качества кода и заранее проговаривать словами особо сложные технические решения, но не блокировать всё подряд. Другими словами, нужность код ревью зависит от проекта и задачи, но не является абсолютной истиной.
В какой момент многократно повторенная мысль становится базовой истиной, от которой потом невозможно отойти? Думаю, что всё просто. Это банальная лень, экономия энергии. Пресловутые система 1 и система 2. Подумайте, сколько всего надо, чтобы перестроиться со скрама на что-нибудь другое: все привыкли к этим пляскам, сторипоинтам, покеру и фибоначчи, знают свою роль, в jira уже всё настроено, в календаре забиты все нужные митинги. А для преобразований надо убедить каждого члена команды и руководство. Дохлый номер. То, что делают все, то истина, и так останется навсегда. Нужна по настоящему железная воля на самом верху, чтобы переубедить всех людей и поменять всю систему на какую-то другую. Потому что система сейчас устойчива (даже если не эффективна), и переход к другому устойчивому состоянию требует огромной энергии.
Кстати, командам легче перестроиться, если им дадут больше полномочий. Я вообще выступаю за по возможности полную независимость команд внутри компании, тогда им будет намного проще пересматривать и менять свои процессы, чем ворочать огромного монстра целиком.
Весто вывода: советую хотя бы иногда пересматривать вообще всё. Любые процессы и технологии, особенно те, которые раздражают, должны регулярно подвергаться сомнению.
-----------------
Вариант Жениного поста можно почитать здесь (ужасно любопытно, что там будет). В любом случае всем искренне советую подписаться на его канал Тимлид Очевидность - это много лет качественного контента на самые важные темы каждую пятницу (мне бы его дисциплину)