Организовать код-ревью среди тысяч разработчиков: опыт Microsoft

Перевод материала Микаэлы Грайлер, бывшего специалиста по организации работы программистов в компании.

Материал входит в серию статей о ревью кода.

Микаэла Грайлер
Микаэла Грайлер

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

Вот и я. Поэтому вместе с коллегами решила приглядеться к процессу ревью кода в Microsoft и ответить на вопросы:

  1. Есть ли какой-то установившийся порядок?
  2. Обязательно ли разработчикам просматривать код?
  3. Если да, какие инструменты они используют?

Приведу некоторые данные о Microsoft. В компании работает около 140 тысяч сотрудников. Примерно 44%, то есть более 60 тысяч, — разработчики. Над кодовыми базами ряда продуктов, например Office, Visual Studio, Windows, одновременно работает несколько тысяч человек.

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

Ревью кода — неотъемлемая часть процесса разработки в Microsoft

Ревью кода очень распространённая практика среди разработчиков компании. Большая часть самых эффективных команд приводит много времени именно за просмотром кода.

Я подготовила электронную <a href="https://api.vc.ru/v2.8/redirect?to=https%3A%2F%2Fwww.michaelagreiler.com%2Fcode-review-e-book%2F&postId=69792" rel="nofollow noreferrer noopener" target="_blank">книгу</a>, описывающую различные методы ревью кода
Я подготовила электронную книгу, описывающую различные методы ревью кода

Изучение ревью кода в Microsoft

Мы опросили более 900 разработчиков Microsoft об их приёмах просмотра кода, наблюдали за их работой и анализировали её.

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

Что можно узнать, изучив подход к просмотру кода в Microsoft

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

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

Если ваша команда уже занимается анализом кода, можно сравнить свой подход с подходом Microsoft. Есть ли отличия?

Как часто разработчики Microsoft проводят ревью кода

Результаты опроса говорят: 36% разработчиков просматривают код несколько раз в день, 39% — по меньшей мере раз в день, 12% — несколько раз в неделю, только 13% утверждают, что не просматривали код ни разу за последнюю неделю.

Как часто разработчики Microsoft анализируют код
Как часто разработчики Microsoft анализируют код

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

Преимущества

Улучшение качества кода, поиск неисправностей и обмен знаниями.

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

Ещё одно преимущество анализа: новые члены команды и младшие разработчики улучшают свои навыки и учатся чему-то новому.

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

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

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

Как именно разработчик проводит анализ кода

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

Просмотр кода в Microsoft с помощью внутренних инструментов

В 2016 году 89% разработчиков указали, что для анализа кода применяют CodeFlow. Позже мы более подробно рассмотрим использование этого инструмента в Microsoft. С тех пор прошло уже довольно много времени, рынок инструментов изменился, на подъёме Git.

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

С чего Роуз из Microsoft начнёт анализ кода

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

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

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

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

Как определить подходящего разработчика

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

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

Роуз запрашивает обратную связь у коллег

Выбрав редакторов, Роуз высылает им анализ кода. Инструмент автоматически рассылает уведомления, сообщая о том, что был создан файл просмотра кода. Все редакторы получают оповещения.

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

Получение обратной связи происходит не один раз

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

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

  1. Нет ли багов?
  2. Всё ли в порядке с архитектурой системы?
  3. Есть ли незначительные проблемы, например пропущенные комментарии или орфографические ошибки?

Не все комментарии представляют одинаковую ценность. Но есть несколько проверенных методов повышения ценности комментария.

Роуз готовит новую версию кода

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

По окончании работы она высылает исправленную версию всем редакторам.

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

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

Утверждение и загрузка

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

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

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

Не все 60 тысяч инженеров и не все команды выполняют одинаковые задачи. У некоторых есть дополнительные этапы просмотра или особые инструменты. Приведу примеры нестандартных этапов, которыми команды дополняют процесс просмотра кода.

Ревью кода с результатами тестирования

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

Именно поэтому некоторые команды требуют вместе с кодом присылать результаты тестирования; к тому же, если сделать тест обязательным условием, про него никто не забудет, а разработчики будут видеть, что код прошёл тест и как минимум работает.

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

Результаты сборки и тестов прилагаются к просмотру кода. Такая настройка гарантирует, что изменения кода протестированы вместе с последними изменениями кодовой базы.

Просмотр кода с пользовательским интерфейсом

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

Просмотр кода, включающий в себя статический анализ

Инструменты статического анализа полностью зависят от конфигурации, но с точки зрения стилевого оформления могут сэкономить много времени редакторам. Некоторые команды в Microsoft используют ботов-редакторов в качестве инструментов статического и динамического анализа.

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

Инструменты Microsoft для код-ревью

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

Скриншот CodeFlow (2016 год)
Скриншот CodeFlow (2016 год)

Интерфейс CodeFlow

Посмотрите на скриншот. Слева буквой A обозначены все рабочие документы.

Буквой B обозначен список редакторов кода, а также их статус (например, «Утвердил» или «В работе»). Документ, над которым ведётся работа, открыт в редакторе (обозначен буквой C). В нижней части скриншота буквой D обозначены комментарии ко всем документам.

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

Функция комментирования

Редактор может выделить именно те части кода, к которым хочет оставить комментарий. Можно даже выделить один или два символа, а не только всю строку целиком, и оставить комментарий только к выделенному фрагменту.

Автору кода и другим редакторам высылается уведомление о комментарии, дальше они могут начать обсуждение в формате треда под этим комментарием.

Функция обсуждения

Она напоминает комментарии в Twitter или Facebook. Ещё одно преимущество — возможность присвоить статус каждому из этих обсуждений, например «Не получается исправить», «Вопрос решён» или «Ведётся обсуждение».

Сравнение редакций кода

Видно, какие именно изменения в код внёс автор после получения комментариев как в первую редакцию, так и в любую из следующих. Функция удобна для отслеживания скорости и эффективности просмотра кода.

Инструменты для аналитики

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

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

Эти данные — основа нескольких эмпирических исследований ревью кода в Microsoft. Многие команды разработки продукта используют эти данные, чтобы отслеживать свою производительность и анализировать используемые приёмы.

Будущее ревью кода в Microsoft

После покупки Microsoft компании GitHub изменение подхода к ревью кода стало неизбежным. Одним из таких изменений стало повсеместное внедрение Git в качестве инструмента управления исходным кодом в Microsoft.

Это привело к тому, что в компании наблюдается рост метода просмотра кода путём запроса на включение внесённых изменений.

Трудности просмотра кода

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

Я бы хотела поблагодарить всех моих коллег из Microsoft и университета Виктории, которые участвовали в исследовании и помогли в создании материала: Крис Бёрд, Яцек Червонка, Лора Маклеод и Маргарет-Анна Стори.

99
4 комментария

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

2
Ответить

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

1
Ответить

Очень слащаво и банально. А хотелось чего-то оригинального и правдивого. Без этих пассажей "в списке уведомлений также находятся менеджеры, в том числе других команд. Так они узнают о новостях, что позволяет им видеть общую картину" - ага, у менеджера столько свободного времени, что он ещё и код сторонних команд будет смотреть.

2
Ответить

сиськи - ОК
статью не читал - пришел за комментами

Ответить