Какие виды инспекции кода вы знаете

Сравнение методик обзора кода

wtf per minute

Думаю, многие разработки знакомы с понятием code review или обзор кода по-русски (также данный термин переводят как просмотр кода, инспектирование кода или рецензирование кода – далее, для единообразия, будет использоваться вариант «обзор кода»). Недавно я столкнулся с необходимостью «разложить по полочкам» и классифицировать знания по этой теме. Результат – данная статья. Надеюсь, она окажется полезной, а также поможет внедрить обзоры кода в свой производственный процесс тем, кто только об этом задумывается.

Обзор кода является одним из наиболее эффективных методов поиска и устранения дефектов программы. Обзоры проводятся человеком, что позволяет находить широкий класс ошибок, в том числе с трудом детектируемых или вообще не детектируемых автоматическими средствами. Безусловно, обзор кода, не отменяет использование анализаторов кода или других методик обнаружения ошибок, например, unit-тестирования. К сожалению, не существует метода, который один обеспечил бы обнаружение всех дефектов программы (в исследованиях эффективность обзора кода обычно оценивается как 30-50% обнаруженных ошибок в приложении).

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

Улучшается архитектура приложения за счет того, что каждую часть системы продумали как минимум 2 человека.
Программист изначально мотивируется писать более качественный код, зная, что его будут просматривать.
Распространяются знания о проекте среди команды.
Происходит обмен программистским опытом.
Вырабатывается единый стиль кодирования в команде.

Можно выделить следующие виды обзоров кода:

Формальная инспекция кода.
Неформальная инспекция кода (другое название – анализ кода).
Чтение кода.
Парное программирование.

Формальная инспекция кода

Формальная инспекция кода представляет собой как следует из названия формализированную процедуру просмотра кода. По МакКоннеллу она выглядит примерно так.

Координатор инспекции назначает дату инспекционного собрания и инспекторов, которые должны до собрания самостоятельно изучить инспектируемый фрагмент кода. В назначенное время собираются координатор инспекции, секретарь, автор кода и инспекторы. Кто-то из инспекторов или руководитель начинают читать код строчку за строчкой (для удобства желательно его заранее распечатать вместе с номерами строк). Инспектора указывают на найденные ими проблемы, автор кода отвечает на вопросы инспекторов – если все соглашаются, что ошибка действительно имеется, то секретарь ее записывает. Координатор инспекции следит за процессом в целом, например, за тем, чтобы обсуждения одной ошибки не затягивались. По окончании инспекции составляется отчет с ее результатами.

Более подробный пример формальной инспекции можно найти здесь.

Достоинства:

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

Недостатки:

Сложная формальная процедура, требующая времени.
Отвлечение как минимум 3-х человек (координатор, автор кода и инспектор) от их основной работы.
Большое психологическое давление на автора кода.

Неформальная инспекция кода

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

Достоинства:

Малые затраты времени.
Простой процесс не требующий формальных процедур.

Недостатки:

Невысокая эффективность за счет поверхностного знакомства проверяющего с кодом.
Для проверки приходится отвлекать кого-нибудь от основной работы, что может сильно раздражать.
Критика кода может плохо восприниматься автором, причем как обоснованно (например, из-за незначащих придирок проверяющего), так и необоснованно (например, автору трудно признавать свои ошибки).

Чтение кода

Чтение кода – это самостоятельное изучение разработчиком чужого кода без присутствия автора. Данная практика является самой простой и распространенной из описанных здесь – думаю, любому разработчику так или иначе приходило читать чужой код. Не говоря уж про мир Open Source, где это зачастую единственный доступный метод обзора кода.

Достоинства:

Простота.
Высокая доступность – не требуется синхронизация во времени и пространстве.

Недостатки:

Медленная обратная связь – могут потребоваться дополнительные комментарии к коду, которые нельзя быстро получить, а иногда даже быстрее самому исправить дефект, чем сообщить об этом автору.

Парное программирование

