Структура ревью

Каждая строчка

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

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

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

Отложенные правки

Типичный источник споров заключается в том, что разработчики (по понятным причинам) хотят добиться завершения работы. Они не хотят проходить ещё один раунд ревью для этого CL. Поэтому они говорят, что уберут что-то в более позднем CL, а сейчас вы должны сделать LGTM для этого CL. Некоторые разработчики очень хорошо с этим справляются, и сразу напишут другой CL, который исправит проблему. Однако опыт показывает, что чем больше времени проходит после исходного CL, тем меньше вероятность, что эта правка произойдёт. На самом деле, обычно, если разработчик не делает правку немедленно, то обычно не делает никогда. Не потому, что разработчики безответственны, а потому, что у них много работы, и правка теряется или забывается под валом другой работы. Таким образом, обычно лучше настаивать на немедленном исправлении, прежде чем коммит уйдёт в кодовую базу и будет «завершён». Позволить отложенные правки — типичный способ вырождения кодовых баз.

Если CL вводит новую сложность, то должен быть обязательно исправлен перед отправкой, если это не чрезвычайная ситуация. Если CL проявляет другие проблемы, которые нельзя решить прямо сейчас, разработчик должен зарегистрировать баг в трекере и назначить его на себя, чтобы он не потерялся. Он может дополнительно написать комментарий TODO в коде относительно данной ошибки.

Функциональность

Делает ли CL то, для чего он задуман? Насколько хорошо продуманы изменения для пользователей? При этом под «пользователем» понимается как конечный пользователь (если его затрагивают изменения), так и разработчики, которые будут использовать код в дальнейшем.

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

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

Еще один случай, когда стоит отнестись к ревью более пристально — это наличие в коде CL параллельности в том или ином виде. Главные проблемы, которые может привнести параллельность — это дедлоки и гонки. Эти проблемы бывают очень трудноуловимыми, поэтому, необходимо чтобы и ревьюер и разработчик отнеслись к данному коду внимательнее. (Сложность ревью также является веской причиной избегать моделей конкурентности с возможными гонками и дедлоками).

Стиль

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

Если вы делаете замечание, которое касается стиля и этот момент никак не освещается в гайде, то помечайте такое требование как необязательное («Nit:»). CL не должен блокироваться на основании личных стилистических предпочтений.

Разработчик не должен мешать в один CL стилистические правки и исправление функционала. Это делает сложным для понимания, какой именно функционал изменился. Например, если разработчик хочет полностью переписать целый файл, поменяв его функционал и зарефакторив, то требуйте от него двух CL — первый с рефакторингом, а второй уже с функциональными изменениями.

How to Write a Book Review (in details)

1. План написания рецензии на произведение (The Plan of a Book Review)

1. Introduction (an author, a title, a setting, a plot in short) — Введение (автор, название, местодействия, краткий сюжет)
2. The main part (the plot in details, main characters) — Основная часть (сюжет частично, главные герои)
3. Conclusion  (opinion about the book, reservations, recomendations) — Заключение (личное мнение, недостатки, рекомендации)

2. Фразы и выражения для рецензии на английском языке (Useful Words for a Book Review)

Общая оценка произведения:

1. a splendid book — великолепная книга
2. a powerful novel — производящий сильное впечатление роман
3. a gripping narrative — захватывающее повествование

1. be meticulously (intricately) constructed — тщательно продуман
2. be richly detailed (is rich and detailed in plot) — сюжет богат деталями
3. be set in — происходит в
4. be told by — (повествование) ведется от …
5. hold the attention right up to the final page — удерживать внимание читателя до последней страницы
6. The contrast between ….be done most skillfully — Контраст между … выполнен мастерски.

Мнение о произведении:

1. The only reservation of the book… — Единственный недостаток книги…
2. It is difficult to put the book down… — Трудно отложить книгу …
3. I highly recommend the book to … — Я очень рекомендую эту книгу…
   

3. An Example of a Review on the Book «The Secret History» by Donna Tratt

The Secret History is a powerful novel written by the American writer Donna Tartt. The story is set in New England and shows the life of students in some prestigious college. It is told by the fellow Richard Popen, who recently moved to the area from Calofornia. He happened to be aware of a terrible secret, which changed his life forever.

The Secret History is rich and detailed in plot and provide many layers for the reader to explore. The intricately constructed murder will hold your attention right up to the final page. The book is moving at times and amusing at others. The background of the book contains references to Ancient Greece, which you are sure to enjoy if you are interested in history.

