Вы когда-нибудь делали проверку кода мерж-реквеста, не разговаривая с человеком, написавшим код? Вероятно, нет, а если и были, то это может предвещать более серьезные проблемы в вашей команде.

Давайте посмотрим на все, что не так с использованием проверки кода в качестве основного инструмента для поддержания качества кода и оптимизации разработки.

Это медленно

В среде с быстрым темпом и скоростью доставки, в которой сегодня находится большинство команд, проверка кода является бесконечным узким местом для пропускной способности доставки. Независимо от того, делается ли это специально или как часть четко определенного процесса (запросы на слияние и т. д.), он всегда включает в себя несколько случаев переключения контекста и отсроченных циклов обратной связи. К тому времени, как Пит внес все предложенные ему изменения, мир изменился, и ему снова нужно наверстать упущенное. Если Пит уже находится в долгоживущей ветке (любой ветке, которая прожила более суток), он полностью зависит от темпа своих коллег.

Быть «плохим парнем»

Не всем удобно быть плохим парнем, потому что, давайте признаем, вы таковы, когда просматриваете чужой код. Вы смотрите на работу, которую кто-то с гордостью представил вам, полагая, что она настолько хороша, насколько это возможно. Как можно не быть плохим парнем, когда вы указываете, что абстракции хрупки и что код изобилует плохими именами методов? Здесь принципиально два подхода. Либо вы снисходительны к парню, потому что знаете, что его самоуверенность сейчас не самая лучшая, и опускаете некоторые мелкие нарушения. Такая практика, очевидно, со временем приводит к ухудшению качества кода и снижает общий уровень обучения в команде. Другой вариант — более жесткий подход, но он редко помогает команде сблизиться с течением времени. Это также может иметь побочный эффект, заключающийся в том, что менее безопасные или неопытные программисты предпочитают, чтобы их критиковал кто-то менее… критикующий.

LGTM — это шутка

Сама суть проверки кода склонна игнорировать ошибки, во многом из-за полной потери контекста. Это как читать последнюю главу книги и думать, что вы поняли все намерения рассказчика. Вы можете понять окончательный результат (хотя и с трудом), но вы не знаете, ПОЧЕМУ он такой. А когда дело доходит до кода, иногда важнее знать, что не попало в список, а не то, что попало.

Другая проблема заключается в том, что вы редко вкладываетесь в чужой код так же, как в свой собственный. «Выглядит хорошо для меня!» — нередкий комментарий от человека, который бегло просмотрел код, думая, что съесть на обед. Как вы думаете, человек, просматривающий ваш код, заметит ошибку компиляции?

Игра с обвинением

Кого винить, когда обнаруживается какой-то беспорядочный код или ошибка, которую можно избежать? Рецензент? Возможно нет. Если вы даже не используете мерж-реквесты или что-то подобное, через неделю никто даже не узнает, кто рецензировал код Пита. Все, что они знают, это то, что Пит экономил на качестве. Если бы они занимались парным или, что еще лучше, групповым программированием, ни один человек не был бы виноват. Команда должна будет взять на себя общую ответственность и учиться на своих типичных ошибках.

Но подождите, культура обвинений — это не проблема процесса! Хотя я согласен с тем, что культуры обвинения следует избегать любой ценой, я все же считаю, что проверка кода по своей сути имеет свойство уговаривать такое поведение. Когда вы видите, что Пит четыре раза на этой неделе проталкивал уродливый код, у вас неизбежно появляются некоторые предрасположенные представления о том, чего ожидать, когда вы получите от Пита запрос на слияние в пятый раз. Короче; он преувеличивает самые уродливые черты как рецензента, так и рецензента, а не умаляет их.

Процессы, процессы, процессы

Спросите себя, действительно ли вам нужен еще один процесс в вашей жизни. Чтобы проводить «эффективную» проверку кода, необходимо внедрить процессы, гарантирующие, что качество никогда не будет скомпрометировано из-за небрежности или «нехватки времени». Часто это легче сказать, чем сделать, и я видел бесчисленное количество примеров, когда что-то падает между стульями или непреднамеренно делается ярлык в попытке «улучшить» процесс.

Пожалуйста, обратите внимание, что я использовал довольно много цитат, и все они были сделаны намеренно.

Подводя итоги

Говорят, что "человек не остров", и это особенно верно, когда речь идет о программировании. Программирование — это социальная деятельность, и любой процесс или инструмент, который преуменьшает этот факт, по моему мнению, опасен по своей сути.