Сделайте отзывы короткими.
Трудно оставаться сосредоточенным, особенно во время проверки кода, в течение длительного времени. Более того, длинные обзоры кода могут указывать либо на то, что слишком много можно сказать о коде (см. Следующие два пункта), либо на то, что обзор становится обсуждением более крупных проблем, таких как архитектура.
Кроме того, обзор должен оставаться обзором, а не обсуждением. Это не значит, что автор кода не может ответить, но это не должно превращаться в длительный обмен мнениями.
Избегайте просмотра кода, который слишком плох.
Просмотр некачественного кода является удручающим как для рецензента, так и для автора кода. Если кусок кода ужасен, проверка кода не будет полезна. Вместо этого автора следует попросить правильно переписать код.
Используйте автоматические шашки до проверки.
Автоматизированные контролеры позволяют не тратить драгоценное время, указывая на ошибки, которые могут быть обнаружены автоматически. Например, для кода на C # запуск StyleCop, метрик кода и особенно анализа кода - это хорошая возможность обнаружить некоторые ошибки до проверки. Затем проверка кода может быть потрачена на пункты, которые чрезвычайно сложно сделать для машины.
Тщательно выбирайте лиц, делающих отзывы.
Два человека, которые не могут терпеть друг друга, не сделают хороший обзор чужого кода. Та же проблема возникает, когда один человек не уважает другого (кстати, неважно, рецензент это или автор).
Кроме того, некоторые люди просто не могут просмотреть свой кодекс, поэтому им требуется специальная подготовка и подготовка, чтобы понять, что их не критикуют, и они не должны воспринимать это как нечто негативное. Проведение обзора, неподготовленного, не поможет, поскольку они всегда будут защищаться и не будут прислушиваться к критикам своего кода (принимая каждое предложение за критику).
Делайте как неофициальные, так и официальные обзоры.
Наличие контрольного списка помогает сконцентрироваться на точном наборе недостатков, избегая превращения в гниение. Этот контрольный список может содержать такие пункты, как:
- SQL-инъекция,
- Неправильные предположения о языке, который может привести к ошибкам,
- Конкретные ситуации, которые могут привести к ошибкам, например, приоритет оператора. Например, в C #
var a = b ?? 0 + c ?? 0;может хорошо выглядеть тот, кто хочет добавить два обнуляемых числа с объединением в ноль, но это не так.
- Распределение памяти,
- Ленивая загрузка (с двумя рисками: загружать одну и ту же вещь более одного раза и не загружать ее вообще),
- Переполнение,
- Структуры данных (например, с ошибками, такими как простой список вместо хеш-набора),
- Проверка ввода и защитное программирование в целом,
- Резьба безопасности,
- и т.п.
Я остановлю этот список здесь, но есть сотни пунктов, которые могут фигурировать в контрольном списке, в зависимости от слабых сторон конкретного автора.
Постепенно настройте контрольный список.
Чтобы оставаться конструктивными и полезными с течением времени, контрольные списки, используемые в официальных обзорах, должны со временем корректироваться в зависимости от обнаруженных ошибок. Например, первые неофициальные обзоры могут выявить определенное количество рисков SQL-инъекций. Проверка SQL-инъекций будет включена в контрольный список. Когда спустя несколько месяцев выясняется, что автор сейчас очень осторожно относится к динамическим и параметризованным запросам, SQL-инъекция может быть удалена из контрольного списка.
У нас почти как контрольный список:
Работает довольно хорошо.
источник
Я думаю, что человеку, который обладает властью над другими, будет достаточно, администратор или модератор, чтобы вырезать неуместные комментарии, ускорить просмотр вещей, которые требуют быстрого обзора. Единый принимающий решение.
Минусом этого было бы то, что этот человек должен выполнять это в качестве основной задачи, в то время как он мог бы заниматься чем-то другим, и, вероятно, вы хотели бы, чтобы на этой должности был самый опытный человек.
Второе - это автоматизация как можно больше!
Эти вещи уберут, по крайней мере, некоторые вещи, которые люди могут комментировать без реальной необходимости. Если он не строит или имеет конечные пробелы, он недостаточно хорош для проверки, исправьте его и снова подайте заявку на проверку. Если он не строится или какой-то тест не пройден, то очевидно, что он недостаточно хорош.
Многое зависит от ваших технологий, но найдите то, что вы можете проверить автоматически, чем больше, тем лучше.
Мы еще не выиграли эту битву, но это то, что мы сочли полезным.
источник