Делай как вGoogle
 Скачать 5.77 Mb.
|
|
401 y Rapid — инструмент для выпуска новых версий, который упаковывает и развер- тывает двоичные файлы, содержащие серии изменений; y Zapfhahn — инструмент вычисления доли кода, охваченной тестами. Кроме того, существуют службы, возвращающие информацию об изменениях (напри- мер, имена пользователей — авторов изменений или ошибки, для устранения которых создавались изменения). Critique идеально подходит для быстрого доступа к этим системам и организации пользовательского интерфейса к ним, однако мы не исполь- зуем его для этого, чтобы не жертвовать простотой. Например, на странице изменения в Critique автору достаточно щелкнуть только один раз, чтобы начать редактирование изменения в Cider. Существует также поддержка навигации по перекрестным ссылкам Kythe и просмотра кода в главной ветви с помощью Code Search (глава 17). Critique поддерживает связь с инструментом, показывающим, относится ли отправленное из- менение к конкретной версии. В Critique отдается предпочтение ссылкам, а не встро- енным операциям, чтобы не отвлекать пользователей от основного процесса обзора кода. Единственным исключением является оценка охвата тестами: информация об охвате строк кода тестами отображается разными цветами фона на полях в пред- ставлении различий (не все проекты используют отдельный инструмент для оценки охвата тестирования). Обратите внимание, что тесная интеграция Critique с рабочим пространством раз- работчика во многом возможна благодаря хранению рабочих пространств в рас- пределенной файловой системе FUSE, расположенной за пределами компьютера конкретного разработчика. Источник истины находится в облаке и доступен для всех инструментов. Этап 2: запрос на рецензирование После того как автор доведет изменение до желаемого состояния, он может передать его для обзора (рис. 19.5). Найти рецензента в небольшой команде может показать- ся простой задачей, но даже в таком случае желательно равномерно распределить рецензирование между членами команды и учитывать такие ситуации, когда кто-то находится в отпуске. Для этого можно создать отдельный электронный адрес, куда будут направляться все запросы на рецензирование, после чего инструмент GwsQ (названный в честь команды Google Web Server, первой предложившей этот прием) на основе своих настроек выберет рецензентов из списка для выполнения обзора. Учитывая размер кодовой базы в Google и количество инженеров, постоянно изме- няющих ее, иногда трудно определить, кто вне вашего проекта лучше подходит для обзора изменений. Поиск рецензентов — сложная задача, которую придется решать, достигнув определенного масштаба кодовой базы. Critique должен поддерживать работу в масштабе и обладает функциональными возможностями для выбора ре- цензентов, обладающих достаточными полномочиями для одобрения изменения. Функция выбора рецензентов учитывает следующие факторы: 402 Глава 19. Critique: инструмент обзора кода в Google y кому принадлежит изменяемый код (см. следующий раздел); y кто лучше всего знаком с кодом (то есть кто недавно его изменял); y кто может заняться обзором (то есть находится на рабочем месте и желательно в том же часовом поясе); y настройки GwsQ в команде. Рис. 19.5. Отправка запроса на рецензирование Выбор рецензента для обзора изменения инициирует отправку запроса на рецензиро- вание. Этот запрос попадает в обработчик «предварительной проверки», подходящий для изменения: команды могут по-разному настраивать обработчики, связанные с их проектами. Чаще всего используются обработчики: y автоматически добавляющие изменение в списки рассылки для повышения осве- домленности и прозрачности; y выполняющие автоматизированные наборы тестов для проекта; y добавляющие постоянные элементы в код (для соблюдения локальных ограни- чений оформления кода) и в описание изменения (для создания примечаний к версии и добавления другой информации). Поскольку для тестирования требуются значительные ресурсы, в Google тесты вы- полняются в ходе предварительной проверки (запускаются при отправке запроса на рецензирование и при фиксации изменений в репозитории), а не для каждого снимка, как, например, анализ с помощью Tricorder. Critique отображает результаты выполнения обработчиков, подобно результатам инструментов анализа, но с важным отличием — неудачный результат блокирует отправку изменения на обзор или его фиксацию. Critique уведомляет автора по электронной почте, если предварительная отправка изменения не удалась. Этапы 3 и 4: исследование и комментирование изменения 403 Этапы 3 и 4: исследование и комментирование изменения После начала процесса обзора автор и рецензенты вместе работают над дости- жением общей цели — повысить качество кода изменения и зафиксировать его в репозитории. Комментирование Комментирование — второе по распространенности действие, которое пользователи выполняют в Critique после просмотра изменений (рис. 19.6). Комментирование в Critique открыто для всех. Оставить свой комментарий может кто угодно, а не только автор изменения и назначенные рецензенты. Также Critique дает возможность следить за тем, как протекает процесс обзора. Рецен- зенты могут устанавливать флажки, отмечая отдельные файлы в последнем снимке как проверенные. Когда автор изменяет файл, флажки «проверен», установленные всеми рецензентами, снимаются с этого файла. Рис. 19.6. Комментирование в представлении различий Увидев результат анализа, рецензент может щелкнуть на кнопке Please fix (Исправь- те), чтобы создать нерешенный комментарий с просьбой к автору отреагировать на замечание. Рецензенты также могут предложить свое исправление, напрямую отредактировав последнюю версию файла. Critique превратит это действие в ком- ментарий с исправлением, которое автор сможет применить к коду. 404 Глава 19. Critique: инструмент обзора кода в Google Critique не накладывает ограничений на комментарии, создаваемые пользователями, но предоставляет ярлыки для быстрого ответа на некоторые общие комментарии. Автор изменения может щелкнуть на кнопке Done (Готово) в панели комментари- ев, чтобы сообщить о своей реакции на комментарий рецензента, или на кнопке Ack (Подтвердить), чтобы подтвердить, что комментарий был прочитан, — так обычно поступают с информационными комментариями или комментариями, не требую- щими выполнения каких-либо действий. В обоих случаях цепочки комментариев отмечаются как решенные. Эти кнопки упрощают рабочий процесс и сокращают время, необходимое для ответа на комментарии рецензентов. Как упоминалось выше, комментарии создаются по мере исследования изменения, а затем «публикуются» вместе (рис. 19.7). Это позволяет авторам и рецензентам проверить правильность своих комментариев перед их отправкой. Рис. 19.7. Подготовка комментариев для автора Выяснение состояния изменения В Critique есть ряд механизмов, позволяющих понять, на каком этапе в процессе «комментировать и повторить» находится изменение в данный момент. К ним от- носится возможность определения, кто должен сделать следующий шаг, а также панель мониторинга для всех изменений, в рецензировании или разработке которых принимает участие конкретный разработчик. Этапы 3 и 4: исследование и комментирование изменения 405 Возможность определения «чей ход» Одним из факторов ускорения процесса обзора является информирование о том, кому принадлежит следующий ход, особенно когда обзор изменения назначен нескольким рецензентам. Такое случается, когда автор желает, чтобы его изменение было рас- смотрено инженером-программистом и лицом, отвечающим за эргономику пользо- вательского интерфейса или надежность службы. Critique помогает определить, кто следующим должен рассмотреть изменение, поддерживая набор внимания (attention set) для каждого изменения. Набор внимания определяет группу людей, которые занимаются исследованием изменения в данный момент. Когда рецензент или автор находится в наборе внима- ния, ожидается, что он ответит в ближайшее время. Critique старается своевременно обновлять набор внимания, когда пользователь публикует свои комментарии, но пользователи тоже могут управлять набором внимания. Его полезность возрастает с увеличением количества рецензентов изменения. Набор внимания отображается в Critique с помощью выделения имен пользователей жирным шрифтом. После реализации этой возможности наши пользователи недоумевали: как они обходились без нее раньше? До внедрения этой функции авторам и рецензентам приходилось напрямую общаться друг с другом, чтобы выяснить, кто следующий работает с изменением. Эта функция также подчеркивает поэтапный характер обзора кода, в котором право действовать всегда принадлежит хотя бы одному человеку. Панель мониторинга и поисковая система На главной странице пользователя Critique отображается панель мониторинга (рис. 19.8). Она состоит из разделов, настраиваемых пользователем, каждый из которых содержит сводную информацию об изменениях. Страница с панелью мониторинга использует поисковую систему Changelist Search, которая индексирует последнее состояние всех доступных изменений (до и после отправки в репозиторий) для всех пользователей в Google и позволяет искать измене- ния с помощью запросов на основе регулярных выражений. Каждый раздел в панели мониторинга определяется запросом к системе Changelist Search. Мы потратили немало времени, чтобы сделать поиск в Changelist Search достаточно быстрым для интерактивного использования. Теперь индексирование в ней выполняется очень быстро, чтобы авторы и рецензенты не тратили время на ожидание, несмотря на то что в Google одновременно создается огромное количество изменений. Для удобства в первом разделе панели мониторинга Critique по умолчанию ото- бражаются изменения, требующие внимания пользователя, но это условие можно настроить. Также в ней есть панель для поиска по всем изменениям и просмотра результатов. Рецензентам обычно нужен только набор внимания, а авторам — список их изменений, ожидающих обзора, чтобы узнать, не пора ли проверить комментарии. Мы старались не давать инженерам слишком широких возможностей в настройке пользовательского интерфейса Critique, но обнаружили, что пользователям так же 406 Глава 19. Critique: инструмент обзора кода в Google нравится настраивать информационные панели по-своему, как и организовывать свою электронную почту 1 Рис. 19.8. Панель мониторинга Этап 5: одобрение изменений (оценка изменений) Чтобы выразить свое мнение об изменении, рецензент должен оставить свои ком- ментарии и предложения. Также должен быть какой-то механизм для выражения общего одобрения изменения. В Google он складывается из трех слагаемых: y отметка LGTM; y одобрение; y отсутствие нерешенных комментариев. Отметка LGTM, выставленная рецензентом, означает: «Я осмотрел это изменение и считаю, что оно соответствует нашим стандартам и его можно зафиксировать после разрешения нерешенных комментариев». Одобрение означает: «Как цензор я раз- решаю зафиксировать это изменение в кодовой базе». Рецензент может добавить комментарии, отмеченные как нерешенные, чтобы потребовать от автора предпри- 1 Централизованные «глобальные» рецензенты крупномасштабных изменений склонны на- страивать эту информационную панель, чтобы избежать ее переполнения во время обзора таких изменений (глава 22). Этап 5: одобрение изменений (оценка изменений) 407 нять какие-то действия. Если у изменения имеется хотя бы одна отметка LGTM, достаточное количество одобрений и отсутствуют нерешенные комментарии, автор сможет зафиксировать это изменение в репозитории. Обратите внимание, что для каждого изменения требуется хотя бы одна отметка LGTM, независимо от наличия одобрений, которая гарантирует, что как минимум две пары глаз рассмотрели из- менение. Это простое правило оценки позволяет Critique уведомить автора, когда изменение будет готово к фиксации (отображается на видном месте в виде зеленого заголовка страницы). В процессе создания Critique мы сознательно решили упростить систему отметок. Изначально Critique содержал оценку «Needs more work» («Требуется доработка»), а также «LGTM++». Впоследствии мы остановились на модели, требующей только комбинации отметки LGTM и одобрения. Если изменение нуждается в повторном обзоре, основные рецензенты могут добавлять комментарии, но без отметки LGTM или одобрения. После того как изменение достигнет состояния «почти готово», рецензенты обычно доверяют авторам внести небольшие правки без необходимо- сти повторно обращаться за получением отметки LGTM независимо от размера изменения. Эта система оценок оказала положительное влияние на культуру обзора кода. Рецензенты не могут просто отвергнуть изменение, не добавив полезный коммен- тарий. Все отрицательные отзывы от рецензентов должны быть связаны с чем-то конкретным, что необходимо исправить (например, с нерешенным комментарием). Фраза «нерешенный комментарий» тоже была специально выбрана как наиболее точная. Critique отображает панель оценки рядом со значками инструментов анализа и вы- водит в ней следующую информацию: y кто поставил оценку LGTM; y чье одобрение еще необходимо получить и почему; y сколько нерешенных комментариев осталось. Такое представление информации об оценках помогает автору быстро понять, что еще он должен сделать, чтобы зафиксировать изменение. Отметка LGTM и одобрение строго необходимы и ставятся только рецензентами. Также рецензенты в любой момент могут отозвать свои отметки LGTM и одобре- ния, пока изменения не зафиксированы. Нерешенные комментарии — это мягкие требования. Отвечая на комментарий, автор может отметить его как решенный. Это способствует воспитанию доверия и общению между автором и рецензентами. Например, рецензент может поставить отметку LGTM и добавить нерешенные комментарии, не проверяя впоследствии, были ли они решены, что подчеркивает доверие рецензента к автору. Это доверие особенно важно для экономии времени, когда автор и рецензент находятся в разных часовых поясах. Выражение доверия — хороший способ укрепить отношения и сплотить команду. 408 Глава 19. Critique: инструмент обзора кода в Google Этап 6: фиксация изменения И последний важный этап: в Critique есть кнопка для фиксации изменения после об- зора, которая запрещает возможность переключения в интерфейс командной строки. После фиксации: история изменений Кроме основной роли инструмента для обзора кода перед фиксацией изменений в репозитории Critique выступает в роли инструмента для археологических изы- сканий среди изменений. Для большинства файлов разработчики могут видеть список изменений, которые привели файл к текущему состоянию в системе Code Search (глава 17), или перейти непосредственно к изменению. Любой инженер в Google может просмотреть историю изменений общедоступных файлов, включая комментарии и последовательность развития изменения. Эта информация может использоваться для аудита и изучения причин, почему были внесены изменения или как появились ошибки. Разработчики могут использовать Critique, чтобы узнать, как были спроектированы изменения, а результаты обзора кода применить для обучения. Critique также поддерживает возможность добавления комментариев после фик- сации изменения, например когда обнаружена проблема или требуется внести до- полнительные сведения для будущих читателей. Critique также позволяет отменить изменение и проверить, было ли конкретное изменение отменено. КЕЙС: GERRIT Critique недоступен извне из-за его тесной связи с нашим большим монолитным репозито- рием и другими внутренними инструментами. По этой причине некоторые наши команды, работающие над проектами с открытым исходным кодом (включая Chrome и Android) или внутренними проектами, которые не могут размещаться в монолитном репозитории, используют другой инструмент обзора кода — Gerrit. Gerrit — это самостоятельный инструмент с открытым исходным кодом, предназначенный для рецензирования и тесно интегрированный с Git. Он предлагает веб-интерфейс с под- держкой многих функций Git, включая просмотр кода, слияние ветвей, выбор версий и, конечно, обзор кода. Кроме того, Gerrit имеет обширную модель разрешений, которую можно использовать для ограничения доступа к репозиториям и ветвям. Оба инструмента, Critique и Gerrit, используют одну и ту же модель обзора кода, в которой каждая фиксация проверяется отдельно. Gerrit поддерживает объединение нескольких из- менений и их выгрузку для отдельного обзора, а также позволяет атомарно фиксировать цепочки изменений после обзора. Как инструмент с открытым исходным кодом, Gerrit предлагает больше вариантов исполь- зования: богатая система плагинов Gerrit обеспечивает возможность тесной интеграции в пользовательские среды. Для поддержки разных вариантов использования Gerrit также имеет сложную систему оценки. Рецензент может наложить вето на изменение, поставив оценку -2, а сама система оценок может настраиваться в весьма широких пределах. Заключение 409 Получить дополнительную информацию о Gerrit и увидеть его в действии можно по адресу: https://www.gerritcodereview.com. Заключение Использование инструмента обзора кода требует неявных компромиссов. Время, потраченное на обзор кода, не связано с созданием нового кода, поэтому любая оп- тимизация процесса обзора может повысить продуктивность компании. Если для фиксации изменения (в большинстве случаев) достаточно согласия только двух человек (автора и рецензента), то скорость обзора будет высокой. В Google ценят образовательные аспекты обзора кода, несмотря на то что их трудно измерить. Чтобы процесс обзора изменения выполнялся быстро, он должен протекать бес- препятственно, своевременно информировать пользователя об аспектах, требующих внимания, и выявлять потенциальные проблемы до этапа рецензирования (проблемы выявляются инструментами анализа и системой непрерывной интеграции). По воз- можности результаты проверки более быстрыми инструментами представляются до завершения проверки более медленными инструментами. В инструменте Critique есть несколько путей поддержки масштаба. Он обрабатывает большое количество запросов на рецензирование без снижения производительности. Поскольку Critique находится на пути к фиксации изменений, он быстро загружается и всегда готов для использования в особых ситуациях, таких как необычно большие изменения 1 . Интерфейс Critique оказывает поддержку пользователям (например, в поиске релевантных изменений) и помогает рецензентам и авторам перемещаться по кодовой базе. Например, Critique сам подбирает подходящих рецензентов для обзора конкретного изменения, не требуя от инженеров выяснять, кто владеет кодом или сопровождает его (это особенно важно для крупномасштабных изменений, таких как миграция на другой API, которая может затронуть многие файлы). Critique упорядочивает процесс обзора кода и предоставляет удобный интерфейс. При этом он допускает настройки, позволяя применить в обзоре инструменты анализа и предварительные обработчики, формирующие контекст для изменений, а также правила, характерные для команды (например, требование отметки LGTM от нескольких рецензентов). Доверие и общение — вот основа процесса обзора кода. Инструмент может дополнить опыт инженера, но не может заменить его. Также важным фактором успеха Critique является его тесная интеграция с другими инструментами. 1 Большинство изменений имеет небольшой размер (менее 100 строк), однако иногда Critique используется для обзора крупных изменений после рефакторинга, которые могут затрагивать сотни и тысячи файлов и должны выполняться атомарно (глава 22). |