ГЛАВА 21 Совместное конструирование
477
Контрольный список: эффективное
парное программирование
Утвердили ли вы стандарт кодирования, позволяющий парам сосредоточиться на программировании и не тратить время на фило- софские диспуты о стиле кодирования?
Оба ли члена пары принимают активное участие в программировании?
Не используете ли вы парное программирование для реализации всех ас- пектов системы? Определяете ли вы задачи, которые действительно целе- сообразно решать в парах?
Не забываете ли вы регулярно менять состав пар и назначаемые им задачи?
Соответствуют ли члены пар друг другу по темпу работы и характеру?
Назначили ли вы лидера группы, координирующего действия участников проекта и отвечающего за связь с людьми, не участвующими в проекте?
21.3. Формальные инспекции
Инспекцией называют специфический вид обзора, обеспе- чивающий очень высокую эффективность обнаружения де- фектов и требующий меньших затрат, чем тестирование.
Инспекции были разработаны Майклом Фаганом (Michael
Fagan) и уже использовались в IBM за несколько лет до того,
как Фаган опубликовал свою работу, которая сделала их доступными широким массам. Хотя любой обзор предпо- лагает изучение проектов или кода, инспекция отличается от обыкновенного об- зора несколькими важными аспектами:
쐽
используемые при инспекциях контрольные списки концентрируют внимание инспекторов на областях, с которыми ранее были связаны проблемы;
쐽
главной целью инспекции является обнаружение, а не исправление дефектов;
쐽
люди, выполняющие инспекцию, готовятся к инспекционному собранию за- благовременно и прибывают на него со списком обнаруженных ими проблем;
쐽
всем участникам инспекции назначаются конкретные роли;
쐽
координатор инспекции не является автором продукта, подвергающегося ин- спекции;
쐽
координатор прошел специальное обучение координированию инспекций;
쐽
инспекционное собрание проводится, только если все участники адекватно к нему подготовились;
쐽
данные, полученные при каждой инспекции, используются для улучшения бу- дущих инспекций;
쐽
руководители не посещают инспекционных собраний, если только вы не ин- спектируете план проекта или другие организационные материалы; участие технических лидеров в инспекционных собраниях допускается.
http://cc2e.com/2192
Дополнительные сведения Пер- вой работой, посвященной ин- спекциям, является статья «De- sign and Code Inspections to Re- duce Errors in Program Develop- ment» (Fagan, 1976).
478
ЧАСТЬ V Усовершенствование кода
Каких результатов можно ожидать от инспекций?
Отдельные инспекции обычно приводят к обнаружению около 60% де- фектов, что превышает эффективность других методик за исключением прототипирования и крупномасштабного бета-тестирования. Эти резуль- таты многократно подтверждены в таких организациях, как Harris BCSD, National
Software Quality Experiment, Software Engineering Institute, Hewlett Packard и мно- гих других (Shull et al., 2002).
Комбинация инспекций проекта и кода обычно позволяет устранить из продукта
70–85 или более процентов дефектов (Jones, 1996). Инспекции способствуют раннему определению подверженных ошибкам классов, и Кейперс Джонс сооб- щает, что при использовании инспекций число дефектов в расчете на 1000 строк кода оказывается на 20–30% более низким, чем при использовании менее фор- мальных методик обзора. Участвуя в инспекциях, разработчики, занимающиеся проектированием и кодированием, учатся улучшать свою работу и достигают повышения производительности труда примерно на 20% (Fagan, 1976; Humphrey,
1989; Gilb and Graham, 1993; Wiegers, 2002). Инспекции проектов и кода системы требуют около 10–15% бюджета проекта и обычно снижают общую сумму расхо- дов на реализацию системы.
Инспекции позволяют также оценить прогресс, но только технический. Как пра- вило, для этого нужно узнать, выполняются ли технические аспекты работы и
хорошо ли они выполняются. Ответы на оба этих вопроса являются побочными продуктами формальных инспекций.
Роли участников инспекции
Один из важнейших аспектов инспекции состоит в том, что каждый ее участник играет свою особую роль.
Координатор Координатор должен поддерживать темп инспекции достаточ- но высоким, чтобы она была продуктивной, и в то же время достаточно низким,
чтобы участники инспекции могли найти максимум ошибок. Координатор дол- жен обладать адекватной технической компетентностью: он может не быть экс- пертом в конкретном фрагменте инспектируемого проекта или кода, но обязан понимать соответствующие детали. Координатор также управляет другими аспек- тами инспекции, такими как распределение фрагментов проекта или кода между инспекторами, распространение контрольных списков инспекции, организация собрания, отчет о результатах инспекции и контроль решения задач, поставлен- ных на инспекционном собрании.
Автор Автор проекта или кода играет во время инспекции относительно неболь- шую роль. Одной из целей инспекции как раз и является гарантия того, что про- ект или код говорит сам за себя. Если проект или код, подвергающийся инспек- ции, кажется неясным, автору поручают его улучшить. Иначе автор должен объяс- нить не совсем ясные части проекта или кода и, если нужно, рассказать, почему аспекты, которые кажутся ошибочными, на самом деле такими не являются. Если инспекторы плохо знакомы с конкретной частью системы, автор может предо- ставить им полезную информацию при подготовке к инспекционному собранию.
1 ... 54 55 56 57 58 59 60 61 ... 104
ГЛАВА 21 Совместное конструирование
479
Инспектор Инспектор имеет прямое отношение к проекту или коду, но не яв- ляется его автором. Инспектором проекта может быть программист, который будет отвечать за его реализацию. Тестировщики или разработчики высокоуровневой архитектуры также могут быть инспекторами. Задача инспекторов — найти дефек- ты. Как правило, инспекторы ищут дефекты при подготовке к собранию, однако при обсуждении проекта или кода на собрании группа должна найти значитель- но больше дефектов.
Секретарь Во время инспекционного собрания секретарь регистрирует обна- руженные ошибки и запланированные действия. Ни автор, ни координатор не дол- жны играть роль секретаря.
Руководители Как правило, руководители не должны участвовать в инспекции.
Инспекция ПО — исключительно технический обзор. Присутствие руководите- лей изменяет все отношения между участниками инспекции: люди, чувствующие,
что их оценивают, начинают беспокоиться не об обзоре кода, а совсем о других вещах, в результате чего инспекция становится не техническим, а политическим мероприятием. Однако руководители имеют право знать результаты инспекции,
поэтому им следует предоставлять соответствующие отчеты.
Ни при каких обстоятельствах не используйте результаты инспекции для оценки производительности труда. Не режьте курицу, которая несет золотые яйца. Ин- спектируемый код все еще находится на стадии разработки. Оценка производи- тельности труда должна быть основана на окончательных, а не промежуточных результатах работы.
В инспекции должны участвовать не менее трех человек, потому что роли коор- динатора, автора и инспектора объединять не следует. В то же время к инспек- ции не следует привлекать более шести человек, потому что группой большего размера слишком трудно управлять. Ученые обнаружили, что наличие более двух- трех инспекторов обычно не повышает эффективность обнаружения дефектов
(Bush and Kelly, 1989; Porter and Votta, 1997). Однако это лишь обобщенные дан- ные: по-видимому, оптимальная методика проведения инспекции зависит от типа инспектируемого материала (Wiegers, 2002). Проанализируйте свой опыт и при- способьте эти рекомендации к своей ситуации.
Общая процедура инспекции
Инспекция включает несколько отдельных этапов.
Планирование Автор проекта или кода предоставляет его координатору. Коор- динатор решает, кто будет выполнять обзор, определяет дату и место проведения инспекционного собрания, после чего предоставляет инспекторам проект или код с контрольным списком, концентрирующим внимание инспекторов на тех или иных аспектах. Инспектируемый материал следует распечатать с номерами строк, что- бы участникам инспекции было проще ориентироваться в нем во время собрания.
Обзор Если инспекторы плохо знакомы с инспектируемым фрагментом систе- мы, автор может посвятить примерно один час описанию технической среды, в которой создан проект или код. Однако наличие подобного обзора может при- водить к нежелательным результатам, подталкивая к неверному толкованию не-
480
ЧАСТЬ V Усовершенствование кода ясных моментов инспектируемого проекта или кода. Как я уже отмечал, проект и код должны говорить сами за себя.
Подготовка Каждый инспектор сам ищет в проекте или коде ошибки, руководствуясь при этом полученным конт- рольным списком.
Выполняя обзор прикладного кода, написанного на высо- коуровневом языке, инспектор может проанализировать за час около 500 строк. При обзоре системного кода, также написанного на высо- коуровневом языке, производительность труда инспектора составляет лишь око- ло 125 строк в час (Humphrey, 1989). Наиболее эффективный темп подготовки может колебаться в широком диапазоне, поэтому храните данные о быстроте подготовки к инспекциям в вашей организации — это поможет вам лучше гото- виться к будущим инспекциям.
В некоторых организациях было обнаружено, что эффективность инспекций повышается, если поручить каждому инспектору рассмотреть проблему под определенным углом. Так, инспектора можно попросить подойти к инспекции с точки зрения программиста, который будет сопровождать программу, клиента или проектировщика. Пока что эта методика изучена недостаточно полно, но имею- щиеся данные говорят о том, что такие обзоры позволяют найти больше ошибок,
чем общие обзоры.
Еще одной разновидностью подготовки к инспекции является выполнение каж- дым инспектором одного или нескольких сценариев. Сценарии могут включать конкретные вопросы, на которые инспектор должен дать ответ, например: «Есть ли требования, которым не удовлетворяет этот проект?» Сценарий может также ставить перед инспектором определенную задачу, такую как составление списка требований, которым удовлетворяет конкретный проект. Вы также можете пору- чить нескольким инспекторам проанализировать материал с начала до конца, в обратном порядке или «вдоль и поперек».
Инспекционное собрание Координатор поручает одному из участников (не ав- тору) начать изложение проекта или чтение кода (Wiegers, 2003) с объяснением всей логики, в том числе всех ветвей каждой логической структуры. Во время этой презентации секретарь записывает обнаруженные ошибки, но как только участ- ники приходят к выводу, что они нашли ошибку, ее обсуждение прекращается.
Секретарь регистрирует тип и серьезность ошибки, и инспекция продолжается.
Если инспекция теряет фокус, координатору следует привлечь внимание группы и вернуть обсуждение в нужное русло.
Темп рассмотрения проекта или кода не должен быть ни слишком медленным, ни слишком быстрым. Если темп слишком низок, участники инспекции теряют кон- центрацию, и продуктивность работы снижается. Если темп слишком высок, группа может упустить ошибки, которые в противном случае были бы обнаружены. Как и темп подготовки, оптимальный темп инспекции зависит от конкретной среды.
Храните соответствующие данные, чтобы со временем вы могли определить са- мую эффективную скорость инспекции в своей организации. В некоторых ком- паниях было обнаружено, что оптимальная скорость инспекции системного кода равна 90 строкам в час. При инспекции прикладного кода скорость может дости-
Перекрестная ссылка Перечень контрольных списков, помога- ющих повысить качество кода,
приведен после содержания книги.