Николай Алименков, Алексей Солнцев, XP Injection
Кстати, авторы уже читали этот доклад на других конференциях, так что видео можно посмотреть здесь, не дожидаясь публикации докладов с Agile Days. Вы ничего не потеряете, на Agile Days презентация тоже была на английском, хотя доклад читался на русском, с приятным украинским акцентом). Конечно, не обошлось без известной картинки про WTF?/min.
Общее впечатление — хорошо прочитанный и насыщенный доклад про Code Review. Авторы систематически рассказали про разные аспекты процесса, но почти ничего нового я не услышал. Впрочем, доклад полезен все равно — «сверить часы» никогда не лишнее.
Из необычного:
- Code Review докладчики предлагают делать «в паре» с автором, на одной машине
Мысли на будущее:
- Еще раз подумать про распределенные системы контроля версий.
- Посмотреть средства поддержки Code Review, например Code Collaborator
Конспект
Цели Code Review
(собирали варианты ответов из зала)
- Общее владение кодом (знакомство с другими частями системы через Code Review)
- Самообучение Review’а
- Обучение автора кода через замечания
- Поиск общего видения (одна голова хорошо, а две — лучше!)
- Мотивация на качество для автора кода
- Приведение кода к стандартам
- Улучшение качества кода в широком смысле
- Устранение ошибок / проверка завершенности задачи
Возможные негативные последствия/проблемы
- Holy Wars
- Межличностные конфликты
- Code review может быть очень скучным
Для предотвращения межличностных конфликтов следует всегда применять принцип «Review кода, а не автора»
Варианты организации Code Review
- «Папа рядом» — старший разработчик осуществляет review в неопытной команде
- именно в этом случае очень легко вызвать отвращение Code Review
- Автор ищет reviewer’а сам
- может всегда выбирать «удобного человека»
- Review по контракту — пары выбираются в начале итерации, на следующей — меняются
- Control Center — менеджер распределяет задачи
- может быть очень эффективным
- SWAT — отдельный отдел Code Review
- Все Agile-гуру сильно не одобряют этот вариант
- «Все смотрят всех» — задачи по Code Review свободно берутся любым разработчиком
- «Связи на стороне» — кросс-командное ревью
- На регулярной основе делается очень тяжело
- Так делали review TN-ERP
Способы Code Review
- От автора — автор рассказывает, что же он сделал
Быстро
Автор может намеренно обходить скользкие моменты
Автор невольно навязывает свою логику рассуждений
Оба способа могут дополняться средствами IDE или специальным средствами
Направления и площадь Code Review
- Можно начинать Review
- От интерфейса (мой любимый способ)
- От тестов
- От кода
- Можно смотреть
- разницу (diff)
- готовое решение
Метрики
Сейчас уже не вспомню книжку (есть в презентации), оттуда авторы приводят следующие метрики:
Для эффективного review
- процесс должен занимать не боее часа
- затрагиваться должно не более 500 строчек кода
- В одном коммите не должно быть более 400 строчек
Tips and Tricks
- Делать review до или после COMMIT?
- авторы предлагают делать ДО, разрабатывая в отдельной ветке
- В RMS это не так, особых неудобств не испытваем
- Делать чек-листы
- Использовать статический анализ кода
- например, для проверки соответствия стандартам кодирования, чтобы не тратить время проверяющего
- Выделять большие исправления после Review в отдельную задачу
- Некритичные замечания исправлять самому проверяющему
