Code Review

Ревью кода является популярной практикой во многих командах разработки. Идея очень простая - до того, как код попадет в основную ветку и станет доступен всем, автор может (или должен) выложить код на рассмотрение остальных членов команды. Обычно для этого используется модель отдельных бранчей и различные инструменты, которые позволяют удобно просматривать и обсуждать код. Ревьюверы изучают изменения, комментируют, предлагают и обсуждают решения проблем, если они есть. После этого код либо принимается и попадает в основной бранч репозитория, либо отправляется автору на доработку.

Проблемы

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

Потеря контекста

Самая главная проблема код ревью - это полная потеря или отсутствие контекста. Контекст включает и мотивацию автора (“Я так делал много раз и это работало”), технические сложности и ограничения (“Не самый лучший способ решить проблему, но в версии библиотеки ХХХ по другому никак”), временные рамки и проектные ограничения (“Все равно перепишем это на следующей неделе”). Ревьюверы могут всего этого не знать. В дополнение к этому, иногда измненения могут быть большими и сложными, затрагивать несколько модулей сразу. Тогда нужно еще и иметь очень хорошее знание и понимание кодовой базы. Инструменты в этом совсем не помогают: ни в одном инструменте для код ревью нельзя ни запустить тесты, ни открыть приложение, ни использовать отладчик. Да даже простая навигация по коду не доступна. По сути, ревью - это просто чтение кода на экране. Учитывая, как в целом программисты не любят интервью “у доски” (whiteboard interview), иронично видеть как многие из них переносят практику изолированной и не интерактивной работы с кодом на ревью.

Отсутствие эмпатии

Вторая проблема, которая по своей важности стоит на том же уровне, что и потеря контекста - это отсутствие эмпатии. Код на ревью - это просто набор строчек на экране, за ним не видно человека, сложно понять его способ мышления и мотивацию. Особенно если ревьювер и автор разделены географическими или временными рамками. Командная работа над кодом это, в первую очередь, социальная активность. А отсутствие строгих, формальных метрик “хорошего” кода в процессе код ревью может создать ненужное напряжение между людьми.

Нарушение потока и бюрократия

Еще одна сложность, которую добавляет обязательное ревью - это нарушение “потока” в разработке задач и создание ненужной бюрократии. Особенно в модели, когда есть всего несколько человек, которые должны утвердить код, и эти люди легко становятся узким местом всего процесса. Для автора кода ревью добавляет сложный и затянутый по времени шаг перед завершением работы над задачей. Если ревью занимает больше 5-10 минут, автор может начать работать над новой задачей, переключится на другую активность. А по мере поступления комментариев, ему придется постоянно возвращаться к предмету ревью. Нужно вспоминать и восстанавливать контекст, переключаться между бранчами, думать над другой проблемой.

Варианты

Какие же есть варианты, как сделать код ревью эффективным и не ломать процесс работы над продуктом?

Парное программирование

Самый простой вариант, предложенный практиками XP - это парное программирование. Идея очень проста: самый лучших способ понять и оценить код - это написать его. Когда два человека работают над одним кодом вместе, ревью случается не просто в конце как жирная бюрократическая точка, а становится частью процесса написания кода. Обмен идеями и мнениями происходит здесь и сейчас, оба человека в курсе всех тонкостей задачи, которую они решают, ограничений и проблем, оба могут делиться опытом и идеями в нужный момент. Этот процесс полностью интерактивный, помимо общего знания у пары программистов есть правильные инструменты (IDE, тесты, актуальная версия системы).

Show and tell сессии

Если же по каким-либо причинам парное программирование, хотя бы для конкретных задач, не подходит - то нужно хотя бы постараться сделать процесс полностью интерактивным. Например, вместо “отправления” кода на ревью - проводить сессии show and tell по коду. На такой сессии автор может рассказать о чем он думал, когда писал код. Ревьюверы могут задать вопросы, уточнить вопросы и получить ответы. И вся команда сможет понять - как и почему было принято то или иное решение в коде. По сути, это как если заменить общение через email на личный разговор - эффективность процесса возрастает в разы и появляется важный элемент эмпатии.

Постоянный рефакторинг

Ну и очень важный момент, который нужно учитывать и при написании и при ревью код - код это не скрижали, которые нельзя изменить. Не стоит думать о коде “либо идеально, либо никак”. Код не должен быть идеальным, он должен быть необходимо и достаточно хорошим. Эта практика ничем не отличается от lean product development, или регулярных релизов в production. Регулярно “выпускайте” код в общий репозиторий, регулярно его рефакторите. Пусть он живет и развивается, а не медленно стагнирует в заброшенном на код ревью бранче.