Упражнения по проверке кода: как использовать рецензирование коллег для развития аналитического мышления и технической компетентности.

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

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

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

Что такое проверка кода?

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

Интересные факты

1. Опишите проблему с производительностью.

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

Исследования современного подхода к проверке кода подтверждают необходимость выхода за рамки простого поиска ошибок. В исследовании, проведенном в Microsoft, Бачелли и Берд наблюдали, опрашивали и проводили опросы разработчиков и менеджеров. Они обнаружили, что поиск дефектов по-прежнему остается основной мотивацией для проверки, но проверка кода в меньшей степени связана с дефектами, чем ожидалось. Кроме того, она приносит и другие преимущества, такие как обмен знаниями, повышение осведомленности команды и поиск альтернативных решений, а исследователи описали понимание кода и изменений как ключевой аспект проверки.Бачелли и Берд, ICSE 2013Это исследование команд одной компании, поэтому используйте его как повод для разработки понятных решений, а не как критерий оценки вашей работы.

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

2. Диагностика пробелов в знаниях и контексте.

Сравните это задание с тем, что практикуется и оценивается в вашей текущей программе.

1. Используется ли в современной практике реальная задача? Если новые рецензенты учатся, читая руководство по стилю, а затем проверяя реальные запросы на слияние, они практикуются на реальной работе, где нет безопасного места для ошибок. Если же оценка представляет собой тест по этикету рецензирования, она измеряет запоминание правил, а не способность применять их к изменениям.
2. Какова когнитивная нагрузка? В пересмотренной таксономии Блума оценка обоснованности проекта и взвешивание его компромиссов находятся на уровнях анализа и оценки, а предложение лучшей структуры достигает уровня создания. Если ваши упражнения спрашивают только «что делает этот код?», они останавливаются на уровне понимания. Наше руководство по соответствие учебных мероприятий таксономии Блума показывает, как соотнести задание с уровнем сложности.
3. Что-то ещё, помимо навыков, мешает? Проверьте время, отведенное на рецензирование, используемые инструменты, ответственных лиц и командные нормы. Если у рецензентов есть пять минут на каждый запрос на слияние, ни одно задание не приведет к вдумчивому объяснению. Если авторы воспринимают каждый комментарий как критику, рецензенты будут смягчать свои выводы до тех пор, пока не перестанут что-либо говорить. Сообщите об этих причинах тем, кто может их устранить.

3. Подготовка проекта, практика и обратная связь.

Каждому этапу поручите отдельное задание.

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

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

Обратная связь. Свяжите это с решениями, принятыми рецензентом. Фраза «Вы заметили проблему с округлением, но в вашем комментарии было сказано: „Это выглядит неправильно“, без указания того, какой ввод приводит к ошибке» более полезна, чем «Найдено 2 из 4».

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

4. Проработайте реалистичный пример.

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

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

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

Первая попытка. «Всё выглядит хорошо, тест пройден. Может, разделить его на части?» Рецензент заметил кое-что, но не сказал, что именно, почему это важно и что делать. Автор не может предпринять никаких действий.

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

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

5. Оценить возможности и спланировать передачу.

Доказательством компетентности является выполнение нового изменения, с которым рецензент ранее не сталкивался. Оцените точность выводов и полезность объяснения. Простая рубрика использует шкалу от 0 до 2 для каждого критерия:

Критерии оценки: 0 означает отсутствие или необоснованность, 1 — частичность с существенными упущениями, а 2 — полноту и обоснованность в соответствии с согласованными критериями. Критические ошибки следует определять отдельно, например, утверждение изменения, сопряженного с риском потери данных, чтобы высокий общий балл не скрывал такой ошибки. Согласуйте критерии с руководителем инженерного отдела; данная рубрика является предварительным предложением, а не утвержденным стандартом готовности. Более подробную информацию о методологии оценки см. в нашем руководстве. разработка интерактивных методов обучения с полезной обратной связью.

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

6. Выполните упражнение в режиме реального времени или в удобном для вас темпе с помощью AhaSlides.

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

1. Выберите ответ На вопрос "Какую проблему вы бы подняли в первую очередь?", с предложенными вариантами ответов. Покажите распределение проблем, прежде чем раскрыть свой собственный рейтинг.
2. Открытый Для фразы "напишите комментарий, который бы вы оставили". Рецензенты могут сравнить свою формулировку с чужими, и именно здесь проявляется умение давать объяснения.
3. Шкала оценок чтобы участники могли увидеть, в чем заключаются различия в оценках, и обсудить причины этих различий.

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

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

Ограничения, которые могут остаться

• Время обзора. Написание вдумчивого комментария занимает больше времени, чем написание "LGTM", а сроки подталкивают к созданию краткой версии.
• Командные нормы. Если отзыв воспринимается как личная критика, рецензенты смягчат или вовсе откажутся от своих замечаний.
• Обзор дела. Одно из упражнений демонстрирует несколько типов проблем. Оценка, как правило, не отражает суждение рецензента.
• Перевод. Производительность в мастерской отличается от производительности в загруженной очереди, поэтому проверяйте и реальные отзывы.

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

Часто задаваемые вопросы

Что такое проверка кода?

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

Как оценить, улучшилось ли качество суждения рецензента?

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

В основном ли рецензирование кода коллегами сводится к поиску ошибок?

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

Когда начать

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

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