As for the characters, Donna Tratt has managed to create different personalities from indulgent parents to light-hearted hippies. She is very convincing and depicted her characters very true to life. The contrast between the sophisticated ideas of the elite group of students and their contemporaries is done most skilfully.

In conclusion, I would like to note that the only reservation of the book is its length. It has more over 500 pages, so it is rather long. However, it’s difficult to put the book down. I highly recommend The Secret History  to everyone as the greatest achievement of this young novelist.

Функциональность

Делает ли этот CL то, что задумал разработчик? Хорошо ли оно для пользователей этого кода? Под «пользователями» подразумеваются и конечные пользователи (если их затрагивает изменение), и разработчики (которым придётся «использовать» этот код в будущем).

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

Если хотите, то можете проверить работоспособность. Наиболее важно сделать это, если код оказывает влияние на пользователей, например, изменение UI. Трудно понять, как некоторые изменения повлияют на пользователей, когда вы просто читаете код. Для таких изменений можете попросить разработчика предоставить демо, если вам слишком сложно углубляться в код и испытать его самостоятельно.

Ещё один момент, когда во время код-ревью особенно важно подумать о функциональности, — это если в CL происходит какое-то параллельное программирование, которое теоретически может вызвать взаимоблокировки или условия гонки. Такие проблемы очень трудно обнаружить, просто запустив код; обычно нужно, чтобы кто-то (и разработчик, и рецензент) тщательно продумали их и убедились, что проблемы не вводятся (обратите внимание, что это также хорошая причина не использовать модели параллелизма, где возможны условия гонки или взаимоблокировки, — это может сделать код очень сложным для понимания или код-ревью).

Сложность

Является ли CL более сложным, чем должен быть? Проверьте это на каждом уровне: отдельные строки, функции, классы. «Излишняя сложность» обычно означает невозможность быстрого понимания при чтении. Это также может означать, что разработчики, скорее всего, будут вводить ошибки при попытке вызвать или изменить этот код.

Особый тип сложности — это оверинжиниринг, когда разработчики сделали код более универсальным, чем он должен быть, или добавили функциональность, которая в настоящее время не нужна системе. Рецензентам следует быть особенно бдительными в отношении оверинжиниринга. Поощряйте разработчиков решать проблему, которая точно должна быть решена сейчас, а не проблему, которую, возможно, потребуется решить в будущем. Будущую проблему следует решать тогда, когда она появится, и вы можете увидеть её фактическую форму и требования в физической Вселенной.

Сколько вопросов стоит задать респондентам?

Разумеется, вы должны найти золотую середину в составлении информативного но не перегруженного опроса. Метрик у бизнеса множество и их все можно раскрыть несколькими вопросами, но будет ли многократное прохождение такой махины в рамках одного ревью приятным для респондентов? С другой стороны, если вы упрощаете ревью чтобы не отталкивать людей от практики, вы можете упустить что-то важное. Советуем остановиться на 10-15 параметрах, наиболее важные из которых можно развернуть на 2-3 вопроса ради большей точности оценки. Сами параметры, при этом, должны совпадать как в self-review, так и в опроснике для оценки третьего лица. Это нужно для того, чтобы вы без особых проблем сопоставили результаты при обработке результатов.

Контекст

Обычно, инструменты для проведения ревью показывают только то, что поменял разработчик и небольшие фрагменты кода около изменений. Но, часто, необходимо полностью просмотреть целый файл чтобы понять контекст: предположим, вы видите, что были добавлены 4 строчки, однако, развернув файл вы понимаете что это строчки в методе из 50 строк и его теперь необходимо рефакторить.

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

Принципы

• Факты и данные всегда важнее мнений и персональных предпочтений.
• В вопросах стиля style guide является наивысшим авторитетом.
  Все, что не отражено в style guide должно быть консистентным с другим кодом проекта. Если предыдущего кода нет, то стоит принять стиль автора.
• Аспекты построения программ никогда не являются в чистом виде вопросами стиля написания или персональных предпочтений.
  Они основаны на принятых в организации/проекте правилах и должны быть построены с учетом этих принципов, а не только личного мнения. Иногда существует несколько подходов к реализации одного и того же функционала.
  В таком случае, если автор на основе данных или общепринятых инженерных практик может показать, что подходы одинаковы, то ревьюер должен принять выбор автора. В противном случае следует руководствоваться стандартными принципами выстраивания программ.
• В ситуации, не регламентированной правилами, ревьюер может запросить от автора привести код к виду, консистентному с другим кодом проекта, если это не ухудшает общее состояние кодовой базы.

