Делайте ревью кода

(В оригинале - Code Reviews)

Вы должны делать ревью кода. Почему? Потому что это повышает качество кода и снижает процент ошибок. Но не совсем по тем причинам, о которых вы могли бы подумать.

Многие программисты не любят ревью кода, потому что имели ранее негативный опыт. Я встречал организации, требовавшие обязательный формальный просмотр кода перед отправкой в продакшен. Часто весь просмотр делает архитектор или ведущий разработчик. Такое положение вещей закреплено формально, поэтому разработчикам приходится его принять. Возможно, некоторым организациям действительно нужно соблюдать столь строгие правила, но большинству это не надо. Более того, для них такая практика оказывается контрпродуктивной. Те, чей код просматривают, могут себя чувствовать проверяемыми. А проверяющим нужно время для самой проверки и время, чтобы постоянно быть в курсе всех подробностей системы. Проверяющие очень быстро могут стать узким местом всего процесса, что приведет к его деградации.

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

Будьте мягкими во время просмотра. Обеспечьте, чтобы замечания были конструктивными, не едкими. Представьте различные роли просмотра, чтобы избежать влияния иерархической структуры команды на процесс ревью кода. Примеры ролей – просмотр документации, просмотр системы исключений, просмотр функциональности. Такой подход позволяет распределить груз ревью кода по всем членам команды.

Выделите отдельный «день просмотра кода» в неделю. Тратьте пару часов на обсуждения просмотра. Обеспечьте равномерную ротацию ролей просматривающих. Меняйте роли на каждом обсуждении ревью. Вовлекайте в просмотр новичков. У них может не быть достаточно опыта, но при этом у них будет «свежий взгляд», что тоже имеет свою ценность. Вовлекайте в процесс экспертов. Они смогут быстрее и точнее найти проблемные места. Процесс просмотра будет идти быстрее, если в команде будет установленный стиль кодирования, проверяемый автоматически. Тогда обсуждение стиля не будет выноситься на обсуждения.

Самый главный залог успеха – сделать процесс просмотра привлекательным. Если процесс создает проблемы или вызывает негатив, то будет сложно кого-либо мотивировать его проводить. Сделайте его неформальным. Сделайте основной целью просмотра распределение знаний между членами команды. Вместо сарказма старайтесь быть позитивными.

Автор оригинала - Mattias Karlsson