Парное программирование является экстремальным методом обзора кода – обзор, осуществляемый постоянно: два разработчика за одним компьютером, за одним комплектом мыши и клавиатуры, вместе решают одну задачу. Широкое распространение парное программирование получило после появления методологии экстремального программирования, хотя активно использовалось и до этого. Часто парное программирование используется спонтанно: думаю, многим приходилось подходить к другому разработчику за компьютер, чтобы помочь решить сложную задачу.

Достоинства:

Высокая эффективность, особенно в плане обмена опыта и распространения знания о проекте.
Высокая концентрация на работе – работая в паре, разработчики гораздо меньше отвлекаются на посторонние вещи.
Естественное ограничение количества одновременно разрабатываемых командой задач – сконцентрированность на меньшем количестве задаче обеспечивает более качественную и быструю их реализацию, что позволяет непрерывно поставлять новые версии продукта.
Нет психологических вопросов присущих инспекциям – оба авторы кода, и оба одновременно его же инспекторы, предложения по улучшению воспринимаются именно как предложения, а не критика.
Повышение командного духа – успехи, достигнутые в паре, больше объединяют людей, чем индивидуальные достижения.
Отлично подходит для обучения новичков.

Недостатки:

Падение общей производительности, два программиста заняты одной задачей, вместо разработки двух задач – данное утверждение достаточно спорное, согласно ряду исследований, программисты, работающие в паре, имеют всего на 15% процентов меньшую производительность, чем два программиста работающих по отдельности.
Требуется синхронизация рабочего графика – трудно работать в паре, когда партнеры в разное время ходят на обед или приходят на работу.
Повешенная утомляемость за счет постоянной высокой концентрации на работе – для программистов, работающих в паре, даже может иметь смысл делать рабочий день меньше стандартных 8-ми часов.
Не все люди совместимы, а некоторые даже вообще не способны работать с кем-то вместе. На самом деле, таких людей достаточно немного и большую часть проблем взаимодействия в паре можно преодолеть, выполняя ряд правил (например), а также с накоплением опыта работы в паре.
Неэффективно для выполнения рутинных задач – в этом случае разработчик, не владеющий клавиатурой, будет просто скучать.
Трудно синхронизировать темп разработчиков уровень опыта и знаний которых сильно различается – для эффективной работы от более опытного разработчика требуются терпение и некоторые наставнические навыки.

Что выбрать?

Теперь можно попробовать определиться какой метод и в каком случае стоит использовать.

Если вы решили делать обзоры кода, но не хотите сильно на этом заморачиваться, то для команды расположенной в одном месте неформальные инспекции будут лучшим выбором.
Для распределенной команды практически единственный доступный метод обзора это чтение кода. Несмотря на то, что существуют системы для удаленного парного программирования, чисто по психологическим причинам, они не так комфортны как программирование за одним компьютером. Кроме того, чтение кода можно практиковать и в нераспределенных командах, но когда стоит выбор гадать над назначением какого-то куска кода или поинтересоваться об этом у автора, я бы выбрал последнее.
Формальные инспекции отлично подходят для обзора сложных или критичных участков кода – в этом случае временные затраты с лихвой окупятся результатом. Некоторые практикуют постоянное использование формальных инспекций, но мне трудно представить, как можно формальными инспекциями провести обзор всего имеющегося кода.
Парное программирование не зря является одним из принципов экстремального программирования. Его высокая эффективность и дополнительные бонусы, присущие только этому виду обзора кода, действительно позволяют его рекомендовать как основной способ разработки в команде (за исключением простейших или рутинных задач). Оптимизма добавляет и то, что с большей частью недостатков можно успешно бороться. Самой большой проблемой может стать попытка уговорить менеджмент использовать такой расточительный, по их мнению, метод – тут вам в помощь книги и статьи практиков экстремального программирования.

Литература

Совершенный код (Code complete). Стив МакКоннелл (Steve McConnell). Глава 21. Совместное конструирование.
Экстремальное программирование: постановка процесса. С первых шагов и до победного конца (Extreme Programming Applied: playing to win). Кен Ауэр, Рой Миллер (Ken Auer, Roy Miller). Глава 14. Прекращаем работать в одиночку.

code review
pair programming
обзор кода

