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

Шамрай Александр Владимирович

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

Posted by Шамрай Александр на Июнь 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 минут посмотреть изменение, мы берем одного разработчика на несколько дней в парное программирование и вас теперь два разработчика на одной задаче на все время.

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

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

Заключение

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

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

Реклама

Добавить комментарий

Заполните поля или щелкните по значку, чтобы оставить свой комментарий:

Логотип WordPress.com

Для комментария используется ваша учётная запись WordPress.com. Выход / Изменить )

Фотография Twitter

Для комментария используется ваша учётная запись Twitter. Выход / Изменить )

Фотография Facebook

Для комментария используется ваша учётная запись Facebook. Выход / Изменить )

Google+ photo

Для комментария используется ваша учётная запись Google+. Выход / Изменить )

Connecting to %s

 
%d такие блоггеры, как: