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

В погоне за качеством. Code Review (AgileDays-2011)

Материал из CustisWiki

Перейти к: навигация, поиск

Аннотация

Докладчики

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

Code Review является одной из наиболее полезных и эффективных практик для ранней борьбы с дефектами в коде и повышению его качества. Использование Code Review на различных этапах разработки, начиная от дизайна и заканчивая написанием кода и тестов, помогает построить ранний цикл обратной связи и избежать потерь времени в будущем на исправление ошибок.

Дополнительным преимуществом применения Code Review является распространение знаний между членами команды и адаптация других командных подходов. Данная практика может быть интересна любому члену команды вне зависимости от его роли в проекте.

В докладе будут рассмотрены основные аспекты Code Review, способы проведения, инструменты и техники. Также будут продемонстрированы основные ошибки в использовании этой практики, полезные советы, приемы по внедрению и поддержке.

Видео



Для этого доклада нужен подкаст (аудиозапись)?

  •  Да, многое понятно и без видео части, есть смысл его прослушать.
  •  Нет, аудиозапись бесполезна (не понять без видео или вообще мало смысла в докладе).

Презентация

Примечания и отзывы

В зале собралось очень много народу, многие приносили стулья из других залов. Было очень приятно, что тема инженерных практик для многих актуальна и интересна. При подготовке к выступлению мы добавили в доклад немного интерактива, дав участникам возможность проявить свои познания в Code Review. Самым активным мы подарили печатные экземпляры перевода книги Хенрика Книберга «Scrum and XP from trenches». Этот подарок был особенно хорош, потому что можно было получить личный автограф автора. ©

Коля Алименков и Алексей Солнцев жгли про В погоне за качеством. Code Review и Что означает «Готово!»: применение практики Definition of Done . Хотя про этих ребят можно сказать просто: Они жгли весь Agiledays :) ©

Star.svgStar.svgStar.svgStar.svgStar.svg

Два бравых украинских хлопца бойко рассказывали про практику code review. При активном участии аудитории осветили практически все, что можно сказать вокруг этой практики. Ну, кроме, разве что, доказательства экономической эффективности, по поводу которой у нас давно ломают копья. Впрочем, в конце доклада парни дали ссылки на книжки с исследованиями, где это вполне может быть.

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

Что хочется отметить из любопытного, что нам непривычно, но, возможно, стоит попробовать:

  • Много говорили о том, что автор и ревьюер смотрят код в паре (есть тонкости);
  • Был рассмотрен вариант, когда автор делает все исправления в ветке, потом в этой же ветке они резвятся с ревьюером, и только после этого вливают изменения в ствол (обсуждались плюсы и минусы такого подхода);
  • Идея о том, что автор кода сам отвечает за поиск ревьюера и (скорейшее) прохождение кода через ревью мне давно нравилась, и здесь еще раз ее проговорили. Это мотивирует автора находить путь решения конфликта, защищая ревьюера формальной позицией. Искусственный дисбаланс ролей на этой стадии может привести к более эффективному выполнению ревью.

Украинская пара из XPInjection

Очень клевый стиль. Реальный парный доклад. Один закончил фразу, другой ее продолжил. Клево!

Активно общаются с аудиторией — очень клево.

По содержанию: всесторонне и очень качественно расмотрели вопрос. Кому интересна тема — рекомендую видео к просмотру… (презентация на английском.. без авторов не очень интересна).

Выводы: Очень здорово и интересно. Ребята — молодцы!

Докладчики
Николай Алименков, Алексей Солнцев
Компании
XP Injection, Инфопульс Украина
Презентация
Документ на slideshare.net

Достаточно живой доклад о практиках Code Review. Есть видеозапись и слайды.

В интерактивной форме (с общением с залом) рассказали о

  • целях Code Review;
  • причинах, почему Code Review может и работать, и не работать;
  • как выбирать того, кто будет выполнять Code Review;
  • возможных сценариях проведения Code Review;
  • инструментах (программах), которые могут быть использованы;
  • возможных метриках;
  • плюсах и минусах проведения Code Review до и после помещения нового кода в репозиторий системы контроля версий;
  • литературе для помощи в проведении Code Review.

Вывод: доклад понравился. Динамично, интересно, живо.

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

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

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

  • От reviewer’а

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

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

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

Метрики

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

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

Tips and Tricks

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




Внимание! Эта статья была создана путем автоматического реплицирования из внутренней базы знаний компании Заказные Информ Системы. Любые правки этой статьи могут быть перезаписаны при следующем сеансе репликации. Если у вас есть серьезное замечание по тексту статьи, запишите его в раздел «discussion».