Многие жалуются на качество кода, автоматизированных тестов или продукта в целом, на количество ошибок, найденных конечными пользователями или отделом тестирования. Почему это происходит? Необходимо понимать, что для того чтобы не допустить подобных ситуаций требуются дополнительные усилия — необходимо следить за качеством кода и работать над его улучшением.
Code Review является одной из наиболее полезных и эффективных практик для ранней борьбы с дефектами в коде и повышению его качества. Использование Code Review на различных этапах разработки, начиная от дизайна и заканчивая написанием кода и тестов, помогает построить ранний цикл обратной связи и избежать потерь времени в будущем на исправление ошибок.
Дополнительным преимуществом применения Code Review является распространение знаний между членами команды и адаптация других командных подходов. Данная практика может быть интересна любому члену команды вне зависимости от его роли в проекте.
В докладе будут рассмотрены основные аспекты Code Review, способы проведения, инструменты и техники. Также будут продемонстрированы основные ошибки в использовании этой практики, полезные советы, приемы по внедрению и поддержке.
Два бравых украинских хлопца бойко рассказывали про практику code review. При активном участии аудитории осветили практически все, что можно сказать вокруг этой практики. Ну, кроме, разве что, доказательства экономической эффективности, по поводу которой у нас давно ломают копья. Впрочем, в конце доклада парни дали ссылки на книжки с исследованиями, где это вполне может быть.
Видеозапись этого доклада я могу рекомендовать как прекрасное руководство для всех команд, которые хотят внедрить code review. Потому что изложен материал был здорово — просто, понятно, и достаточно широко. Основные вопросы, которые могут возникнуть при внедрении и использовании практики, были освещены. Причем, никаких нареканий к тому, что говорили докладчики, лично у меня, например, не возникло.
Что хочется отметить из любопытного, что нам непривычно, но, возможно, стоит попробовать:
Много говорили о том, что автор и ревьюер смотрят код в паре (есть тонкости);
Был рассмотрен вариант, когда автор делает все исправления в ветке, потом в этой же ветке они резвятся с ревьюером, и только после этого вливают изменения в ствол (обсуждались плюсы и минусы такого подхода);
Идея о том, что автор кода сам отвечает за поиск ревьюера и (скорейшее) прохождение кода через ревью мне давно нравилась, и здесь еще раз ее проговорили. Это мотивирует автора находить путь решения конфликта, защищая ревьюера формальной позицией. Искусственный дисбаланс ролей на этой стадии может привести к более эффективному выполнению ревью.
Очень клевый стиль. Реальный парный доклад.
Один закончил фразу, другой ее продолжил. Клево!
Активно общаются с аудиторией — очень клево.
По содержанию: всесторонне и очень качественно расмотрели вопрос.
Кому интересна тема — рекомендую видео к просмотру… (презентация на английском.. без авторов не очень интересна).
Выводы: Очень здорово и интересно. Ребята — молодцы!
Кстати, авторы уже читали этот доклад на других конференциях, так что видео можно посмотреть здесь, не дожидаясь публикации докладов с 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 в отдельную задачу
Некритичные замечания исправлять самому проверяющему
Любые правки этой статьи будут перезаписаны при следующем сеансе репликации. Если у вас есть серьезное замечание по тексту статьи, запишите его в раздел «discussion».
Быстро
Автор может намеренно обходить скользкие моменты