AgileDays-2011: Отчет Кудрявцева В.Б/В погоне за качеством. Code Review

Ссылки сюда (3) →

Николай Алименков, Алексей Солнцев, 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 свободно берутся любым разработчиком
  • Так принято в RMS
• «Связи на стороне» — кросс-командное ревью
  • На регулярной основе делается очень тяжело
  • Так делали review TN-ERP

Способы Code Review

• От автора — автор рассказывает, что же он сделал

Быстро

Автор может намеренно обходить скользкие моменты

Автор невольно навязывает свою логику рассуждений

• От reviewer’а

Оба способа могут дополняться средствами IDE или специальным средствами

Направления и площадь Code Review

• Можно начинать Review
  • От интерфейса (мой любимый способ)
  • От тестов
  • От кода
• Можно смотреть
  • разницу (diff)
  • готовое решение

Метрики

Сейчас уже не вспомню книжку (есть в презентации), оттуда авторы приводят следующие метрики: Для эффективного review

• процесс должен занимать не боее часа
• затрагиваться должно не более 500 строчек кода
• В одном коммите не должно быть более 400 строчек

Tips and Tricks

• Делать review до или после COMMIT?
  • авторы предлагают делать ДО, разрабатывая в отдельной ветке
  • В RMS это не так, особых неудобств не испытваем
• Делать чек-листы
• Использовать статический анализ кода
  • например, для проверки соответствия стандартам кодирования, чтобы не тратить время проверяющего
• Выделять большие исправления после Review в отдельную задачу
• Некритичные замечания исправлять самому проверяющему