Комментарии

Насколько понятны и необходимы комментарии, оставленные разработчиком? Написаны ли они на понятном английском? Комментарии полезны, когда объясняют почему данный код существует, но излишни, если рассказывают о том, что делает код, хотя бывают и исключения: например, регулярные выражения и сложные алгоритмы. Если код сам по себе не является наглядным, то необходимо сделать его проще. Однако, чаще всего, комментарии должны пояснять то, чего не может сказать код: те решения, которые стоят за написанным.

Бывает полезным посмотреть комментарии, оставленные до CL: возможно, там есть «TODO», которое теперь можно убрать или совет про то, как должен быть сделан некоторый функционал.

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

Стандарты код-ревью

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

На пути к достижению озвученной цели приходится идти на ряд компромиссов.

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

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

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

Таким образом, мы приходим к следующему правилу, задающему стандарт проведения ревью:

Ревьюер должен принять CL тогда, когда он улучшает общую кодовую базу проекта, даже если CL не идеален.

Это самый главный принцип проведения ревью.

Конечно, есть некоторые оговорки: если CL добавляет в код фичи, которые ревьюер не хочет видеть в проекте и не считает необходимыми, то он может не принимать изменения, даже если они улучшают кодовую базу.

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

Замечание: данный документ не оправдывает изменений в CL, которые ухудшают состояние кодовой базы проекта. Единственным исключением являются экстренные случаи.

Улучшения код-ревью со временем

Если будете следовать этим рекомендациям и строго подходить к код-ревью, то обнаружите, что весь процесс со временем ускоряется и ускоряется. Разработчики узнают, что требуется для качественного кода, и отправляют вам CL, которые с самого начала отлично подходят, требуя все меньше и меньше времени на просмотр. Рецензенты учатся быстро реагировать и не добавлять ненужные задержки в процесс рецензирования. Но не компрометируйте стандарты обзора кода или качество для воображаемого улучшения скорости — так на самом деле вы не добьётесь общего ускорения в долгосрочной перспективе.

Шаг нулевой — готовим почву

Если вы собрались проводить эту практику первый раз, то стоит рассказать о ней сотрудникам. Это поможет избежать излишнего стресса и обговорить правила игры ещё до начала. Чем лучше вы объясните цели и задачи процесса для вашей компании, тем меньше встретите сопротивления, меньше будете бегать с просьбами заполнить опрос, получите более осмысленные ответы и, прости господи, инсайты. Наша тройка причин почему это нужно сотрудникам: это шанс посмотреть на себя со стороны, это интересно и даже азартно, это возможность высказаться.

Указания

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

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

Однако иногда более полезны прямые инструкции, предложения или даже код. Основная цель код-ревью — получить наилучший CL. Вторичной целью является повышение квалификации разработчиков, чтобы для них ревью занимало всё меньше и меньше времени.

Тесты

Код, проходящий ревью, должен быть покрыт тестами: требуйте юнит, интеграционных или end-to-end тестов при проведении ревью. В общем случае, тесты должны быть добавлены в тот же CL, что и код. Исключениями являются
экстренные случаи.

Проверяйте правильность тестов — они не тестируют сами себя, а тесты на тесты пишутся крайне редко, обычно их проверяет человек.
Упадут ли тесты, если сломается код? Будут ли они работать правильно, если код изменится? Все ли тесты простые и проверяют то, что нужно проверять? Корректно ли разбиты проверки по методам?

Помните, что тесты — это тоже код, который нужно поддерживать. Не позволяйте тестам быть слишком сложными, просто потому, что они не входят в конечный релизный файл.

Как назначить респондентов?

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

Формат performance review подразумевает сбор информации в формате 180\360 градусов, то есть, в первом случае оценку проводит сам сотрудник (self-review) и его руководитель, во втором — подключаются коллеги, подчиненные и другие менеджеры или даже клиенты. Мы советуем охватывать разные уровни для репрезентативности и полноты взглядов на сотрудника, однако это обязательно должны быть люди вовлечённые в работу сотрудника. Не злоупотребляйте количеством оценивающих: человек 5 будет достаточно.

Стандарт код-ревью

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

Здесь необходим ряд компромиссов.

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

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

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

Таким образом, мы получаем следующее правило в качестве стандарта для код-ревью:

Обычно рецензенты должны одобрить CL, как только он достигает состояния, когда определённо улучшает общее качество кода системы, даже если CL не идеален.

Это главный среди всех принципов код-ревью.

