Книга: Руководство по DevOps

Введите практику рецензирования изменений

Вместо того чтобы требовать разрешения на развертывание у внешнего арбитра, можно побуждать инженеров рецензировать работу своих коллег. В разработке эта практика носит название анализ кода, но ее можно приспособить и для любых других изменений в приложениях или окружении, включая серверы, сеть и базы данных[136]. Суть метода в том, чтобы кто-нибудь из инженеров, близких к конкретной задаче, тщательно рассмотрел и проанализировал предлагаемые правки. Такое рецензирование улучшает качество вносимых исправлений, а также стимулирует взаимное обучение и улучшение навыков.

Логичный момент, когда нужно проводить анализ, — перед отправкой кода в систему управления кодом, где изменения потенциально могут привести к глобальному сбою. Как минимум рецензирование должен проводить ваш непосредственный коллега, но для областей с более высоким уровнем риска, например для баз данных или критичных для бизнеса компонентов со слабым покрытием автоматизированными тестами, может потребоваться более глубокий анализ эксперта (например, инженера по информационной безопасности или инженера по базам данных) или же несколько разных рецензий от разных специалистов («+2» вместо «+1»).

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Оглавление книги