У вас здесь ошибка… или о практике инспекций кода в мобильной разработке

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

Процесс внедрения инспекций кода в нашей команде был начат несколько лет назад. Прежде, чем прийти к текущему состоянию, были опробованы различные подходы, методики и инструменты, было перечитано огромное количество постов и книг. Наибольшую пользу нам принесло изучение опыта других команд (как положительного, так и отрицательного). Это помогало определяться с вектором развития и быть подготовленными к возникающим трудностям. Сейчас же, я думаю, настала пора поделиться нашим опытом внедрения и использования инспекций кода при разработке приложений.

Почему важны инспекции кода?

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

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

Программисты, читая код, который был написан их коллегами, неизбежно знакомятся и с ним, и с задачами, которые он должен решать. В результате у команды повышается уровень владения кодом. Разработчики начинают понимать, как работают модули приложения, написанные другими людьми. Уменьшается вероятность дублирования существующего функционала (не кода!). Сокращаются риски, связанные с уходом или временным отсутствием члена команды. В итоге, любой разработчик готов к выполнению даже тех задач, которые затрагивают не только его код.

В случае, когда разработчики знают, что их код будет обязательно просмотрен, они начинают относится к его написанию более ответственно: тщательно продумывают, как встроить функционал в существующую архитектуру, добавляют достаточное количество комментариев и т.д.

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

Во-первых, если инспектирование кода не проводится, то очень легко оказаться в ситуации, когда внедрение нового функционала будет вызывать серьезные проблемы у программистов. В свою очередь заказчик будет недоумевать: почему на добавление небольшого функционала требуется так много времени? Ответ достаточно прост – за качеством архитектуры приложения, его кода и вносимых в них изменений никто не следил.

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

Почему инспекции кода все равно не проводятся?

Программисты, в силу специфики своей профессии, очень умные люди и умеют считать. В особенности, они очень хорошо считают свое время и следят за своей продуктивностью. Согласно их мнению, инспекция кода отвлекает от текущих задач и снижает продуктивность. Дефекты, найденные в ходе инспекции кода, также не представляют для них особого интереса, потому что в основном представляют собой список мелких ошибок, допущенных младшими разработчиками. Более того этот список стабильно повторяется, и его обсуждение представляет собой довольно скучный процесс для опытных разработчиков. Проведение инспекции кода предполагает, что все найденные дефекты будут исправлены. Однако, тут проявляется огромное нежелание программистов вносить изменения в работающий код. Также, если инспекции кода проводятся редко, то программист, которому было это поручено, просто теряется в огромном количестве нового кода. И для него это выглядит как наказание. Эти моменты не мотивируют команду к систематическому проведению инспекций кода. Программисты считают, что результат полученный в ходе инспекций кода не стоит затраченных усилий. Это является следствием недочетов в подходе к проведению инспекций кода и нежеланию их исправлять.

при получении проекта от другой команды;
при постоянном переносе сроков сдачи из-за большого количества ошибок.

К сожалению, что-то менять в этих случаях уже поздно, но существует несколько вариантов выхода из сложившейся ситуации. Первый, очевидный, — поддаться на уговоры программистов «все переписать». Однако, есть шанс довериться слабой команде с неотлаженными процессами и, на выходе, снова получить еще одну мешанину кода. Второй — проанализировать (проинспектировать) существующий код и подготовить стратегию его реанимации. Этот вариант более долгий и требует огромных усилий от проектировщиков и разработчиков.

Типы инспекций кода

формальные инспекции (formal inspections);
инспекция через плечо (over-the-shoulder review);
инспекция кода с помощью e-mail (e-mail pass-around reviews);
парное программирование (pair-programming);
инспекция кода с помощью специальных средств (tool-assisted reviews).

При парном программировании два разработчика решают вместе одну задачу за одним компьютером. В случае инспекции через плечо разработчик просто показывает код своему коллеге.

При инспекции с помощью e-mail измененный код автоматически отправляется на анализ другому программисту.

сбор внесенных в код изменений;
сравнение текущего и предыдущего состояний кода;
ведение диалога, касающегося определенного кода;
сбор статистики;
форсирование проведения инспекции кода и исправления найденных дефектов;
и т.д.

