Персональные инструменты
 

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

Материал из CustisWiki

< AgileDays-2011: Отчет Кудрявцева В.Б
Версия от 11:31, 10 мая 2011; StasFomin (обсуждение | вклад) (Новая страница: «Николай Алименков, Алексей Солнцев, [http://xpinjection.com XP Injection] Кстати, авторы уже читали [[В пого...»)

(разн.) ← Предыдущая | Текущая версия (разн.) | Следующая → (разн.)
Это снимок страницы. Он включает старые, но не удалённые версии шаблонов и изображений.
Перейти к: навигация, поиск

Николай Алименков, Алексей Солнцев, 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

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

Ok16.png Быстро

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

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

  • От reviewer’а

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

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

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

Метрики

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

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

Tips and Tricks

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