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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

#microsoft #ревьюкода