Конечно, у него есть ограничения. Например, если CL добавляет функцию, которую рецензент не хочет видеть в системе, то рецензент, безусловно, может отказать в коммите, даже если код хорошего качества.

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

Рецензенты всегда могут оставлять любые комментарии по улучшению кода, но не очень важные изменения следует помечать, например, префиксом Nit:, чтобы автор знал, что это просто точка зрения, которую он может игнорировать.

Примечание. Ничто в этом документе не оправдывает CL, которые определённо ухудшают общее качество кода системы. Такое возможно только в чрезвычайной ситуации.

Какие типы вопросов использовать?

После того как вы определитесь с примерным содержанием вашего опроса, следующей задачей становится выбор типов вопросов. Их можно поделить на 3 типа:

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

Начнём с закрытых и шкальных вопросов, потому что именно с них стоит начинать опрос. На это есть ряд причин:

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

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

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

Кстати, стоит сказать и о небольшой уловке, которая позволит вам вытянуть из респондента оценку: четное количество делений. Дело в том, что на “нечетной” шкале у вас присутствует среднее значение, своего рода нейтральный ответ (для примера, на шкале от 1 до 5 этой серединой будет значение 3). Четная же шкала не имеет такого центра, значит вашему респонденту в пограничных случаях придется подумать и определиться, как же он относится к той или иной вещи.

Наконец, открытые вопросы — мы предлагаем использовать их не для оценки параметров, а ради получения обратной связи. Например, включите вопрос “расскажи про свои успехи за отчетный период” в self-review или “что бы ты посоветовал сотруднику делать\не делать” в часть опроса для оценки третьего лица. Таким образом вы сможете собрать обратную связь и получить инсайты, которые пригодятся в планировании 1х1 по итогам ревью или дальнейшей работы с человеком.

Дизайн (структура)

Самое важное, на что стоит обратить внимание в ревью — это дизайн CL в целом. Как взаимодействует код в рамках CL? Где находятся изменения: в общей кодовой базе или в вынесены в отдельную библиотеку? Насколько хорошо они интегрируются с остальными компонентами системы? Подходящее ли сейчас время для данных изменений?

Как правильно делать код-ревью?

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

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

Всвязи с этим, «Руководство компании Google по проведению ревью» выглядит очень ценным документом, перевод первой части которого и представлен далее. Переводы остальных частей выйдут позже отдельными постами. Стоит отметить, что это адаптированный перевод, не все переведено слово-в-слово, во имя более русских формулировок и предложений.

CL: «changelist» — список изменений кода, отправленный в систему контроля версий на ревью. Аналог Pull Request в GitHub или Merge Request в GitLab.

Как быстро выполнять код-ревью?

Если вы не в середине сосредоточенной задачи, то должны сделать код-ревью вскоре после его поступления.

Один рабочий день — максимальное время для ответа (т. е. это первое дело на следующее утро).

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

Контекст

Обычно, инструменты для проведения ревью показывают только то, что поменял разработчик и небольшие фрагменты кода около изменений. Но, часто, необходимо полностью просмотреть целый файл чтобы понять контекст: предположим, вы видите, что были добавлены 4 строчки, однако, развернув файл вы понимаете что это строчки в методе из 50 строк и его теперь необходимо рефакторить.

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

Менторство

Документация

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

Сложность

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

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

Как формулировать вопросы?

После того, как вы определитесь с формой и содержанием исследования, следует заняться составлением вопросов — к ним тоже есть определенные требования, хоть и не очень строгие. Формулировка должна создавать условия для точного ответа на вопрос, который вы держите в голове. Для этого:

• держите фокус на предмете вопроса — например, если вы хотите узнать о коммуникабельности человека в общении именно с клиентом, не следует пытаться выяснить это через иной контекст. Дополнения “общается ли он с коллегами на обеде” направят оценивающего не в то русло и исказят оценку.
• не задавайте несколько вопросов в одном — если хочется использовать союз “и” — разбейте на два или уточните.
• не оставляйте двойных смыслов — снижайте сложность восприятия текста за счет использования коротких предложений, линейной структуры и простых слов (а сложным и специфическим не стесняйтесь давать определения).
• не окрашивайте вопрос (и ответы на него) эмоционально — вы же хотите узнать мнение человека, а не подтолкнуть его к определенным ответам?

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

Как правильно делать код-ревью?

9 мин

22K

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

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

Всвязи с этим, «Руководство компании Google по проведению ревью» выглядит очень ценным документом, перевод первой части которого и представлен далее. Переводы остальных частей выйдут позже отдельными постами. Стоит отметить, что это адаптированный перевод, не все переведено слово-в-слово, во имя более русских формулировок и предложений.

Терминология:

CL: «changelist» — список изменений кода, отправленный в систему контроля версий на ревью. Аналог Pull Request в GitHub или Merge Request в GitLab.

Какие инструменты помогут мне провести ревью?

Сейчас проводить аналоговое анкетирование уже как-то неприлично. К счастью, разработчики подумали об эйчарах, поэтому для наших задач существуют множество инструментов — как платных, так и бесплатных. Начнем с последнего — простых и всем известных — сервисов от Google. Наш опыт общения с эйчарами показывает, что так или иначе каждый, кто уже проводит ревью в какой-то момент пользовался или даже продолжает пользоваться Google Forms и Spreadsheets.

Главным плюсом и причиной, по которой с них начинают — отсутствие денежных затрат и, в целом, достаточный на первый взгляд функционал. Однако, немного повозившись с опросом и собрав необходимую информацию, пользователи утыкаются в непростую и очень трудозатратную задачу — обработку результатов. Конечно, с помощью Spreadsheets или Excel можно рассчитать необходимые параметры и даже построить графики, но из-за сложностей и объемов работы, после нескольких ревью эйчары начинают поглядывать в сторону второй группы — платных специализированных сервисов.

Конечно, они уже не только позволяют вам проводить рассылки среди участников, но и сами за вас все посчитают, построят графики и даже позволят сгенерировать отчет. Но у всего есть обратная сторона и в этой группе ей становится отсутствие гибкости. Упрощая работу эйчара, эти сервисы предлагают готовое коробочное решение, внесение корректировок в которое (а как мы помним, ревью — штука весьма индивидуальная) либо невозможно, либо обойдется вам в копеечку. Да и в целом ценники на свои услуги компании ставят весьма негуманные — нам рассказывали о примерно полумиллионной стоимости за год использования одного из сервисов для работы с ~30 людьми — многовато лишь за один инструмент.

Все это подтолкнуло нас (минутка рекламы) к созданию инструмента третьей группы — гибкого, недорогого и не давящего своими заранее созданными функциями на эйчаров. Не будем тут особо хвалиться, просто скажем, что мы добились полной кастомизации опросов, вычислений и вывода результатов, не забывая и о наборе шаблонов для тех, кто просто хочет попробовать тот или иной опрос (не обязательно ревью, можете узнать о вовлеченности коллектива или о тенденциях к выгоранию). Больше вы можете узнать на сайте teamheat.tech или поговорив с нами — контакты будут в конце статьи.

Навигация по CL в код-ревью

Немного о постановке целей

От планов развития сотрудника вы ожидаете выполнения в оговоренные сроки. И в какой бы мягкой форме вы бы ни проводили ваше перформанс ревью, все же стоит зафиксировать договоренности — так они будут восприниматься гораздо серьезнее. Если вы используете OKR, ваши цели можно оформить соответствующим образом и включить в задачи сотрудника. Если нет — просто попросите записать их на бумаге/доске в ходе разговора (и перепишите их себе, забыть может не только респондент). И если вы видите прогресс по этим пунктам — не забывайте его отметить, пусть даже словами — это мотивирует работать и развиваться дальше, в том числе и самостоятельно, без толстых намеков от лида/эйчара. Ваши сотрудники должны понимать, что все эти на первый взгляд обременительные и усложняющие им жизнь телодвижения нужны не только начальству, ваша работа направлена на то, чтобы им лучше жилось и работалось. Поверьте, люди оценят ваши намерения и непременно вас за них отблагодарят. И напоследок, связывать ли окончание ревью с материальными бонусами или повышениями — вопрос дискуссионный, однако мы не советуем: практика показывает, что такая привязка искажает отношение сотрудников к процессу, сводя его к своеобразной “сдаче экзамена” ради получения выгоды.

Тесты

Запросите модульные, интеграционные или сквозные тесты, соответствующие изменению. В общем случае тесты следует добавить в тот же CL, что и производственный код, если CL не обрабатывает чрезвычайную ситуацию.

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

Действительно ли тесты не проходят на сломанном коде? Если код изменится, не появятся ли ложные срабатывания? Делает ли каждый тест простые и полезные утверждения? Правильно ли тесты разделены между различными методами тестирования?

Помните, что тесты — код, который тоже придётся поддерживать. Не допускайте в них сложности только потому, что это не часть основного двоичного файла.

Стандарты код-ревью

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

На пути к достижению озвученной цели приходится идти на ряд компромиссов.

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

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

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