Наш опыт проведения инспекций кода

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

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

Прежде всего в дополнение к формальным инспекциям кода была интегрирована проверка проектов статическими анализаторами кода. В случае разработки под Android использовались Pmd, Findbug, Checkstyle, Lint. Это позволило в автоматическом режиме находить все проблемы кода, связанные с несоблюдением стиля кодирования, неправильным использованием системных API, ошибок в построении интерфейса пользователя и т.д. По началу интеграция данных анализаторов на билд-сервере полностью удовлетворяла наши потребности. Однако, со временем, данный подход перестал нас устраивать по многим причинам. В особенности нам не нравилось, что:

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

Результаты анализа проекта с помощью PMD (Jenkins plugin)

Подробная информация о найденном дефекте с помощью PMD (Jenkins Plugin)

Вскоре мы поняли, что дальше так продолжаться не может – команда росла, и каждому новому программисту приходилось усваивать довольно большой объем информации относительно существующих процессов разработки и используемых утилит. Тогда было принято решение попробовать платформу SonarQube[3], которая предназначена для постоянного отслеживания качества кода. Несмотря на наши сомнения, платформа показала себя только с хорошей стороны. Она решила большую часть наших проблем, связанных со статическими анализаторами кода, добавила новые метрики, по которым можно отслеживать состояние проекта. Управление правилами стало централизованным, появилась возможность составлять планы исправления найденных дефектов и т.д.

Результаты анализа проекта в SonarQube

Подробная информация о найденном дефекте в SonarQube

Статические анализаторы кода, конечно, очень помогают, но полностью полагаться на них нельзя. Они позволяют избавить формальные инспекции кода от обсуждения очевидных дефектов и указать на подозрительные места. Но посоветовать что-то, например, в плане архитектуры приложения они не в силах.

Проведение формальных инспекций кода, даже с учетом помощи статических анализаторов, слишком затратное по времени мероприятие. Поэтому, с одной стороны, если его проводить часто, продуктивность программистов действительно снизится, с другой – если проводить редко, увеличится количество кода, которое необходимо проинспектировать. Согласно же проведенным исследованиям большое количество кода только снизит число найденных дефектов [2].

В поисках решения, которое было бы так же эффективно, как формальная инспекция кода, но не отнимало так много времени, мы пришли к использованию Atlassian Crucible [4]. Фактически это средство взяло на себя всю работу по:

подготовке изменений кода к проверке;
навигации в коде;
ведению диалогов относительно определенных строк кода;
приглашению разработчиков для проведения инспекции;
отслеживанию исправлений, согласно замечаниям коллег;
и т.д.

Самая же интересная возможность, которой мы активно пользуемся в Crucible, состоит в том, что теперь все изменения в коде привязаны к определенной задаче. То есть, это позволяет проводить инспекции кода относительно определенной задачи. В результате, замечания коллег-программистов носят более предметных характер и действительно помогают найти и исправить нетривиальные ошибки.

Пример экрана пользователя при проведение инспекции кода с помощью Atlassian Crucible

Пример экрана создания инспекции кода в Atlassian Crucible

Таким образом, в нашей команде каждый коммит сделанный разработчиком проверяется на билд-сервере статическими анализаторами. Вся собранная статистика аккумулируется в SonarQube и используется всеми заинтересованными лицами: программистами – для самопроверки и определения проблемных мест, руководством – для понимания состояния проекта. Когда программист заканчивает работу над задачей, он начинает инспектирование кода. С помощью Crucible выделяются изменения связанные с завершенной задачей и приглашаются члены команды. Когда код будет всех устраивать инспекция кода завершается. В результате каждая строчка кода подвергается анализу, и за нее отвечает теперь команда целиком.

Хотя мы и перешли к проведению инспекций кода посредством специальных средств, полного отказа от формальных инспекций не было. Они все равно проводятся, но носят более глобальных характер, т.к. на них обсуждается вопросы связанные с архитектурой приложения. Формальные же инспекции проводятся в обязательном порядке для всех новых проектов, которые поступают к нам.

