14/97: Разбор кода

Это перевод Code Reviews. Автор: Mattias Karlsson.

Из "97-ми вещей, которые должен знать каждый программист".

Вам нужно проводить разбор кода (code review). Почему? Потому что он улучшает качество вашего кода и уменьшает частоту ошибок. Но не обязательно по тем причинам, по которым вы думаете, что он это делает.

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

Вместо простого исправления ошибок в коде, цель разбора кода - поделиться знанием и выработать общепринятые методологические рекомендации. Делясь своим кодом с другими программистами, вы закладываете фундамент совместного владения кодом. Пусть случайный член команды пройдёт сквозь код остальной команды. Вместо поиска ошибок, ему следует сделать обзор кода, пытаясь понять, что он делает, и понять как.

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

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

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

Примечание переводчика: