Critique и Gerrit

У Google есть два собственных инструмента для ревью кода: Critique, используемый большинством инженеров, и Gerrit, — опенсорсный, который продолжают применять в публичных проектах.

(Вы можете сами поэкспериментировать с Gerrit в опенсорсных репозиториях Chromium и Android.)

Дэшборды

Когда инженеры логинятся с утра или когда устраивают перерыв для ревью пул-реквестов, внутри Google называемых change list, или CL, и в Critique, и в Gerrit они работают с дэшбордами, в которых можно легко вкратце просмотреть все актуальные изменения (это похоже на окно пул-реквестов репозитория GitHub, только более сложное и информационно насыщенное).

В дэшборде Gerrit есть единичный поиск, извлекающий такую информацию, как размер изменения и более подробные сведения о статусе CL (три столбца справа).

В выпущенном позже Critique дэшборд может состоять из множества разделов, позволяющих авторам выделять различные группы CL (чаще всего это созданные ими изменения, которые ещё не смерджены, и те, которые требуют их ревью).

У Critique есть одна странная особенность: кнопка «Switch user» в верхней панели инструментов. Она позволяет просматривать разделы другого пользователя, например, если вы хотите убедиться, что ваш CL действительно ему виден.

Просмотр CL

При нажатии на CL открывается следующее окно:

Разумеется, там есть привычные элементы, например заголовок, описание, diff, список файлов и список ревьюеров, но там присутствуют и дополнительные полезные элементы, которых не увидишь на GitHub.

В Gerrit непосредственно рядом со списком файлов отображаются метрики покрытия тестами:

Сообщение коммита для CL отображается как просматриваемая сущность первого класса, расположенная прямо рядом с изменёнными файлами в разделе diff:

Существуют также некоторые примечательные элементы, которые не видно или плохо видно на скриншоте выше:

• Строки кода, которые просто были перенесены в diff, визуально отображаются иначе.

• Для стандартных ответов существуют удобные быстрые функции: «Автор изменения может нажать на кнопку "Done" в панели комментариев, чтобы показать, что комментарий ревьюера был учтён, или на кнопку "Ack", чтобы подтвердить, что комментарий прочитан; обычно это используется для информационных или вспомогательных комментариев. Обе эти кнопки ресолвят ветку комментариев, если это ещё не было сделано. Эти быстрые функции упрощают рабочий процесс и уменьшают время, необходимое для просмотра комментариев». [1]

• Для всего есть клавиатурные сочетания.

• Кроме просмотра общего diff можно также с лёгкостью просматривать версии diff CL. (Рассмотрим ситуацию: ваш коллега публикует CL (v0), вы даёте обратную связь, он учитывает её и обновляет CL (v1), и теперь вам нужно просмотреть только то, что изменилось, то есть diff между v0 и v1.)

Готово к мерджу?

В терминологии GitHub мы обычно говорим, что PR готов к слиянию (merge). Однако в Google говорят, что CL готов к отправке (submit). Именно поэтому на скриншотах выше присутствуют «Submit Requirements».

Однако перед отправкой изменений в Google они должны пройти три уровня обязательных утверждений:

1. LGTM («looks good to me»)

2. Владельцы кода

3. Читаемость

Первые два (LGTM и владельцы кода) должны быть знакомы инженеру, работавшему с GitHub.

• LGTM может утвердить любой; это означает, что в CL присутствует базовая бизнес-логика (это эквивалентно обычному утверждению ревью пул-реквеста в GitHub).

• Владельцы кода чётко соотносятся с эквивалентной концепцией GitHub: когда вы вносите изменение в какой-то файл, вам нужно утверждение того, кто указан владельцем этого файла или содержащей его папки. (Если вы и автор, и владелец, то утверждение происходит автоматически.)

(На самом деле, GitHub позаимствовал концепцию владельцев кода непосредственно от Google; когда в 2017 году в GitHub была добавлена поддержка владельцев кода, внизу было указано небольшое примечание: «Источником вдохновения для функции владельцев кода стало использование в Chromium файлов OWNERS».)

Читаемость же — это исключительно концепция Google.

В Software Engineering at Google замечательно описывается, откуда она взялась [2]:

В ранние годы Google Крейг Сильверштейн (сотрудник с ID за номером 3) проводил личные собеседования с каждым новым сотрудником и выполнял построчное «ревью читаемости» его первого серьёзного коммита кода. Это было очень дотошное ревью, охватывавшее всё, от возможных способов совершенствования кода до стандартов расстановки пробелов. Это обеспечило кодовой базе Google единый внешний вид, но, что более важно, научило разработчиков best practices, подчеркнув существование общей инфраструктуры и показав новичкам, каково это — писать код в Google». Программа обеспечения читаемости применяется и сейчас, её задача — поддержание этого стандарта в среде десятков тысяч разработчиков, ежедневно выполняющих слияние десятков тысяч изменений.

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

(Как и в случае с владельцами кода, если вы и автор, и «специалист по читаемости» для языка, на котором вы написали CL, то изменение утверждается автоматически.)

«Группы внимания» и «очереди»

Так как потенциально может существовать куча разных множеств ревьюеров на каждое CL, например, при работе над кодовой базой другой команды вам может понадобиться LGTM от коллеги из вашей команды (лучше всех знающего изменение, которое вы хотите внести в ваш собственный продукт), утверждение владельца кода и ревью читаемости от других команд, то можно легко запутаться, чьи действия необходимы для утверждения конкретного изменения.

В Gerrit и Critique эта проблема решается идеально.

На этом скриншоте из старой версии Gerrit можно заметить, что рядом с именами некоторых авторов или ревьюеров есть серая стрелка.

А в Critique некоторые имена выделены полужирным шрифтом.

Эти маркеры обозначают, что теперь чья-то «очередь» (turn) предпринимать действие с конкретным CL. Если навести указатель мыши на индикатор, то Gerrit или Critique также сообщат, почему, по их мнению, ваша очередь предпринимать действие (например, только что было запрошено ваше ревью или автор ответил на ваш комментарий). В любой конкретный момент времени множество всех людей, чья очередь сейчас настала, создают общую «группу внимания» (attention set).

Для любого CL ревьюер может оставить пометку «не моя очередь», убрав себя из группы внимания и сообщив автору, а также другим людям, оставшимся в группе внимания, кто действительно должен предпринять действие. Это может быть вызвано тем, что, например, его коллега — более опытный ревьюер или потому что ему нужно, чтобы действие сначала предпринял другое ревьюер; в культуре Google так сложилось, что ревью CL обычно первым выполняет ревьюер LGTM, а затем владелец кода и специалист по читаемости.

Культура ревью

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

В 2018 году несколько людей из Google провели подсчёты и опубликовали результаты в рамках статьи Modern Code Review: A Case Study at Google; оказалось, процесс этот совершенно не медленный. [3]

«Мы обнаружили, что в Google медианные авторы-разработчики вносят примерно три изменения в неделю, а 80% авторов вносит менее семи изменений в неделю. Аналогично, медиана прошедших ревью разработчиками изменений составляет 4, и 80% ревьюеров проверяют менее десяти изменений в неделю. Также мы выяснили, что в медиане разработчикам приходится ждать обратной связи по их изменениям меньше часа в случае мелких изменений и примерно пять часов в случае очень крупных изменений. Общая медианная задержка (для кода всех размеров) для всего процесса ревью составляет менее четырёх часов. Это существенно меньше, чем медианное время утверждения из исследований Питера Ригби и Кристиана Бёрда [33], которое составляет 17,5 часа для AMD, 15,7 часа для Chrome OS и 14,7, 19,8 и 18,9 часа для трёх проектов Microsoft. Ещё одно исследование показало, то медианное время утверждения в Microsoft составляет 24 часа».

Отчасти за такую высокую скорость следует благодарить инструментарий — дэшборд и чёткую очередь, указывающую, на что именно вам нужно обратить внимание. (Также существует удобное расширение Chrome, умеющее рендерить основную часть дэшборда, поэтому можно смотреть на него, вне зависимости от посещаемой страницы.)

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

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

Это тоже в большой степени часть процесса ревью кода в Google.

Источники

[1] Written by Caitlin Sadowski, Ilham Kurnia, and Edited by Lisa Carey. “Critique: Google’s Code Review Tool.” Software Engineering at Google. https://abseil.io/resources/swe-book/html/ch19.html.

[2] Written by Caitlin Sadowski, Ilham Kurnia, and Edited by Lisa Carey. “Critique: Google’s Code Review Tool.” Software Engineering at Google. https://abseil.io/resources/swe-book/html/ch19.html.

[3] Sadowski, Caitlin, Emma Söderberg, Luke Church, and Michal Sipko. “Modern Code Review: A Case Study at Google.” Proceedings of 40th International Conference on Software Engineering: Software Engineering in Practice Track, n.d. https://sback.it/publications/icse2018seip.pdf.