Делай как вGoogle
 Скачать 5.77 Mb.
|
|
168 Глава 8. Правила и руководства по стилю длины строк перестала существовать 1 . Инженеры просто запускают программы проверки стиля и продолжают двигаться вперед. Единый способ форматирования устраняет циклы рецензирования, в ходе которых инженер тратит время на поиск, маркировку и исправление незначительных ошибок в оформлении. Управляя самой большой в истории базой кода, мы получили возможность срав- нить результаты форматирования, выполненного людьми и автоматизированными инструментами. В среднем роботы справляются с большими объемами кода лучше людей. Но в некоторых ситуациях знание предметной области имеет значение, на- пример человек лучше справляется с форматированием матрицы, чем универсальный инструмент. В остальных случаях форматирование кода с помощью автоматических инструментов редко выполняется неправильно. Также мы автоматизировали проверку форматирования: перед отправкой кода в ре- позиторий служба проверяет, изменился ли код после его обработки инструментом форматирования. Если изменился, то отправка отклоняется и сопровождается инструкциями, как запустить средство форматирования для исправления кода. Такой предварительной проверке подвергается большая часть кода в Google. Для проверки кода на C++ мы используем clang-format ( https://oreil.ly/AbP3F ); для кода на Python — внутреннюю обертку вокруг yapf ( https://github.com/google/yapf ); для кода на Go — gofmt ( https://golang.org/cmd/gofmt ); для кода на Dart — dartfmt и для файлов BUILD — buildifier ( https://oreil.ly/-wyGx ). Заключение В любой инженерной организации, особенно в такой большой, как Google, правила помогают управлять сложностью процессов и создавать устойчивую кодовую базу. Общий набор правил направляет инженерные процессы на расширение и рост и обе- спечивает долгосрочную поддержку кодовой базы и самой организации. Итоги y Правила и руководства должны быть нацелены на поддержание устойчивости и масштабирование. y Корректировки правил должны быть обоснованы данными. y Правил не должно быть слишком много. y Единообразие — ключ к успеху. y Автоматизация контроля за соблюдением правил должна применяться везде, где возможно. 1 Если учесть, что для обсуждения требуется не менее двух инженеров, умножьте это число на количество раз, когда такое обсуждение может случиться в команде, насчитывающем более 30 000 инженеров, и вы убедитесь, насколько дорогостоящим может стать решение проблемы «количества символов в строке». ГЛАВА 9 Код-ревью Авторы: Том Маншрек и Кейтлин Садовски Редактор: Лиза Кэри Код-ревью, или обзор кода, — это процесс проверки внесенных в код изменений со- трудником, который не является их автором, часто до передачи кода в репозиторий. Определение выглядит простым, но реализации процесса обзора кода сильно отли- чаются в индустрии ПО. В одних организациях вносимые изменения просматривает отдельная группа «цензоров» всей кодовой базы. В других обзоры кода делегируются небольшим командам, что позволяет разным командам требовать разные уровни проверки кода. В Google практически каждое изменение проверяется перед его отправкой в репозиторий и каждый инженер отвечает за инициирование обзоров и проверку изменений. Обзоры кода обычно представляют собой комбинацию процесса и инструмента, поддерживающего этот процесс. Мы в Google используем для проверки кода спе- циальный инструмент Critique 1 , обсуждение которого достойно отдельной главы в этой книге. А сейчас мы представим идеи, связанные с самим процессом обзора кода в Google, которые можно применить к любому специальному инструменту. Дополнительная информация о Critique в главе 19. Некоторые из преимуществ обзора кода, такие как выявление ошибок до того, как они окажутся в кодовой базе, хорошо известны 2 и даже очевидны (если не измерены точно). Но у него есть и скрытые преимущества: процесс обзора кода в Google настолько вездесущий и обширный, что мы смогли отследить другие его аспекты, в том числе психологические, играющие роль в экономии времени и масштабировании. 1 Также для проверки кода в Git мы используем Gerrit ( https://www.gerritcodereview.com ), но в первую очередь для проектов с открытым исходным кодом. То есть Critique — основной инструмент типичного инженера-программиста в Google. 2 Макконнелл С. Совершенный код. Мастер-класс. М.: Русская редакция и Microsoft Press, 2017. — Примеч. пер. 170 Глава 9. Код-ревью Поток обзора кода Обзоры кода могут выполняться на разных этапах разработки ПО. В Google обзоры кода выполняются до того, как изменения попадут в кодовую базу, — этот этап мы называем предварительной проверкой. Основная цель обзоров кода — получить от инженера, который не является автором данного кода, отметку LGTM («looks good to me» — «хорошо для меня»). Мы используем эту отметку как необходимый «элемент» разрешения на внесение изменения (остальные элементы обсудим ниже). Типичный обзор кода в Google включает следующие этапы: 1. Пользователь-автор вносит изменения в кодовую базу в своем рабочем про- странстве. Затем он создает снимок изменений — файл исправлений (patch-файл) и их описание — и выгружают его в инструмент обзора кода. Для выявления из- менений этот инструмент создает diff-файл, содержащий отличия нового кода от старой кодовой базы. 2. Автор может использовать diff-файл также для комментирования автоматическо- го обзора. Убедившись, что diff-файл точно и полно отражает изменения, автор от- правляет его одному или нескольким рецензентам по электронной почте. Рецензен- ты получают уведомление с просьбой просмотреть и прокомментировать снимок. 3. Рецензенты открывают diff-файл в инструменте обзора кода и добавляют к нему комментарии. Некоторые комментарии явно требуют исправить выявленные ошибки. Другие носят чисто информационный характер. 4. Автор вносит необходимые исправления, выгружает новый снимок, полученный на основе отзывов, а затем отправляет его рецензентам. Шаги 3 и 4 могут повто- ряться несколько раз. 5. Если рецензенты удовлетворены состоянием изменений, они дают им отметку LGTM. По умолчанию требуется только одна отметка LGTM, но соглашение может потребовать, чтобы с изменениями согласились все рецензенты. 6. Автор фиксирует изменения, отмеченные LGTM, в кодовой базе при условии, что он учел все комментарии и изменения одобрены. Процедуру одобрения мы рассмотрим в следующем разделе. Далее в этой главе мы обсудим этот процесс более подробно. Как проводятся обзоры кода в Google Мы уже рассказали, как примерно выглядит типичный процесс обзора кода, но, как всегда, дьявол кроется в деталях. В этом разделе мы подробно опишем, как методы обзора кода в Google позволяют масштабировать это процесс. Процесс обзора кода в Google имеет три вида «одобрения» любого изменения. y Проверка и оценка правильности измененного кода и его соответствия заяв- ленным целям других инженеров — часто членам команды автора изменения. Выражается в отметках LGTM. Как проводятся обзоры кода в Google 171 y Одобрение одного из владельцев кода, подтверждающее, что код подходит для конкретной части кодовой базы (и может быть сохранен в определенный каталог). Это одобрение может быть неявным, если владельцем кода является автор изме- нения. База кода в Google — это древовидная структура с иерархией владельцев каталогов (глава 16). Владельцы действуют как «цензоры» своих каталогов. Изменение предлагает любой инженер, отметку LGTM ставит любой другой инженер, а добавление изменения в часть кодовой базы одобряет владелец соот- ветствующего каталога. Таким владельцем может быть технический руководитель или инженер-эксперт в конкретной области кодовой базы. Как правило, каждая команда сама закрепляет области кода за их владельцами. y Одобрение от обладателя сертификата удобочитаемости для данного языка 1 , подтверждающее, что код соответствует стилю языка и передовым практикам. Это одобрение тоже может быть неявным, если автор изменения обладает серти- фикатом удобочитаемости, или явным, если оно получено от другого инженера, уполномоченного проверять удобочитаемость на соответствующем языке про- граммирования. КОД — ЭТО ОТВЕТСТВЕННОСТЬ Важно помнить (и понимать), что код сам по себе является ответственностью, поскольку в будущем он обслуживается не его автором. Код похож на топливо — груз, без которого самолет не полетит ( https://oreil.ly/TmoWX ). Добавлять новые возможности стоит, только если они действительно нужны. Повторяю- щийся код — это не только пустая трата сил, но и лишние затраты. Изменить один паттерн в кодовой базе намного легче, чем множество повторяющихся фрагментов. К написанию совершенно нового кода у нас относятся настолько неодобрительно, что появилась пого- ворка: «Если ты пишешь код с нуля, значит, делаешь это неправильно!» Это особенно верно для библиотечного или служебного кода. Если вы пишете утилиту, скорее всего, учитывая размер кодовой базы Google, кто-то еще уже написал нечто подобное. Поэтому инструменты, описанные в главе 17, имеют большое значение как для поиска по- вторяющегося кода, так и для предотвращения дублирования. Чтобы выявить дубликаты как можно раньше, нужно показать проект новой утилиты ответственным командам до того, как к ней будет написан код. Конечно, появляются новые проекты, внедряются новые технологии, добавляются новые компоненты и т. д. Но обзор кода не является поводом для переосмысления или обсуждения предыдущих проектных решений. На выработку проектных решений часто требуется много времени для обмена предложениями, обсуждения дизайна (в обзорах API или на встречах) и, возможно, разработки прототипов. В той же мере, в какой обзор совершенно нового кода не должен происходить внезапно, сам процесс рецензирования не должен рассматриваться как возможность пересмотреть предыдущие решения. 1 В Google под «удобочитаемостью» подразумевается не только простота понимания, но также использование набора стилей и передовых практик, помогающих другим инженерам сопровождать код. Подробнее о контроле удобочитаемости в главе 3. 172 Глава 9. Код-ревью Хотя такая форма контроля выглядит обременительной — и, по общему мнению, такой и является, — в большинстве случаев все три роли принимает на себя один человек, что значительно ускоряет процесс обзора кода. Важно отметить, что две по- следние роли может взять на себя сам автор кода, и ему останется только получить LGTM от другого инженера. Эти требования делают процесс обзора кода достаточно гибким. Технический руко- водитель, который является владельцем проекта и обладает сертификатом удобо- читаемости для этого кода, может отправить изменение в кодовую базу на основании LGTM от другого инженера. Инженер без таких полномочий может отправить такое же изменение в ту же кодовую базу при условии, что он получит одобрение от владель- ца с сертификатом удобочитаемости для данного языка. Три вышеупомянутых одо- брения могут объединяться в любой комбинации. Автор может даже запросить более одного LGTM, явно пометив изменение как получившее LGTM от всех рецензентов. Чаще всего обзоры выполняются в два этапа: получение LGTM от инженера-кол- леги, а затем получение одобрения у соответствующего владельца(-ев) кода и/или рецензента(-ов) удобочитаемости. Это позволяет одобряющим инженерам сосредо- точиться на разных аспектах и сэкономить время, необходимое для обзора. Первый рецензент может сосредоточиться на правильности кода, а владелец кодовой базы — на необходимости изменения, без учета деталей в каждой строке. Другими словами, владелец часто ищет нечто иное, чем рецензент. Наконец, тех, кто хочет принять код в свой проект/каталог, волнуют вопросы: «Насколько сложно поддерживать этот код?», «Увеличит ли он мой технический долг?», «Достаточно ли опыта в нашей команде для его поддержки?» Если все обзоры всех трех типов могут выполняться одним человеком, почему бы просто не поручить таким сотрудникам проводить все обзоры кода? Ответ прост: такой подход не масштабируется. Разделение ролей добавляет гибкости процессу обзора кода. Если вы работаете с коллегой над новой функцией в библиотеке, то можете попросить кого-то из вашей команды проверить правильность и удобочи- таемость кода. После нескольких раундов (возможно, в течение нескольких дней) ваш код удовлетворит рецензента и вы получите LGTM. После этого вам останется только получить одобрение владельца библиотеки (часто имеющего сертификат удобочитаемости), чтобы утвердить изменение. Преимущества обзоров кода Сами по себе обзоры кода не вызывают споров. Многие (возможно, даже большин- ство) компании и проекты с открытым исходным кодом имеют некоторую форму обзоров кода и считают этот процесс не менее важным, чем проверка работоспособно- сти при добавлении нового кода в репозиторий. Инженеры-программисты понимают некоторые из наиболее очевидных преимуществ обзоров кода, даже если считают, что эта практика применима не во всех случаях. Но в Google этот процесс, как пра- вило, более тщательный и распространенный, чем в большинстве других компаний. Преимущества обзоров кода 173 ВЛАДЕНИЕ Хайрам Райт В небольшой команде выделенный доступ к коду в отдельном репозитории обычно рас- пространяется на всех членов команды. В конце концов, они друг друга хорошо знают и предметная область достаточно узкая, чтобы каждый мог быть экспертом, а небольшой объем кода ограничивает влияние потенциальных ошибок. По мере увеличения численности команды такой подход перестает масштабироваться. В результате происходит беспорядочное разделение репозитория: неясно, кто и какими знаниями обладает и какие обязанности выполняет в разных частях репозитория. Мы в Google называем эту совокупность знаний и обязанностей владением, а ее носителей — владельцами. Эта идея отличается от владения коллекцией исходного кода и скорее под- разумевает разделение базы кода в интересах компании. (Если бы нам снова пришлось вводить культуру владения кодом, мы наверняка выбрали бы термин «распоряжение».) Специальные файлы с названием OWNERS содержат списки пользователей, которые несут ответственность за каталог и его элементы. Эти файлы могут также содержать ссылки на другие файлы OWNERS или внешние списки управления доступом, но в конечном итоге образуют список лиц. Каждый подкаталог может содержать свой файл OWNERS, при этом файлы в дереве каталогов связаны аддитивным отношением: файл обычно включает всех пользователей, перечисленных в файлах OWNERS, расположенных выше в дереве ката- логов. В файлах OWNERS может быть столько записей, сколько пожелает команда, но мы рекомендуем сохранять списки относительно небольшими и точными, чтобы гарантировать ясность разделения зон ответственности. Владение кодом в Google дает сотруднику право на одобрение изменений в этом коде. Владелец должен сам понимать код или знать, кому задавать вопросы по коду. В разных командах используются разные способы передачи права владения новым членам команды, но мы рекомендуем не использовать это право в качестве обряда посвящения и призываем уходящих членов команд незамедлительно уступать права владения. Распределенная организация владения позволяет использовать методы, представленные в этой книге. Например, инженеры, перечисленные в корневом файле OWNERS, могут выступать в роли лиц, утверждающих крупномасштабные изменения (глава 22) без при- влечения членов локальных команд. Точно так же файлы OWNERS действуют подобно документации, позволяя людям и инструментам легко находить ответственных за данный фрагмент кода: достаточно просто пройти вверх по дереву каталогов. У нас нет центрального органа, который регистрирует новые права владения в новых проектах: для присвоения прав владения достаточно создать новый файл OWNERS. Это простой, но весьма действенный механизм владения, и за последние два десятилетия он значительно расширился. С его помощью Google гарантирует эффективную работу десятков тысяч инженеров с миллиардами строк кода в одном репозитории. Культура Google, как и многих софтверных компаний, основана на предоставле- нии инженерам широких возможностей. Многие считают, что строгие процессы плохо работают в динамично развивающихся компаниях, которым приходится быстро реагировать на появление новых технологий, и бюрократические правила отрицательно влияют на творческую работу. Однако в Google обзоры кода — это обязательное мероприятие, в котором должны участвовать все инженеры-програм- 174 Глава 9. Код-ревью мисты и практически 1 все изменения в кодовой базе. Это требование влечет затраты и влияет на скорость разработки, замедляя внедрение нового кода и его передачу в производство. (Инженеры-программисты часто жалуются на строгость обзоров кода.) Тогда зачем нам этот процесс? Почему мы считаем, что он приносит выгоду в долгосрочной перспективе? Хорошо продуманный процесс обзора кода обеспечивает следующие преимущества: y проверку правильности кода; y гарантию понятности изменения для других инженеров; y обеспечение согласованности всей кодовой базы; y воспитание командной ответственности; y возможность обмена знаниями; y хронологическую запись принятия решений об изменениях. С течением времени многие из этих преимуществ приобретают особую важность для авторов изменений, рецензентов и организации в целом. Рассмотрим указанные преимущества подробнее. Правильность кода Очевидным преимуществом процесса обзора кода является возможность проверить «правильность» изменения. Рецензент, который не является автором изменения, проверяет, было ли изменение должным образом протестировано, правильно ли оно спроектировано и насколько эффективно оно функционирует. В основном проверка правильности кода ориентирована на выявление потенциальных ошибок в базе кода, которые может вызвать конкретное изменение. Многие отмечают, что основной эффект от обзоров кода заключается в предотвра- щении появления ошибок в ПО. Исследование, проведенное в IBM, показало, что ошибки, обнаруженные на более ранних этапах разработки, можно исправить бы- стрее, чем ошибки, обнаруженные на более поздних этапах 2 . Время, потраченное на обзор кода, экономит время на тестирование, отладку и устранение регрессий при условии, что сам процесс обзора кода необременителен. Трудоемкие или неправиль- но масштабированные процессы обзора кода менее надежны 3 . Мы дадим некоторые рекомендации по упрощению обзора кода в этой главе. 1 Некоторые изменения в документации и конфигурациях могут добавляться без обзора кода, но обычно мы настаиваем на прохождении этой процедуры. 2 «Advances in Software Inspection», IEEE Transactions on Software Engineering, SE-12(7): 744–751, July 1986. Конечно, это исследование проводилось до появления надежных инструментов и автоматизированных процессов тестирования в сфере разработки ПО, но его результаты остаются актуальными и в наше время. 3 Rigby P. C., Bird C. 2013. Convergent software peer review practices. ESEC/FSE 2013: Proceedings of the 2013 9th Joint Meeting on Foundations of Software Engineering, August 2013: 202–212. https://dl.acm.org/doi/10.1145/2491411.2491444 |