Таким образом, мы приходим к следующему правилу, задающему стандарт проведения ревью:

Ревьюер должен принять CL тогда, когда он улучшает общую кодовую базу проекта, даже если CL не идеален.

Это самый главный принцип проведения ревью.

Конечно, есть некоторые оговорки: если CL добавляет в код фичи, которые ревьюер не хочет видеть в проекте и не считает необходимыми, то он может не принимать изменения, даже если они улучшают кодовую базу.

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

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

Замечание: данный документ не оправдывает изменений в CL, которые ухудшают состояние кодовой базы проекта. Единственным исключением являются экстренные случаи.

Все ли так просто?

После прочтения статьи может сложиться впечатление, что перформанс ревью не представляет собой чего-то особенного. В самом деле, большинство, если не все действия по его подготовке вы, скорее всего, когда-то выполняли или представляете как за них взяться. Опрос, 1х1, постановка целей — вещи интуитивно понятные, но лишь до тех пор, пока вы с ними не столкнетесь на практике. Какие же бывают подводные камни? Абсолютно любые и непредсказуемые, как показывает наш опыт общения с эйчарами из разных сфер. Самое простое — вы можете застрять на создании опроса — вам просто негде будет валидировать свой набор метрик или методики оценки. Составить сам опросник тоже не тривиальная задача — формулировки вопросов должны быть точные, но не перегруженные. Следующие проблемы могут возникнуть на стадии проведения опроса — частый случай это отторжение новой практики со стороны коллег. Люди могут проходить опрос для галочки, либо искажать ответы из-за нежелания подвести оцениваемого или стремления казаться лучше. Требуется серьезная разъяснительно-подготовительная работа о целях проведения ревью.А ведь потом вам нужно оценить сотрудников, подготовиться к беседе и составить план развития… практически каждый этап несет в себе явные и скрытые сложности, на которых немало эйчаров набили себе шишек. Некоторые даже отказались от такого формата оценки и вернулись к формированию характеристик сотрудника “на глазок” или метрикам по типу KPI, для оценки которых не нужно привлекать и организовывать такое количество людей. Однако, мы с вами уже разобрали пользу, которую несет в себе формат PR и советуем запастись терпением и начать работу в этом направлении. Игра стоит свеч и уже после 1-2 грамотно проведенных ревью ваши сотрудники сами оценят пользу этой практики, а большинство ваших болей будут разрешены или уйдут сами. Поэтому, в следующей статье мы сфокусируемся на разборах некоторых практических этапов и постараемся дать вам детальные ответы на частые вопросы, ем самым предоставив вам минимальный набор знаний для начала самостоятельной работы. Если после прочтения у вас остались или появились вопросы — задавайте их в комментариях, пишите в Телеграмм @alexander_a_gurov или на [email protected] и мы вам непременно ответим а может и осветим ваш вопрос в одной из следующих статей. А еще, скажем вам по секрету — у нас есть и инструмент для проведения ревью и корпоративных опросов в целом. Захотите поглядеть — записывайтесь на демо по тем же каналам. Ну а пока — спасибо за внимание, уже скоро поговорим о практических рекомендациях по созданию ревью с нуля. Stay tuned!

Позитивные моменты

Если вы видите в CL хорошо сделанную работу, то скажите об этом разработчику: ревьюеры должны не только обращать внимание на ошибки, но и поощрять за качественно написанный код. С точки зрения менторства намного более важно говорить о том, что сделано хорошо, чем заострять внимание на плохих моментах.

Дизайн

Самое главное — учесть в код-ревью общий проект (дизайн). Имеют ли смысл взаимодействия разных частей кода? Это изменение относится к вашей кодовой базе или к библиотеке? Хорошо ли CL интегрируется с остальной частью системы? Время ли сейчас добавлять эту функциональность?

Стиль

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

Если вы делаете замечание, которое касается стиля и этот момент никак не освещается в гайде, то помечайте такое требование как необязательное («Nit:»). CL не должен блокироваться на основании личных стилистических предпочтений.

Разработчик не должен мешать в один CL стилистические правки и исправление функционала. Это делает сложным для понимания, какой именно функционал изменился. Например, если разработчик хочет полностью переписать целый файл, поменяв его функционал и зарефакторив, то требуйте от него двух CL — первый с рефакторингом, а второй уже с функциональными изменениями.

Контекст