Что мы имеем?

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

В итоге

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

Ссылки

Best Kept Secrets of Peer Code Review / J. Cohen, St. Teleki, E. Brown
11 Best Practices for Peer Code Review // smartbear.com/SmartBear/media/pdfs/11_Best_Practices_for_Peer_Code_Review.pdf
Atlassian Crucible Overview — www.atlassian.com/software/crucible/overview
SonarQube — www.sonarqube.org

Заметки консультанта

Лучшие секреты рецензирования кода. Пять типов рецензирования

Posted by Shamrai Alexander на 13 июня, 2013

За и против формальных проверок, через-плечо, через-почту, парного программирования и инструментального рецензирования.

Есть много способов ободрать кошку. Я могу придумать сразу четыре. Есть также много способов выполнить коллегиальную оценку и каждый имеет свои за и против.

Формальные инспекции

Исторически «формальные» рецензии обычно вызывают «инспекциями». Это пережиток исследования Майкла Фагана 1976 года в IBM относительно эффективности коллегиальных оценок. Он попробовал много комбинаций переменных и придумал процедуру для рецензирования до 250 строк прозы или исходного кода. После 800 итераций он придумал формализованную инспекционную стратегию, и по сей день Вы можете заплатить ему, чтобы он Вам рассказал об этом (название компании: Fagan Associates). Его методы были позже другими изучены и подробно расширены, прежде всего Томом Джилбом и Карлом Виджерсом.

В целом «формальное» рецензирование относится к тяжеловесному процессу рецензирования с тремя -шестью участниками, встречающимися вместе в одной комнате с распечатками и/или проектором. Кто-то «модератор» или «контроллер» и действует как организатор, сохраняет всех в контексте задачи, управляет темпом анализа и действует как арбитр в спорах. Все прочитывают материалы заранее, чтобы должным образом подготовиться к встрече.

Каждому участнику будет присвоена определенная «роль». Для «рецензента» можно определить задачу критического анализа, в то время как «наблюдатель» может бы быть призван как консультант проблемной области или изучить, как правильно делать рецензирование. На инспекции Фагана «читатель» просматривает исходный код только для понимания – не для критического анализа – и представляет его группе. Это разделяет то, что автор предполагал, от того, что фактически представлено; часто сам автор в состоянии выбрать дефекты, получив такое описание со стороны.

Когда дефекты обнаруживаются при формальном рецензировании, они обычно регистрируются довольно подробно. Помимо общего расположения ошибки в коде, включается также детализация, такая как серьезность (например, серьезный, незначительный), тип (например, алгоритм, документация, использование данных, обработка ошибок) и фаза ввода (например, ошибка разработчика, проблема проектирования, ошибка требований). Обычно эта информация хранится в базе данных, поэтому возможно проанализировать под разными углами метрики дефектов и, возможно, сравниться с подобными метриками от QA.

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

Типичный поток операций для «формальной» инспекции. Не показаны артефакты, создаваемые анализом: журнал дефектов, заметки по встрече и журнал метрик. Некоторые в инспекции также используют закрывающую анкету-опросник на заключительной встрече.

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

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

Много исследований за прошлые 15 лет продемонстрировали, что другие формы рецензирования раскрывают столько же дефектов, как и формальные рецензии, но с намного меньшим количеством времени и обучением. Этот результат – ожидаемый теми, кто попробовал много типов рецензий – поместил формальные инспекции в сторону отрасли.

В конце концов, если вы можете извлечь всю доказанную пользу из формальных инспекций и готовы потратить 1/3 времени разработчика, это лучше, чем ничего.

Поэтому давайте посмотрим другие методы.

Рецензирование через-плечо

Это наиболее распространенное и неофициальное из рецензирований кода. Рецензирование «через-плечо» простое – разработчик стоит над рабочим местом автора, в то время как автор проводит рецензента по изменениям кода.

