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

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

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

Posted by Шамрай Александр на Июнь 24, 2013

Какая современная литература может рассказать о Рецензировании кода; c какими исследованиями мы согласны, а с какими нет.

Поиск в Amazon книг по фразе «рецензирование кода» покажет только один книгу: 29-страничная статья Майкла Фаган из IBM 1974 года. В том году IBM продал модель диска 3330-11 за $111,600. Мегабайт ОЗУ мог обойтись вам в $75000. До сих пор наиболее продаваемым миникомпьютером является PDP-11.

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

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

Инспекции кода для сборок в OS/360 не имеет ничего общего с тем, как сказываются последствия изменений кода в объектно-ориентированных интерпретируемых языках 3-го уровня. Сбор встречи по инспекции с 5 участниками не работает при распределенной разработке и гибких методологиях.

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

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

Вотта 1993, Конради 2003, Келли 2003: Встречи по рецензированию необходимы?

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

Во-первых, самый известный выпад на такое мнение, традиционно связанное с совещаниями, сделал Лоуренс Вотта из AT&T Bell Labs в 1993 году. Он выделил пять причин наиболее цитируемых менеджерами и разработчиками программного обеспечения в поддержку встреч по инспекциям:

  1. Синергия. Команда найдет недостатки, которые отдельных рецензент может не найти.
  2. Образование. Менее опытные разработчики и рецензенты учатся у своих более опытных коллег.
  3. Срок. Встречи создают график, в котором люди должны работать.
  4. Конкуренция. Эго приводит к личному стимулированию содействия и улучшения.
  5. Процесс. Инспекции просто требуют встреч. Это формальный процесс.

Однако в его оригинальных документах в 1993 на основе его собственных исследований, а также исследованиях других Вотта утверждал, что:

  1. Синергия. Встречи, как правило, выявляют ложные дефекты вместо новых дефектов. (Подробнее ниже).
  2. Образование. Образование путем наблюдения обычно недостаточно; Некоторые исследователи его сильно осуждают.
  3. Сроки. Процесс установки сроков является важным, но может быть обеспечен без встреч сам собой или, по крайней мере, без тяжеловесных встреч.
  4. Конкуренция. Конкуренция по-прежнему достигается при любой коллегиальной оценке. Некоторая конкуренция разрушительно влияет на совместную работу, например, между проектировщиками и тестировщиками.
  5. Процесс. Процесс имеет важное значение, но факты, а не «традиция», должны использоваться для определения процесса.

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

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

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

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

Как выяснилось совещания способствовали лишь 4% от всех дефектов, найденных в ходе инспекций в целом. Статистически больше нуля, но Вотта задался вопросом «стоит ли цена времени потраченного на собрание по сбору Tсбора [напрасно потраченное время] и дополнительное время рецензента этому 4% увеличению проблем, найденных на этой встрече (по любой причине)? Ответ на этот вопрос Нет».

Сильные слова! Но существуют ли другие преимущества для совещаний инспекции помимо просто выявления дефектов?

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

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

В общей сложности 147 дефектов было обнаружено во время фазы чтения. Из них 39 (26%) были удалены во время встречи. Хотя некоторые из них были как ложные (т.е. рецензент неправильно определил дефектом), в большинстве случаев плохая документация или стиль кода привели оппонента к мнению, что существует проблема. Келли выразил мнение о том, что эти «дефекты» следует вероятно рассматривать после всех остальных.

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

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

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

Келли установил, что на чтение было потрачено около две трети от общего объема человеко-часов и одну треть на совещание. Это приводит к скорость обнаружения дефекта 1,7 дефектов в час для чтения и 1,2 для совещания. Чтение на 50% более эффективно в поиске дефектов, чем встречи.

Еще один прямой тест исследований Вотта совместных усилий под другим углом прошел в 2003 году и был проведен Рейдаром Конради между Ericsson в Норвегии и двумя норвежскими колледжами, NTNU и Университетом Агдер. Целью экспериментов было измерение воздействия некоторых методов чтения для проверки модели UML. Вотта экспериментировал с рецензированием проектирования, Келли с исходным кодом, и теперь Конради изучит рецензирование архитектуры.

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

