Джин Ким - Руководство по DevOps

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

Принципы рецензирования кода включают в себя следующее:

• у каждого сотрудника должен быть кто-нибудь, кто проверяет его исправления (и в коде, и в окружении) перед отправкой в основной код проекта;

• все сотрудники должны следить за потоком правок своих коллег, чтобы можно было заметить и проанализировать потенциальные конфликты изменений;

• определите, какие изменения считаются очень рискованными: они могут потребовать анализа эксперта в этой области (например, исправления в базах данных, такие важные с точки зрения безопасности модули, как подтверждение прав доступа, и так далее) [137];

• если кто-то собирается внести слишком объемные для понимания правки — другими словами, если даже после нескольких прочтений вы не можете понять, к каким последствиям они приведут, или вам нужно просить о разъяснениях, — их нужно разделить на более мелкие части, понятные с первого взгляда.

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

Анализ кода может принимать несколько разных форм.

• Парное программирование.Программисты работают парами (см. раздел ниже).

• «Чересплечное» программирование.Один программист наблюдает за работой другого, когда тот проходит по написанному им коду.

• Передача по электронной почте.Система управления исходным кодом автоматически рассылает код на рецензию после того, как программист ставит пометку о внесении изменений

• Анализ кода с помощью инструментов.Авторы и рецензенты используют специально разработанные для обзора кода инструменты (например, Gerrit, запросы на внесение изменений GitHub и так далее) или средства, предоставляемые репозиториями исходного кода (например, GitHub, Mercurial, Subversion, а также такие платформы, как Gerrit, Atlassian Stash и Atlassian Crucible).

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

Компания Google — прекрасный пример организации, использующей разработку на основе единой ветви кода и непрерывную масштабируемую поставку. Как отмечалось ранее, Эран Мессери рассказывал, что в 2013 г. организация процессов в Google позволяла более чем 13 000 разработчиков работать в своих ветвях над одним и тем же исходным кодом, совершая более 5500 коммитов в неделю. Число развертываний за неделю доходило до нескольких сотен. Согласно данным 2010 г., каждую минуту в основную ветку кода отправлялось более двадцати правок, из-за таких темпов каждый месяц обновлялось 50 % кода.

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

• легкая читаемость кода (нужны руководства по стилю оформления кода);

• назначение ответственных за поддеревья кода для поддержания единообразия и контроля над отсутствием ошибок;

• прозрачность кода и сотрудничество в работе над одним и тем же кодом между разными командами.

На рис. 42 показано, как время на рецензирование кода зависит от размера внесенных изменений. На оси X отмечается размер правок, на оси Y — время, затраченное на проверку кода. В общем случае чем больше объем изменений, тем дольше проходит анализ. Точки в верхнем левом углу обозначают более сложные и потенциально рискованные изменения, требующие более глубокого обдумывания и обсуждения.

Рис. 42. Длительность рецензирования в зависимости от размера кода в компании Google (источник: Ашиш Кумар, “Development at the Speed and Scale of Google,” презентация на QCon, Сан-Франциско, CA, 2010. https://qconsf.com/sf2010/dl/qcon-sanfran-2010/slides/AshishKumar_DevelopingProductsattheSpeedandScaleofGoogle.pdf)