Обычно автор «ведет» рецензирование, находясь за клавиатурой и мышью, открывая различные файлы, указывая на изменения и объясняя, почему был выбран такой путь. Автор может представить изменения, используя различные инструменты, и даже переходя назад и вперед между изменениями и другими файлами в проекте. Если рецензент видит что-то неправильное, они могут поучаствовать в небольшом «парном программировании на месте», когда автор пишет исправление, а рецензент наблюдает. Большие изменения, где рецензент не обязателен, выполняются отдельно.

С современным программным обеспечением использующим общий рабочий стол так называемый анализ «через-плечо» может иметь место и для удаленных ситуаций. Это усложняет процесс, потому что вы должны запланировать эти встречи совместного использования и связаться по телефону. Положение через-плечо позволяет людям указывать, писать примеры или даже переходить к электронной доске для обсуждения, что сложнее сделать по Интернету.

Самое очевидное преимущество рецензирования через-плечо — простота выполнения. Любой может это делать, в любое время и без обучения. Это может применяться каждый раз, когда вам рецензирование необходимо – особенно при сложном изменении или изменении в «стабильной» ветви кода.

Когда все лично рецензируют, метод через-плечо позволяет обучаться и делиться навыками между разработчиками, и заставляет людей взаимодействовать лично вместо того, чтобы скрываться за безличной электронной почтой и мессенджером. Вы естественно говорите больше, когда вы можете поболтать, и может родиться идея вместо того, чтобы зарегистрировать некий формальный «дефект» в какой-нибудь базе данных.

К сожалению, непринужденность и простота процесса также приводят к горе недостатков. Во-первых, это не измеряемый процесс – нет ничего, что передается менеджеру, рассматриваются ли все изменения кода. Фактически, нет никаких метрик, отчетов или инструментов, которые измеряют что-либо вообще о процессе.

Во-вторых, для автора просто неумышленно пропустить изменение. Бесчисленное количество раз мы наблюдали анализ, который завершался, автор регистрировал свои изменения, и когда он видит, что список файлов уже загружен, он говорит, «О, я изменял этот? «. Слишком поздно!

Процесс рецензирования через-плечо

В-третьих, когда рецензент сообщает о дефектах и покидает комнату, редко когда он возвращается назад, чтобы проверить, что дефекты были исправлены должным образом и что никакие новые дефекты не были введены. Если Вы не проверяете, что дефекты исправлены, значение их обнаружения уменьшается.

Есть другой эффект рецензирования через-плечо, которые некоторые люди рассматривают как преимущество, а другие как недостаток. Поскольку автор управляет темпом анализа, часто рецензент идет слишком быстро по коду. Рецензент не может продумать сложную часть кода. Рецензент не имеет шансов пройтись по другим исходным файлам, чтобы удостовериться, что изменение не будут ломать что-то еще. Автор мог бы рассказать что-то, что разъяснит код рецензенту, но следующий разработчик, который прочитает этот код, не будет иметь этого объяснения, если этого не будет как комментарий в коде. Для рецензента трудно быть объективным и понимающим эти проблемы, будучи ведомым по коду с взаимодействующим c ним разработчиком.

Например, скажем, что для автора определили задачу с исправлением ошибки, где часть диалогового окна прорисовывалась неправильно. После борьбы с документацией GUI Windows он наконец обнаруживает недокументированную «функцию» в вызове API прорисовки текста, которая вызывала проблемы. Он обработает ошибку с некоторым новым кодом и решит проблему. Когда рецензент доберется до этого обходного решения, это будет выглядеть сначала забавно.

«Почему Вы делаете так,» спросит рецензент, «ведь API GUI Windows сделает это за Вас?»

«Да, я думал так также,» ответит автор, «но оказывается, что в этом случае обрабатывается не правильно. Поэтому я должен был вызвать его по-другому здесь.»

Для рецензента будет просто принять изменения. Но следующий разработчик, который прочтет этот код, будет иметь такой же вопрос и может даже удалит обходное решение в процессе чистки кода. «В конце концов», скажет следующий разработчик, «API Windows делает это для нас, поэтому никакой потребности в этом дополнительном коде нет!»

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

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

Рецензирование через-почту

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

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

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