Часто бывает полезно взглянуть на CL в широком контексте. Обычно инструмент код-ревью показывает только несколько строк возле места изменения. Иногда нужно посмотреть на весь файл, чтобы убедиться, что изменение действительно имеет смысл. Например, вы видите добавление всего четырёх строк, но если посмотреть на весь файл, то эти четыре строки находятся в 50-строчном методе, который теперь действительно придётся разбить на более мелкие.

Также полезно думать о CL в контексте системы в целом. Улучшает ли он качество кода системы или делает её более сложной, менее протестированной и т. д.? Не принимайте коммит, который снижает качество кода системы. Большинство систем усложняются в результате суммы многих небольших изменений, поэтому важно предотвратить там даже небольшие сложности.

Метрики и опрос

Итак, в начале текста мы с вами проговорили, что источником информации для оценки сотрудника являются сразу несколько людей — его начальники, коллеги, подчиненные. Можно по старинке собирать информацию в личных беседах, а можно переместиться в 2022 год и проводить опросы. Для этого, кто-то использует бумажные анкеты, кто-то переносит опросники в гугл-формы, а наиболее продвинутые уже пользуются специальными сервисами. Про инструменты поговорим в конце нашего цикла, сначала давайте о содержании. В каждой компании понимают, какие именно компетенции, хард скиллы и поведение они ожидают от сотрудника в зависимости от его должности и уровня. Возможно, у вас уже имеются модели компетенций для каждой из позиций, а может быть только образ идеального сотрудника в голове — в любом случае, именно на основе этой информации мы и определяем набор ключевых метрик для оценки сотрудника. Составьте список как общекорпоративных, так и узкоспециальных метрик, а затем оставьте где-то 10-15 из них — они и лягут в основу перформанс ревью. После того, как вы определились с метриками, вам необходимо составить опрос, который позволит оценить каждую из них. Для этого, вам необходимо придумать вопрос, ответом на который будет оценка соответствия оцениваемого вашему образу идеального сотрудника в контексте конкретной метрики. Задайте контекст в теле вопроса, либо в вариантах ответа — так респондентам будет проще понять, с каким именно образом сотрудника нужно сравнить человека. Ну а затем — создайте свой опрос или анкету и распространите ее среди оценивающих. Дальше вы будете работать уже с результатами и самим оцениваемым. Важным аспектом performance review является привязка к рабочему периоду. Компании оценивают не просто навыки сотрудника, а то, как он проявлял их в в последнее время. Поэтому, советуем вам проводить ревью почаще, чем раз в год — не только людей в тонусе держать будете, но и информация, с которой вам работать, будет свежей. Конечно, мы тут очень поверхностно поговорили о методологии ревью. Но мы отложим это на нашу вторую статью, в которой мы подробно разберем вопросы, вызывающие у эйчаров большинство трудностей. А сейчас предлагаем переместиться в недалекое будущее — вы провели опрос и теперь думаете, что же вам делать дальше:

Дизайн (структура)

Самое важное, на что стоит обратить внимание в ревью — это дизайн CL в целом. Как взаимодействует код в рамках CL? Где находятся изменения: в общей кодовой базе или в вынесены в отдельную библиотеку? Насколько хорошо они интегрируются с остальными компонентами системы? Подходящее ли сейчас время для данных изменений?

Сложность

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

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

О чем говорить на 1

Вообще, сама идея встречи 1:1 — собрать и обсудить информацию ради корректировки вектора развития как самого сотрудника, так и компании. Притом под развитием мы тут понимаем не рост численных показателей, а работу над навыками и эволюцию внутренних процессов соответственно. Дело довольно серьезное и поэтому встречи требуют предварительной подготовки. Поэтому, уделите полчаса для того чтобы составить план беседы и примерный список вопросов и тем для обсуждения.

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

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

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

Функциональность

Делает ли CL то, для чего он задуман? Насколько хорошо продуманы изменения для пользователей? При этом под «пользователем» понимается как конечный пользователь (если его затрагивают изменения), так и разработчики, которые будут использовать код в дальнейшем.

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

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

Еще один случай, когда стоит отнестись к ревью более пристально — это наличие в коде CL параллельности в том или ином виде. Главные проблемы, которые может привнести параллельность — это дедлоки и гонки. Эти проблемы бывают очень трудноуловимыми, поэтому, необходимо чтобы и ревьюер и разработчик отнеслись к данному коду внимательнее. (Сложность ревью также является веской причиной избегать моделей конкурентности с возможными гонками и дедлоками).

Наименования

Необходимо проверять, что разработчик выбрал подходящие наименования. Хорошее имя должно быть достаточно полным, чтобы понять, за что отвечает компонент, но вместе с тем, оставаться легко читаемым и не быть слишком длинным.

