У меня есть перехватчик предварительной фиксации, который может убедиться, что свойства установлены для файлов, когда они зафиксированы, и что эти свойства установлены на определенные свойства.
Это обеспечит установку свойства для файлов при их фиксации. ОДНАКО есть несколько проблем:
Свойства файла редактируются точно так же, как файлы. Если я установлю в своем файле свойство CodeReview = Done в ревизии 14, оно будет установлено на CodeReview = Done, когда следующий человек зафиксирует свое изменение в Subversion. Не совсем то, что вы хотите.
Не существует простого способа запросить свойства файла, чтобы увидеть, какие из них имеют значение Done, а какие нет.
Моя скромная рекомендация: вы направляетесь в мир боли. Вместо этого настройте Jenkins в качестве сервера непрерывной сборки. Каждый раз, когда кто-то вносит изменения в Subversion, Дженкинс запускает сборку, записывая, что было изменено и кем. Затем вместо того, чтобы помечать отдельные файлы как просмотренные или не проверенные, вы проверяете сборку Jenkins, которая выполняется для всего набора изменений (что в любом случае имеет больше смысла).
Вы можете использовать Promoted Build Plugin, чтобы отметить, является ли конкретный сборка была проверена и прошла ли она проверку кода. Вы также можете прикрепить к каждой сборке комментарий о любых проблемах, обнаруженных при проверке кода.
А теперь, извините меня, я беру свою мыльницу...
Большинство обзоров кода довольно бесполезны. Существует три основных аспекта проверки кода:
- Соблюдал ли пользователь корпоративные стандартные практики?
- Хороша ли логика, заложенная в программе?
- Разработчик допустил глупую ошибку?
Слишком много обзоров кода сосредоточены на проблеме № 1 и оставляют мало времени для проверки остальной части кода или даже для разработки. Я провел часы в обзоре кода, где разработчик назвал переменную CustomerServiceResponseCode, а не customerServiceResponseCode. Мы даже спорили, должно ли это быть responseCodeCustomerService. Часы моей жизни никогда не вернутся к более важным вещам, таким как игра в Angry Birds.
Что касается пункта № 2: это нужно сделать до того, как будет написан какой-либо код. Слишком поздно, когда разработчик потратил 5 часов на кодирование, чтобы ему сказали Вы все сделали неправильно.
Теперь переходим к пункту №3.
Перед просмотром кода:
Разработчик №1: Эй, в вашей программе ошибка!
Разработчик №2: Вау, да. Я забыл разобрать вербекс перед тем, как подключить его. Мальчик, это глупая ошибка.
Результаты: один разработчик, который чувствует себя некомпетентным и глупым.
После проверки кода:
Разработчик №1: Мы только что получили сообщение о том, что в программе есть ошибка!
Разработчик №2: Вау, мы забыли разобрать вербекс перед тем, как его подключить. Как это ускользнуло от обзора кода?
Результаты: целая команда разработчиков, которые чувствуют себя некомпетентными и глупыми.
Я редко видел код-ревью, который действительно выявлял ошибку — даже самую простую — до утверждения кода. Это чужой код, и большинство разработчиков думают о другом. Они бегло просматривают, видят, что общая логика выглядит правильно, а затем, чтобы показать, что они внимательны, жалуются, что отступы неверны.
Что делать?
В рамках вашего процесса все новые разработки должны обсуждаться до написания кода. Это не проверка кода, это часть вашей системы отслеживания проблем.
Используйте автоматизированные инструменты, чтобы поймать вещи. В Java у нас есть Checkstyle (правильно ли отформатирован код), Findbugs, PMD (оба инструмента ловят потенциальные ошибки), детекторы копирования/вставки и т. д. Дженкинс может запускать эти программы и строить всевозможные диаграммы и графики. Более того, это может быть частью игры с непрерывной интеграцией. Вы получаете баллы за решение задач Checkstyle и Findbugs и теряете баллы за создание новых. Также настаивайте на исправлении предупреждений компилятора и уведомлений об устаревании. Опять же, Дженкинс может отслеживать их и давать баллы за их исправление и обработку.
Используйте модульное тестирование. Когда я возглавляю проект, я настаиваю на том, чтобы все модульные тесты были написаны до того, как будет создан кусок кода. Это дает разработчикам цель для достижения при разработке, и код обычно лучше с меньшим количеством ошибок. Используйте инструменты покрытия, чтобы увидеть, насколько хорошо ваши модульные тесты покрывают ваш код.
Использование автоматических инструментов обычно выявляет больше ошибок, чем ручная проверка кода. Автоматизированное тестирование может определить, когда логика кода может иметь проблемы.
Это не означает, что обзоры кода бесполезны. Это просто позволяет обзору кода быть общим обзором кода. Например:
- Что разработчик думает о кодировании? Сочли ли они реализацию более сложной, чем должна была быть, из-за плохого дизайна в другом месте?
- Программа по-прежнему читабельна и понятна? Не слишком ли много исключений и пунктов
if, чтобы обойти проблемы с реализацией?
- Соблюдалась ли общая стратегия? Была ли у разработчика проблема с использованием базового класса/API из-за плохой реализации?
- Следовал ли разработчик согласованной логике?
- Зависит ли разработчик, скажем, от одной сторонней библиотеки JSON, и вы видели, как другая сторонняя библиотека используется в остальной части кода?
Не делайте обзоры кода ради обзоров кода. Не тратьте слишком много времени на реализацию код-ревью. И, ради всего святого, не делайте код-ревью перед фиксацией. Это означает, что разработчики застревают в ожидании одобрения, прежде чем они смогут выполнить какую-либо работу.
person
David W.
schedule
16.04.2013