Система управления версиями может также помочь автоматической отсылкой электронных писем. Например, серверный триггер «регистрации» в системе управления версиями может послать электронное письмо в зависимости от того, кто загрузил код (например, ведущий разработчик каждой группы рецензирует код от участников своей группы) и какие файлы были изменены (например, некоторые файлы «принадлежат» пользователю, который лучше всего квалифицирован для рецензирования изменений). Автоматизация полезна, но для многих процессов рецензирования кода вы захотите провести рецензию перед регистрацией, а не после.

Рисунок 3: Типичный процесс для почтового рецензирования кода уже зарегистрированного в системе управления версиями. Эти фазы не отличимые в действительности, потому что нет никакого материального объекта «рецензирование».

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

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

Еще одно преимущество рецензирования через-почту – они не выбивают рецензентов из «зоны». Хорошо известно, что разработчику требуется 15 минут, чтобы войти «в зону», где они погружены в свою работу и очень производительны. Даже простая просьба рецензирования у разработчика выбивает его из зоны – даже если будет ответ «я слишком занят». С электронными письмами рецензенты могут работать во время самостоятельно выбранного перерыва, поэтому они могут оставаться в своей зоне в течение многих часов.

Есть несколько важных недостатков рецензировании через-почту. Самый большой тот, который присущ большинству тривиальных рецензирований, трудно отследить различные потоки изменений кода и обсуждений. С несколькими обсуждениями относительно нескольких различных областей кода, возможно приглашая других разработчиков в спор, трудно отследить то, что каждый говорил или дошла ли группа до согласия.

Рисунок 4: Типовой процесс для рецензирования кода через-почту уже зарегистрированного в системе управления версиями. Эти фазы не отличимые в действительности, потому что нет никакого материального объекта «рецензирование».

Есть еще сложный момент с удаленным рецензированием. Иронично, но это одно из явных преимуществ рецензирования через-почту то, что они могут быть проводиться с удаленными разработчиками. Удаленное рецензирование может занять много дней, т.к. каждый переход «назад и вперед» может занять день, поэтому для завершения рецензирования может потребоваться пять дней вместо тридцати минут. Это тянет за собой много одновременных рецензий, а это в свою очередь означает еще больше трудностей для сохранения переговоров и связанных с ними изменений кода.

Предположим, что разработчик в Хайдарабаде, открывая Outlook, обнаруживает 25 электронных писем от различных людей, обсуждающих аспекты трех различных изменений кода, которые он сделал за последние несколько дней. Потребуется много времени только для того, чтобы разобраться, перед тем как может начаться реальная работа.

Среди всех преимуществ перед рецензированием через-плечо, почтовое рецензирование имеет некоторые недостатки. Менеджеры по продукту все еще не уверены, рассматриваются ли все изменения кода. Даже с серверными триггерами управления версиями, все, что Вы знаете это то, что изменения были отосланы, но не то, что каждый действительно смотрел на них. И если было согласовано, что определенные дефекты должны быть исправлены, Вы не можете проверить, что эти исправления были сделаны правильно. Также все еще нет никаких метрик для измерения процесса, определения эффективности или измерения эффекта изменений в процессе.

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

Инструментальное рецензирование

Это относится к любому процессу, в котором используются специализированные инструменты во всех аспектах рецензии: сбор файлов, передача и отображение файлов, комментариев и дефектов для всех участников, сбор метрики и передача менеджерам по продукту и передача администраторам некоторого контроля над потоком операций.

Существует несколько основных элементов, которые должны присутствовать в инструменте рецензирования, если он должен решить большие проблемы с другими типами рецензий:

Автоматизированный сбор файлов

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

В идеале инструмент может сделать это и с локальными изменениями, которые не зарегистрированы в управлении версиями, и с уже зарегистрированными изменениями (например, по дате, метке, ветви или уникальному номеру изменения). Даже если Вы не делаете оба этих типа рецензирования сегодня, то вы скорее всего захотите эту опцию в будущем.

Объединенное отображение: Различия, комментарии, дефекты

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

Автоматизированный набор метрик

С одной стороны точные метрики — единственный метод понять ваш процесс и единственный метод измерить изменения, которые происходят при изменении процесса. С другой стороны, ни один разработчик не хочет рецензировать код с секундомером и инструментами учета количества строк.

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

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

Клиенты и интеграция

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

Инструменты разработчика также имеют свойство интегрироваться с другими инструментами. Клиенты управления версиями находятся внутри IDE. Контроль заданий коррелирует с изменениями в управлении версиями. Точно так же Ваш инструмент рецензирования должен интегрировать с другими вашими инструментами – все от клиентов управления версиями и IDE до метрик и отчетов. Бонус — инструмент, который представляет общедоступный API так, чтобы Вы могли сделать настройки и дополнительную интеграцию сами.

Если Ваш инструмент удовлетворит этот список требований, то Вы будете обладать преимуществами перед рецензированием через-почту (работа с несколькими, возможно удаленными разработчиками, минимизация прерываний), но без каких-либо проблем выполнения потока операций, сбора метрик, и напрасной траты времени для упаковки файлов/различий, поставки и контроля.

Недостаток любого инструментального рецензирования – цена, т.е. деньги для коммерческого инструмента или время, если разработка внутренняя. Вы также должны удостовериться, что инструмент достаточно гибок, чтобы обработать Ваш специфический процесс рецензирования кода; иначе Вы можете найти инструмент, который управляет Вашим процессом, а не наоборот.

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

Парное программирование

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

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

Однако тут есть спорный вопрос, лучше ли рецензии парного программирования, хуже или оно как дополнительное к более стандартным методам. Рецензент глубоко вовлечен в код, уделяя много внимания проблемам и последствиям, являющимся результатом различных реализаций. С одной стороны, это дает рецензенту много времени на инспекцию и глубокое понимание проблемы, поэтому возможно, это означает, что анализ будет более эффективным. С другой стороны, такая близость — это точно не то, чего вы хотите от рецензента; так же, как любой автор не видит всех опечаток в своей собственной работе, рецензент, который слишком близок к коду, и не может отстраниться и не критиковать ее с новой и непредвзятой позиции. Некоторые люди полагают использовать оба метода – парное программирование для глубокого анализа и последующее стандартное рецензирование для введения новых глаз. Несмотря на то, что это занимает много времени разработчика для его реализации, казалось бы, что такой подход обнаружит больше всего дефектов. Хотя мы никогда на практике этого не замечали.

Единственная самая большая жалоба на парное программирование это то, что оно занимает слишком много времени. Вместо того, чтобы привести рецензента на 15-30 минут посмотреть изменение, мы берем одного разработчика на несколько дней в парное программирование и вас теперь два разработчика на одной задаче на все время.

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

Полное обсуждение за и против парного программирования в целом вне нашей темы.

Заключение

Каждый из пяти типов рецензирования полезен по-своему. Формальные инспекции и парное программирование — доказанные методы, но требуют большого количества времени разработчика и не работают с удаленными разработчиками. Рецензирование через-плечо является самым простым для реализации, но не может быть реализован как управляемый процесс. Рецензирование через-почту и инструментальное рецензирование давят на баланс между временем, которое инвестируют, и простотой реализации.

И любой вид рецензирования кода лучше, чем ничего.

Сравнение методик обзора кода

2012-09-13 в 19:02, admin , рубрики: code review, обзор кода, Программирование, разработка, Совершенный код, метки: code review, обзор кода

wtf per minute

Улучшается архитектура приложения за счет того, что каждую часть системы продумали как минимум 2 человека.
Программист изначально мотивируется писать более качественный код, зная, что его будут просматривать.
Распространяются знания о проекте среди команды.
Происходит обмен программистским опытом.
Вырабатывается единый стиль кодирования в команде.

За все это приходится платить временем, которое могло быть потрачено на кодирование. Тем не менее, на проектах, рассчитанных хоть на какую-либо перспективу, затраченное время в будущем вернется сторицей за счет создания изначально качественного продукта, вместо судорожной «допилки» позже.

Формальная инспекция кода.
Неформальная инспекция кода (другое название – анализ кода).
Чтение кода.
Парное программирование.

Рассмотрим каждый вариант по-отдельности.