В частности, в 38 контролируемых инспекциями сценариях они обнаружили, что 25% времени было потрачено на чтение, 75% времени на совещания, и тем не менее 80% дефектов были обнаружены во время чтения! Они были в 12 раз более эффективным в поиске дефектов с использованием чтения чем на совещании. Кроме того, в их случае они приглашали 5-7 человек на каждое совещание, что немного больше, чем Келли или Вотта, или даже Фаган рекомендует, поэтому количество обнаруженных дефектов в соответствии с трудозатратами было очень малым.

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

Блакели 1991: Hewlett Packard

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

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

Это предварительное исследование включало один проект с 30 часами разработки и 20 часами рецензирования – 13 часов на предварительной встрече контроля и 7 часов на совещании. Они ограничили свои инспекционные размеры 200 строками кода в час согласно инструкциям. Был найден 21 дефект, обеспечивая проекту скорость дефектообразования 0.7 в час и плотность дефектов 100 на тысячу строк кода.

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

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

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

Дансморе 2000: Объектно-ориентированные инспекции

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

Алистер Дансморе, Марк Ропер и Мюррей Вуд попробовали ответить на этот вопрос в серии экспериментов.

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

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

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

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

  1. «Рецензирование по контрольному списку» дает рецензентам конкретный перечень вещей для проверки на уровне класса, метода и иерархии классов. Контрольный список был построен с использованием опыта первых двух экспериментов как руководство какие типы проблем рецензентам следует искать.
  2. «Систематическое рецензирование» — доработанная техника второго эксперимента.
  3. «Рецензирование варианта использования» дает рецензентам множество путей, в которых можно было бы ожидать код, который используется другим кодом в системе. Это своего рода контрольный список, в котором код ведет себя относительно документа, «играет хорошо» в условиях стресса, и работает в нескольких конкретных путях, которые как мы знаем будут изучаться в текущем приложении.

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

Сравнение результатов трех типов рецензирования. Уровень дефектов в час.

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

Результаты показаны на рисунке ниже.

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

Уровень дефектов является постоянным до 60 минуты инспекции, далее он выравнивается на уровень без дефектов, которые не обнаруживались уже вообще после 90 минут.

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

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

Увано 2006: Анализ движения глаз в процессе рецензирования

Четыре исследователя Института Науки и Технологии Нара выполнили уникальное исследование движений глаз рецензента во время проверки кода. Всегда увлекательно и жутко получить возможность заглянуть в наше подсознание и физиологическое поведение.

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

Исследователи использовали систему по плану, отображаемому в короткой программе на языке C на экране, пока сканер глаз записывал все «фиксации» – время, когда глаз оставался в радиусе 30 пикселей более чем на 1/20 секунды. Кроме того, т.к. они контролировали отображение исходного кода, фиксации были сопоставлены с номерами строк. Результатом является участки, в которых строка кода просматривались с течением времени.

Были использованы шесть различных фрагментов кода C, каждый от 12 до 23 линий, каждый как целая функция или небольшой набор функций для просмотра без прокрутки. Пять предположений были применены для каждого фрагмента, выполняя 27 испытаний (от трех из 30 пришлось отказаться, потому что субъект отвлекался во время опыта).

Общий шаблон – это рецензент, который читает линии сверху вниз в «ухабистом склоне». Это, как правило сквозное, но с короткими, краткими «обратными дорожками» по пути. Они назвали это «первичным сканированием». Обычно 80% из линий только «касаемы» в ходе этого первого сканирования. Затем рецензент концентрируется на определенной части кода – 4 или 5 линий – предположительно где рецензент считает, что может быть проблема.

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

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

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

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

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

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

Этот результат имеет несколько последствий. Во-первых, замедлить! Как мы говорили в разделе как вывод – чем дольше вы уделяете обзору, тем больше дефектов вы найдете. Поспешность добавляет затраты.

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

Лайтенбергер 1999: Факторы, влияющие на количество дефектов

При каких обстоятельствах мы ожидали бы найти больше или меньше дефектов в ходе рецензирования? Размер кода является вопросом инспекции? Как насчет количества времени рецензирования потраченного, глядя на код? Что насчет языка исходного кода или типа программы? Все эти вещи являются «факторами», но мы можем установить что-то более влиятельное, чем эти? Возможно некоторые вещи значат больше, чем другие. В 1999 году трое исследователей провели анализ 300 рецензий от Lucent в Центре Реализации Продуктов для Оптических Сетей (PRC-ON) в Нюрнберге, Германия. Эта группа тратит 15% от их общей разработки на рецензии, но используют ли они свое время мудро? Они обнаруживают настолько много дефектов в час насколько возможно? Если нет, что конкретно они должны делать, чтобы максимизировать уровень обнаружения дефекта? Это были вопросы Лайтенбергера.

