Делай как вGoogle
 Скачать 5.77 Mb.
|
|
Заключение Система сборки — одна из самых важных частей инженерной организации. Каждый разработчик взаимодействует с ней десятки и сотни раз в день, и часто это может оказаться ограничивающим фактором для его продуктивности. Поэтому качество работы системы сборки заслуживает внимания. Один из самых удивительных уроков, извлеченных в Google, заключается в том, что ограничение возможностей и гибкости может повысить производительность инже- неров. Мы смогли создать систему сборки, которая отвечает нашим потребностям. Она не дает инженерам свободу определять, как выполнять сборку, но предлагает четко структурированную среду, которая выполняет наиболее интересные решения с помощью автоматизированных инструментов. И как ни странно, инженеров это не возмущает: гуглерам нравится, что эта система работает почти сама по себе и по- зволяет им сосредоточиться на более интересных аспектах разработки приложений. Доверие к системе сборки позволяет легко выполнять инкрементальные сборки без очистки кешей сборки или применения clean Опираясь на полученный опыт, мы создали систему сборки совершенно нового типа — на основе артефактов, — существенно отличающуюся от традиционных систем сборки на основе задач. Переосмысление подходов к сборке позволило масштабировать ее процессы до размеров Google. Новые подходы позволяют создать распределенную систему сборки, которая может использовать ресурсы всего вычислительного кла- стера для повышения производительности инженеров. Конечно, ваша организация может быть не настолько большой, чтобы извлечь выгоду из подобных инвестиций, но мы считаем, что системы сборки на основе артефактов могут масштабироваться не только вверх, но и вниз: даже небольшие проекты системы сборки, такие как Итоги 393 Bazel, могут дать значительные преимущества с точки зрения скорости выполнения и безошибочности. В этой главе мы также рассмотрели особенности управления зависимостями в мире, основанном на артефактах, и пришли к выводу, что дробление кода на мелкие модули масштабируется лучше. Мы также обсудили трудности управления версиями за- висимостей и правило единственной версии и отметили, что для всех зависимостей следует явно и вручную определять их версии. Эти приемы помогают миновать известные ловушки, такие как проблема ромбовидной зависимости, и работать с базами кода масштаба Google, насчитывающими миллиарды строк кода в едином репозитории с единой системой сборки. Итоги y Для продуктивной работы разработчиков с ростом организации необходима полноценная система сборки. y Мощность и гибкость системы сборки имеют свою цену. Выбор правильных ограничений для системы сборки упрощает ее использование. y Системы сборки, организованные вокруг артефактов, обычно лучше масшта- бируются и более надежны, чем системы сборки, организованные вокруг задач. y При определении артефактов и зависимостей лучше стремиться разбивать код на более мелкие модули, потому что при этом полнее используются преимущества параллельной и инкрементальной сборки. y Версии внешних зависимостей должны явно указываться в VCS. Использова- ние «последних» версий приводит к катастрофическим и невоспроизводимым сборкам. ГЛАВА 19 Critique: инструмент обзора кода в Google Авторы: Кейтлин Садовски, Ильхам Курния и Бен Рольфс Редактор: Лиза Кэри Как мы уже писали в главе 9, обзор кода является жизненно важной частью разра- ботки ПО, особенно в больших масштабах. Основная цель обзора кода — улучшить удобочитаемость и простоту поддержки кодовой базы, и достижение этой цели обес- печивается процессом обзора и инструментами, поддерживающими этот процесс. В этой главе мы посмотрим, как в Google проводится обзор кода с использованием собственного инструмента Critique. Он явно поддерживает основные цели рецен- зирования, давая рецензентам и авторам возможность исследовать и комментиро- вать изменения. Также Critique дает возможность фильтровать код, поступающий в кодовую базу (см. раздел, посвященный «оценке» изменений). Информация из Critique используется при поиске причин технических решений по диалогам в об- зорах кода (например, когда отсутствуют встроенные комментарии). Critique — не единственный, но самый популярный инструмент обзора кода в Google. Принципы оснащения обзора кода инструментами Выше упоминалось, что Critique предоставляет необходимые функции поддержки целей обзора кода (мы рассмотрим их далее в этой главе), но почему этот инструмент пользуется таким успехом? Critique сформирован культурой разработки в Google, в которой обзор кода является неотъемлемой частью рабочего процесса. Это куль- турное влияние выражается в наборе руководящих принципов, которые Critique подчеркивает: Простота Пользовательский интерфейс Critique создавался с целью упростить обзоры кода. Он не имеет лишних элементов управления, работает очень гладко, быстро загружается, имеет простую навигацию, поддерживает горячие клавиши, а также четкие визуальные индикаторы, сообщающие, было ли проверено то или иное изменение. Процесс обзора кода 395 Доверие Обзоры кода должны не замедлять работу инженеров, а расширять их возмож- ности. Они основываются на максимальном доверии к коллегам, например к авто- рам изменений. Расширению доверия способствует также общедоступность (для просмотра и проверки) изменений в Google. Универсальная коммуникация Сложности с коммуникацией редко решаются с помощью инструментов. Critique отдает приоритет универсальным способам комментирования изменений в коде, а не сложным протоколам. Вместо того чтобы усложнять модель данных и про- цесс, Critique поощряет пользователей пояснять в своих комментариях, чего они хотят, и предлагает правки к комментариям. Но даже с использованием лучшего инструмента обзора кода коммуникация может не получаться, потому что поль- зователи — это люди. Интеграция в рабочий процесс Critique имеет ряд точек интеграции с другими инструментами разработки ПО. Разработчики с легкостью могут переходить от просмотра проверяемого кода в Code Search к правке в веб-инструменте редактирования кода или к просмотру результатов тестирования изменений. Из всех этих руководящих принципов наибольшее влияние на инструмент оказала простота. Изначально мы думали о добавлении множества интересных возможностей, но потом решили не усложнять модель, чтобы обеспечить поддержку максимально широкого круга пользователей. Простота также имеет интересное противоречие с интеграцией Critique в рабочий процесс. Мы рассматривали возможность создания единого инструмента Code Central для правки, обзора и поиска кода, но потом отказались от этой идеи. Critique имеет множество точек соприкосновения с другими инструментами, но мы сознательно решили нацелить его на обзор кода. Многие возможности, доступные в Critique, реализованы в разных подсистемах. Процесс обзора кода Обзоры кода могут выполняться на разных этапах разработки ПО (рис. 19.1). Обычно они проводятся до передачи изменений в кодовую базу, поэтому их называют обзо- рами перед передачей в репозиторий. Краткое описание процесса проверки кода уже приводилось в главе 9, но мы повторим его здесь, дополнив некоторыми ключевыми аспектами Critique. В следующих разделах мы подробно рассмотрим каждый этап. Вот типичные этапы обзора кода: 1. Добавление изменений. Пользователь вносит изменение в код в своем рабочем пространстве. Затем автор выгружает снимок (отражающий изменения в опре- деленный момент) в Critique, который запускает инструменты автоматического анализа кода (глава 20). 396 Глава 19. Critique: инструмент обзора кода в Google Добавление изменений Запрос на рецензирование Комментирование Правка изменений, ответы на комментарии Отправка изменений Одобрение изменений Рис. 19.1. Процесс обзора кода 2. Запрос на рецензирование. Закончив вносить изменения и удовлетворившись результатами автоматического анализа в Critique, автор отправляет изменение одному или нескольким рецензентам по электронной почте. 3. Комментирование. Рецензенты открывают изменение в Critique и добавляют свои комментарии. По умолчанию комментарии отмечаются как нерешенные, то есть требующие реакции автора. Также рецензенты могут добавлять решенные комментарии, которые не требуют реакции автора и имеют исключительно ин- формационный характер. Результаты автоматического анализа кода, если они есть, также доступны рецензентам. После того как рецензент подготовит набор комментариев, он публикует их для автора, выражая свою оценку изменения после его обзора. Прокомментировать изменение может любой желающий в «по- путном обзоре». 4. Правка изменений, ответы на комментарии. Основываясь на комментариях, автор вносит новые правки в изменение, выгружает новые снимки и передает обновленный вариант изменения рецензентам. Автор реагирует (по меньшей мере) на все нерешенные комментарии, либо изменяя код, либо просто отвечая на комментарий и отмечая комментарий как решенный. Автор и рецензенты могут посмотреть различия между любыми парами снимков, чтобы увидеть, что изменилось. Шаги 3 и 4 могут повторяться несколько раз. 5. Одобрение изменений. Удовлетворившись последним состоянием изменения, рецензенты одобряют его и отмечают как «мне нравится» (LGTM). При жела- нии они могут добавить комментарии, требующие решения. После признания изменения пригодным для отправки в репозиторий оно будет отмечено зеленым цветом в пользовательском интерфейсе. 6. Отправка изменений. Если изменение одобрено (как обсуждается ниже), автор может запустить процесс его фиксации. Если инструменты автоматического анализа и другие средства оценки перед отправкой не обнаружили никаких про- блем, изменение фиксируется в кодовой базе. Даже после запуска процесса система позволяет отклониться от типичной процеду- ры обзора. Например, рецензенты могут отказаться от оценки изменений или явно передать эту роль кому-то другому, а автор может вообще приостановить процесс обзора. В экстренных случаях автор может принудительно зафиксировать свое из- менение в репозитории и запросить его обзор после фиксации. Этап 1: добавление изменений 397 Уведомления По мере продвижения изменения через этапы, описанные выше, Critique публикует уведомления о событиях, которые могут использоваться другими вспомогательными инструментами. Модель уведомлений позволяет инструменту Critique оставаться основным средством обзора кода, интегрированным в рабочий процесс разработчика, и не превращаться в многоцелевой инструмент. Уведомления позволяют разделить задачи так, чтобы Critique мог просто посылать события, а другие системы обслу- живали их. Например, пользователи могут установить расширение для Chrome, чтобы под- писаться на эти уведомления. Когда появляется изменение, требующее внимания пользователя, например если настала очередь пользователя оценить изменение или предварительная проверка перед отправкой потерпела неудачу, расширение выводит на экран уведомление с кнопкой для перехода непосредственно к изменению или для отключения уведомления. Мы заметили, что одним разработчикам нравятся немедленные уведомления об обновлении изменений, а другие не пользуются этим расширением, потому что оно мешает работе. Critique может рассылать уведомления по электронной почте. Например, таким способом рассылаются уведомления о наиболее важных событиях. Некоторые ин- струменты автоматического анализа тоже имеют настройки для пересылки резуль- татов по электронной почте дополнительно к их отображению в пользовательском интерфейсе Critique. Кроме того, Critique может обрабатывать ответы по электронной почте и переводить их в комментарии для тех пользователей, которые предпочитают электронную почту. Обратите внимание, что для многих пользователей электронные письма не являются ключевой функцией обзора кода и для управления отзывами они используют панель инструментов Critique (подробнее ниже). Этап 1: добавление изменений Инструмент обзора кода должен обеспечивать поддержку на всех этапах процесса рецензирования и не задерживать фиксацию изменений. На этапе предварительного обзора авторам проще отшлифовать свое изменение перед отправкой на проверку, что помогает сократить время рецензирования. Critique позволяет отображать только значимые различия и игнорировать изменение количества пробелов. Также Critique отображает результаты сборки, тестирования и статического анализа, включая про- верку стиля (глава 9). Critique позволяет автору видеть свои изменения так, как их видят рецензент и ав- томатический анализ, поддерживает возможность корректировки изменения прямо в инструменте обзора и предлагает подходящих рецензентов. Отправляя запрос, автор может добавить предварительные комментарии к изменению, что дает воз- можность напрямую задать рецензентам любые вопросы. Все это предотвращает недопонимание. 398 Глава 19. Critique: инструмент обзора кода в Google Чтобы предоставить рецензентам дополнительную информацию, автор может свя- зать изменение с конкретной ошибкой. Critique использует службу автодополнения, чтобы подсказать соответствующие ошибки, отдавая приоритет ошибкам, устранение которых поручено автору. Представление различий Главная задача обзора кода — упростить понимание изменения. Крупные изменения обычно труднее понять, чем мелкие. Поэтому представление различий в коде, об- условленных изменением, в наиболее простом и понятном виде является основным требованием для хорошего инструмента обзора кода. В Critique этот принцип распространяется на несколько уровней (рис. 19.2). Ком- понент представления различий, начиная с алгоритма оптимизации самой длинной общей подпоследовательности, дополнен следующими возможностями: y подсветка синтаксиса; y поддержка перекрестных ссылок (с помощью Kythe, глава 17); y отображение различий внутри строк, показывающее разницу на уровне символов (рис. 19.2); y настройки, позволяющие игнорировать различия в количестве пробелов; y фрагменты кода, перемещенные из одного места в другое, отмечаются как пере- мещенные, а не удаленные в одном месте и добавленные в другом, как это делают многие алгоритмы сравнения. Рис. 19.2. Отображение различий внутри строк показывает разницу на уровне символов Пользователи также могут просматривать различия в разных режимах, например в режиме наложения или рядом друг с другом. Создавая Critique, мы решили, что важно показать различия рядом друг с другом, чтобы упростить процесс обзора. Такое расположение различий занимает много места, и мы упростили структуру представления различий, отказавшись от границ и отступов и оставив только сами различия и номера строк. Нам пришлось поэкспериментировать с разными шриф- тами и кеглями, пока мы не добились представления различий, которое учитывает ограничение размеров строк в 100 символов в Java и типичную ширину экрана в Critique — 1440 пикселов. Этап 1: добавление изменений 399 Critique также поддерживает дополнительные инструменты, представляющие раз- личия в артефактах, созданных в результате изменения, например снимки пользова- тельского интерфейса или файлы конфигурации, полученные в результате изменения. Чтобы упростить процесс навигации по различиям, мы постарались максимально сэкономить пространство и обеспечить быструю загрузку различий, даже таких, как изображения и большие файлы. Мы также определили комбинации клавиш для быстрой навигации по файлам при обзоре измененных разделов. Когда пользователи переходят на уровень файлов, Critique предоставляет виджет с компактным отображением цепочки версий снимков, с помощью которого поль- зователи могут выбирать интересующие их версии для сравнения. Этот виджет автоматически сворачивает похожие версии, помогая сосредоточить внимание на наиболее важных из них. Благодаря этому пользователь может видеть, как разви- вался файл в ходе изменения, например какие части изменения охвачены тестами, а какие части уже проверены или содержат комментарии. Чтобы решить проблему масштаба, Critique заранее выбирает все необходимое, поэтому загрузка различных снимков выполняется очень быстро. Анализ результатов Выгрузка снимка приводит к запуску автоматических инструментов анализа кода (глава 20). Результаты и обобщенные итоги анализа отображаются в Critique на странице изменения (рис. 19.3). Более подробные детали отображаются во вкладке Analysis (Анализ) (рис. 19.4). Рис. 19.3. Обобщенные итоги анализа и представление различий 400 Глава 19. Critique: инструмент обзора кода в Google Рис. 19.4. Результаты анализа Инструменты анализа могут подсвечивать конкретные результаты красным цветом. Еще не завершенные виды анализа выделяются желтыми значками, а остальные — серыми. Для простоты Critique не предлагает других вариантов выделения. Если тот или иной инструмент возвращает какие-то результаты, их можно открыть щелчком мыши на значке. Подобно комментариям, результаты анализа могут отображаться внутри различий, но оформляются иначе, чтобы их было проще отличить. Иногда результаты анализа включают предложения по исправлению замечаний, которые автор может просмотреть и применить прямо в Critique. Предположим, что инструмент статического анализа обнаруживает нарушение стиля — лишние пробелы в конце строки. На странице изменения появится значок этого инструмента. Щелкнув на нем, автор может быстро перейти к различиям, показывающим код, и парой щелчков мыши исправить нарушение. Большинство замечаний, возвращаемых инструментом статического анализа, также включают предложения по исправлению. Одним щелчком автор может просмотреть пред- лагаемое исправление (например, предложение удалить лишние пробелы), а вто- рым — применить его. Тесная интеграция инструментов В Google есть инструменты, созданные на основе Piper — монолитного репозитория исходного кода (глава 16), например: y Cider — онлайн-IDE для редактирования исходного кода, хранящегося в облаке; y Code Search — инструмент для поиска в кодовой базе; y Tricorder — инструмент для отображения результатов статического анализа (упо- минался выше); |