Хорошие рекомендации и практики для обязательного пересмотра кода [закрыто]

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

• очевидное уменьшение ошибки
• больше осведомленности об изменениях, происходящих вокруг проекта
• «Я знаю, что кто-то будет смотреть на это, чтобы я не был ленивым» / анти-ковбойский эффект
• повышенная согласованность внутри / между проектами

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

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

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

1. Сделайте отзывы короткими.

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

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

2. Избегайте просмотра кода, который слишком плох.

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

3. Используйте автоматические шашки до проверки.

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

4. Тщательно выбирайте лиц, делающих отзывы.

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

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

5. Делайте как неофициальные, так и официальные обзоры.

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

   • SQL-инъекция,
   • Неправильные предположения о языке, который может привести к ошибкам,
   • Конкретные ситуации, которые могут привести к ошибкам, например, приоритет оператора. Например, в C # var a = b ?? 0 + c ?? 0;может хорошо выглядеть тот, кто хочет добавить два обнуляемых числа с объединением в ноль, но это не так.
   • Распределение памяти,
   • Ленивая загрузка (с двумя рисками: загружать одну и ту же вещь более одного раза и не загружать ее вообще),
   • Переполнение,
   • Структуры данных (например, с ошибками, такими как простой список вместо хеш-набора),
   • Проверка ввода и защитное программирование в целом,
   • Резьба безопасности,
   • и т.п.

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

6. Постепенно настройте контрольный список.

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

У нас почти как контрольный список:

• Покажите мне описание задачи.
• Проведи меня через результат и покажи, как он работает. Запустите различные сценарии (неверный ввод и т. Д.).
• Покажите мне прохождение тестов. Как выглядит тестовое покрытие?
• Покажите мне код - вот где мы ищем очевидные недостатки.

Работает довольно хорошо.

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

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

Второе - это автоматизация как можно больше!

• контролировать пробелы
• программное обеспечение для контроля стиля
• автоматизированные сборки перед проверкой кода
• автоматическое тестирование перед проверкой кода

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

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

Мы еще не выиграли эту битву, но это то, что мы сочли полезным.