Мысли о code-review

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

Для начала, тем, кому интересно или кто не совсем в теме, можно ознакомиться, например, со следующими линками:

Ну, когда вступление пройдено и необходимая информация прочитана, можно и поговорить. Сначало давайте введем дефиницию на термин «code review»: под code review (или рецензирование кода) тут и далее в тексте будет подразумеваться проверка исходного кода, проводящаяся для того, чтобы улучшить качество программы и навыки разработчиков. Из определения следует, что полезность рецензирования и ее качество может оцениваться, только из критериев изменения этих двух параметров: качества программы и навыков разработчиков. Т.е. процесс, в ходе которого навыки и/или качество не изменяются (или изменяются ровно на столько, на сколько они изменились, если бы этого процесса не было вообще) – назвать рецензированием кода нельзя. Так же максимальная полезность/эффективность от рецензии может быть только при максимальных изменениях этих параметров (конечно в сторону их улучшения). С этим, надеюсь, определились, рассуждаем дальше.

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

Начнем с качества программы. Поскольку понятие термина «качество» не совпадает не только у разных людей, но и может различаться у одного человека в разные промежутки времени, то необходим какой-то общий знаменатель. Пускай этим знаменателем будут, например, следующие критерии:
  1. выполняет ли программа то, что она должна выполнять, и на сколько правильно она это выполняет (соответствие проектной документации),
  2. на сколько эффективно программа выполняет то, что она должна выполнять (используемые алгоритмы).
  3. на сколько удобно данную программу сопровождать (стилистика).

Рецензор кода. Сущность, осуществляющая рецензию кода, на соответствие выше перечисленным критериям качества. В качестве этой сущности могут выступать как программно-аппаратные средства, так и человек. Проверка каждого из критериев в той или иной степени может быть автоматизирована с использованием различных реалтаймовых тестов (юнит, креш, перфоманс и т.д.), статического анализа кода и различных стайл-чекеров. Но в любом случае полностью всю проверку не автоматизируешь, и часть ее ляжет на человека. От сюда делаем следующие выводы: для максимального качества, во-первых, человек должен концентрироваться только на том, что нельзя автоматизировать, во-вторых, человек должен разбираться в предметной области проекта и его архитектуре – т.е. либо он должен работать в том же проекте, либо быть гуру+.

Навыки разработчиков. За счет чего они могут повыситься? В первую очередь за счет учебы на своих (или лучше чужих) ошибках, во-вторых, за счет более полного охвата системы в целом (если разработчик выступает в качестве рецензора в том же проекте, в котором и работает). За счет чего можно достигнуть их роста? Во-первых, автор кода должен всегда иметь обратную связь от рецензора (по максимально удобным для обоих каналам связи), во-вторых, обезличенная информация должна быть доступна для всех разработчиков в разделе на подобие «вредные советы или как писать не стоит».

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

Программный код. Чтобы от ревью был толк, рецензированию должен подвергнуться весь код проекта, т.е. рецензирование должно быть систематическим и охватывать весь diff проекта с момента последней рецензии (в идеально случае начинаться это должно с нулевой ревизии, т.е. с пустого проекта). Т.е. либо проверяется каждый чекин в системе, либо diff между двумя временными точками (в любом случае покрытие кода не изменяется, изменяется только итоговый diff). Так же отсюда можно сделать вывод, что рецензия в отрыве от исходного кода (а также от самого проекта) ничего не стоит. Если изменился код – то старая рецензия уже не актуальна. Если на рецензию в коде не было реакции – то смысл в такой рецензии? Любая критика в рецензии должна превращаться в полноценную запись в системе управления багами и на ее устранение должно отводиться время в проекте, т.е. проводиться соответствующий рефакторинг.

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

На этом пока все. Если у кого-то есть замечания или дополнения - пишите комменты. Так же было бы интересно прочитать, переменяется ли у вас рецензирование кода и в каком виде это происходит Smile

Последняя правка: ср, 09/01/2008 - 19:23
Submitted by Victor on

GameDev.by