Рассмотрение других исследований предложило два наиболее вероятных фактора в количестве дефектов, обнаруженных во время рецензирования: (a) время, затраченное на подготовку и (b) размер кода для инспекции. Так они пришли к причинно-следственной модели – то есть, теоретическая модель, в которой, как они ожидали, эти два фактора могут повлиять на количество дефектов.

Эта модель показана на рисунке ниже. Но создание схемы не доказывает ничего!

Как мы можем проверить является ли эта модель точной и как можно измерить насколько важны каждые из этих причинных связей?

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

Стрелки указывают причинно-следственные связи. «Е» значения представляют собой внешние факторы, которые не учитываются в модели.

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

Результаты Пути Анализа Лайтенбергера для рецензирования кода. Цифры представляют процент от общего влияния.

Результаты одинаковы для проведения рецензирования проектирования и спецификаций.

Результаты показаны на рисунке выше. Следует отметить две важные вещи.

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

Во-вторых, «внешние факторы» гораздо более важны, чем любой из названных. Размер кода только показывает лишь 8% колебаний в количестве найденных дефектов; время чтения показывает 35%, но большая часть вариации поступает из других источников. Рецензирование нового кода, отличается от поддерживаемого кода. Сложные алгоритмы отличаются от связей сложных объектов, которые отличаются от простого процедурного кода. Языки отличаются. Уровень опыта автора и рецензента имеет значение. Эти внешние эффекты составляют наиболее важные факторы того сколько дефектов вы можете ожидать при проведении рецензии.

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

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

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

Заключение

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

Рецензирование максимум один час.

Хотя не каждое исследование рассматривало этот вопрос, общий результат говорит, что эффективность рецензентов по поиску дефектов падает резко после 1 часа. Это справедливо независимо от того, сколько материалов пересматривается одновременно. Некоторые исследования тестировали специально для того, чтобы увидеть насколько много дефектов обнаруживается после 15, 30, 45, 60, 75, 90 и 120 минут на задаче. Во всех случаях существует примерно линейное увеличение количества дефектов, найденных до одного часа, затем значительное выравнивания после этого. Этот результат был отражен и в других исследованиях, которые мы рассматривали.

Точка останова, в которой дальнейшее рецензирование не приносит пользы

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

Второе объяснение заключается в том, что после часа человеческий мозг становится насыщенным. Рецензент не может обрабатывать больше информации, потому что его мозг отказывается сосредоточиваться. «Я искал это слишком долго. Меня уже тошнит от этого» – общая жалоба во время длительного рецензирования. Этот второй пункт может быть проверен просто вернувшись к рецензированию кода на следующий день, и вы увидите, что тот же человек может найти больше дефектов после «перезагрузки». Однако, мы не изучали это и возможно это неважно, потому что мы принимаем, что много времени тратить нецелесообразно.

Чтобы обнаружить больше дефектов, нужно замедлить чтение кода.

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

Что также справедливо, будет или не будет ваш приватный код читаться впоследствии на совещании инспекции.

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

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

За последние пятнадцать лет этот эффект был проверен во многих исследованиях и со многих углов зрения. Несколько выводов по этому вопросу показаны во всех исследованиях данного обзора и во многих других.

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

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

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

Показатели количества дефектов на строку кода ненадежны.

Это мечта предсказателя. Сколько дефектов скрываются в этих 5000 строк кода? Нет проблем, просто взять наше стандартное количество дефектов на количество строк во время обзора и умножить. 12 дефектов на количество строк кода? Ожидаете, что найдете 60 дефектов. Если вы пока нашли только 30, смотрите дальше.

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

Упущения усложняют поиск дефектов.

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

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

Например, в нашем собственном опыте утилита контрольного списка имеет пункт «убедитесь, что все ошибки обрабатываются», что имеет ограниченную пользу – это очевидная вещь для проверки всего кода. Но мы забыли передать номер сборки, прежде чем сеанс QA прошел уже на 30%. После установки контрольного списка выпуска мы больше не забывали об этом.

Исследования слишком малы.

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

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

Различия между каждыми исследованиями.

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

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

Реклама

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

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

Логотип WordPress.com

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

Фотография Twitter

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

Фотография Facebook

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

Google+ photo

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

Connecting to %s

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