2013-11-28
Покажите мне десять команд, и я покажу вам десять разных подходов к код-ревью.
Я не буду говорить об инструментах. Инструменты можно подобрать к выбранному процессу, но сам процесс не зависит от инструментов.
В разработке огромное количество внимания уделяется поиску лучших практик для совместной инспекции кода. Тогда почему самые распространённые практики до сих пор неэффективны.
Перед тем, как перейти к обзору эффективности различных подходов, нужно определиться с целями такой деятельности, как код-ревью. Единственная значимая цель код-ревью —найти истоки ошибок в логике кода.
Дайте программистам десять строк кода, и они найдут десять ошибок. Дайте им сто строк кода, и они не найдут ни одной.
Скорее всего, вы знакомы с этим афоризмом, он вполне остроумно звучит, многим нравится, и в душе вы с ним согласны.
Интутитивно мы подтверждаем, что так оно и есть, но рационально объяснить себе причины такого феномена не можем. Первая причина, которая нам приходит в голову, — это лень. Но это самое первое, очевидное, ленивое и неверное умозаключение.
Популярная книга Дэниэла Канемана, нобелевского лауреата по экономике, «Мыслить быстро и медленно» (Thinking. Fast and Slow) открыла мне глаза на то, насколько нерациональны мы в своём мышлении.
Что же на самом деле происходит при рецензировании кода?
Во-первых,
Когда ревьюер просматривает код, его реакцией по умолчанию является одобрение. Другими словами, если период времени, выделенный на ревью, стремится к нулю, мы более подвержены к принятию внесённых изменений, чем к отклонению. Причиной этому может быть наше доверие к коллегам или к автоматическим тестам, которые выявят большую часть регрессивных изменений. Но самое вероятное оправдание нашему стремлению одобрить большую часть кода при ревью — это наше нежелание объяснить свои мотивы при отклонении изменений.
Во-вторых,
Мы склонны к когнитивным искажениям. В ходе код-ревью конформизм играет значимую роль. Ревьюеры спрашивают себя: «Выглядит ли это как хороший код?».
Мы легко ведёмся на визуальные индикаторы вроде ошибок форматирования строк или правильной расстановки скобок: хотя, несмотря на идеальный синтаксис, код может быть ужасен с точки зрения логики и алгоритмов.
В-третьих,
При инспекции кода мы подвержены длительной ментальной активности. Инспекция кода требует интенсивной аналитической работы в течение долгого времени. Неважно, сколько человек занимается рецензированием кода, ваш мозг не приспособлен к выполнению такой деятельности на протяжении нескольких часов.
В результате мы и принимаем решения «по умолчанию», поддаваясь когнитивным искажениям.
Что делать?
Проводите инспекцию кода очень малыми частями.
Запас нашей ментальной энергии быстро истощается. Мы можем распределить этот запас равномерно на большом куске кода, либо сфокусироваться на малом количестве. По моему опыту, фиксация внимания на малой части (на одном классе или даже на одном методе) приносит гораздо лучшие результаты.
Проводите инспекцию кода почти при полном отсутствии контекста.
Обширный контекст отвлекает нас, и мы попадаем в ловушку оценки формы, а не функционирования и содержания. Пусть форму оценивают автоматизированные инструменты, а человеческий мозг сосредоточится на определении логических свойств конкретного куска кода. Тесты могут сделать это за вас только в том случае, если они составлены правильно.
Уделяйте процессу рецензирования кода 5 минут.
Не больше и не меньше. Пять минут — это максимально допустимое время для эффективной инспекции кода. После пяти минут качество рецензирования значительно снижается.
В качестве итога
Я верю, что не так важны методы и инструменты, которые вы используете при код-ревью. Кому-то нравится рецензировать пулл-реквесты в одиночестве, кто-то предпочитает сидеть рядом с автором кода.
Но основные принципы не меняются: малые куски, малое количество времени «за один присест», малый контекст.
Разделяем и властвуем.
Перевод: Люся Ширшова. По материалам блога Adam Thody, Тим-Лида команды веб-разработки, на Medium.com.