Насчёт обиды разработчиков

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

Позитивные моменты

Если вы видите в CL хорошо сделанную работу, то скажите об этом разработчику: ревьюеры должны не только обращать внимание на ошибки, но и поощрять за качественно написанный код. С точки зрения менторства намного более важно говорить о том, что сделано хорошо, чем заострять внимание на плохих моментах.

Хорошее

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

Как писать комментарии в код-ревью

Как подготовить команду к появлению review в компании?

Ваша подготовка к внедрению перформанс ревью не должна ограничиваться созданием опроса. Новые общекомандные практики — не самое простое во внедрении дело и начать подготовку коллектива следует заранее. Иначе вы можете столкнуться с различными проблемами, будь то перекос оценок в сторону доброжелательности вместо объективности, низкая доля участвующих, растянутые сроки прохождения и общее недовольство среди коллег.

Как показывает практика, основные причины противодействия ваших сотрудников следующие:

• Опасение оказаться хуже — неважно, в сравнении с коллективом ли или с собственным мнением — и, как следствие, получить из-за этого неприятности на работе или удар по самолюбию.
• Нежелание брать на себя дополнительные обязанности, зачастую прикрытое непониманием. “Зачем” от сотрудника это не всегда желание узнать причины, часто это и скрытое “опять менеджеры навыдумывали”.

Каждая строка

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

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

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

Что и как мне стоит подсчитать?

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

Если вы пошли по пути использования шкал, вам не придется делать дополнительный шаг и кодировать свои ответы. А если ваш вопрос состоит из закрытых ответов, у вас все равно присутствует незримая, но от этого не менее явная шкала. Ответы, вне зависимости от их формулировок, будут находиться в диапазоне от “близкое к идеальному поведение” до “все очень слабо”. А это значит что присвоить им численные значения — лишь один небольшой, но скрытый от респондентов шаг.

После того, как у вас есть оценка каждого человека по каждому параметру, дальнейшие подсчеты — дело техники. Для начала мы советуем не усложнять математический аппарат: для визуализации картины по сотруднику, а так же средней температуры по больнице вам будет достаточно среднего балла по параметру и среднего значения каждого из параметров из опроса (желательно по отделу и по компании в целом).

После того, как у вас есть оценка каждого человека по каждому параметру, дальнейшие подсчеты — дело техники. Для начала мы советуем не усложнять математический аппарат: для визуализации картины по сотруднику, а так же средней температуры по больнице вам будет достаточно среднего балла сотрудника и среднего значения каждого из параметров из опроса (желательно по отделу и по компании в целом).

Из этих значений уже можно извлечь очень много информации:

• Средние и медианные значения параметров укажут вам на общее состояние, сильные и слабые места процессов. Тут так же важна динамика относительно предыдущих прохождений.
• Сравнение результатов отделов может дать вам инсайты о плюсах или минусах различий в организации рабочего процесса.
• Не стоит искать с помощью этого процесса лидеров по тем или иным показателям ради того, чтобы выставить их на доске почёта. Ранжирование может повлечь за собой конкуренцию, а в командной работе вам это не нужно. Можете пользоваться этой информацией ради распределения знаний. Если кто-то более продуктивен в том или ином процессе по мнению команды, то этому человеку стоит предложить поделиться опытом.

Если вы желаете пойти на шаг дальше — можете рассчитывать статистическую значимость или ввести систему весов оценок респондентов. С помощью первого, вы сможете валидировать корреляцию внутренних изменений с оценками респондентов. Веса же помогут вам корректировать разницу в восприятии людьми той или иной оценки на шкале. Другой причиной введения весов может стать желание разграничить оценки коллег, подчиненных и руководителей. Разумеется, вы можете обойтись и без них, но в реальном мире мнение начальства все же обычно стоит большего, а значит его оценка должна сильнее влиять на оценку сотрудников. Все зависит от вашей корпоративной культуры и модели управления коллективом.

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

LGTM с оговорками

Ради повышения скорости существуют определённые ситуации, в которых рецензент должен дать LGTM/одобрение, даже в случае неотвеченных комментариев к CL. Это делается в случае, если:

• Рецензент уверен, что разработчик надлежащим образом рассмотрит все оставшиеся комментарии.
• Остальные изменения незначительны и необязательны.

Рецензент должен указать, какой из этих вариантов он имеет в виду, если это не ясно.

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

Документация

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

Просмотрите остальную часть CL в соответствующей последовательности

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