Руководство по стилю программирования и конструированию по
 Скачать 7.6 Mb.
|
|
ГЛАВА 21 Совместное конструирование 479 Инспектор Инспектор имеет прямое отношение к проекту или коду, но не яв- ляется его автором. Инспектором проекта может быть программист, который будет отвечать за его реализацию. Тестировщики или разработчики высокоуровневой архитектуры также могут быть инспекторами. Задача инспекторов — найти дефек- ты. Как правило, инспекторы ищут дефекты при подготовке к собранию, однако при обсуждении проекта или кода на собрании группа должна найти значитель- но больше дефектов. Секретарь Во время инспекционного собрания секретарь регистрирует обна- руженные ошибки и запланированные действия. Ни автор, ни координатор не дол- жны играть роль секретаря. Руководители Как правило, руководители не должны участвовать в инспекции. Инспекция ПО — исключительно технический обзор. Присутствие руководите- лей изменяет все отношения между участниками инспекции: люди, чувствующие, что их оценивают, начинают беспокоиться не об обзоре кода, а совсем о других вещах, в результате чего инспекция становится не техническим, а политическим мероприятием. Однако руководители имеют право знать результаты инспекции, поэтому им следует предоставлять соответствующие отчеты. Ни при каких обстоятельствах не используйте результаты инспекции для оценки производительности труда. Не режьте курицу, которая несет золотые яйца. Ин- спектируемый код все еще находится на стадии разработки. Оценка производи- тельности труда должна быть основана на окончательных, а не промежуточных результатах работы. В инспекции должны участвовать не менее трех человек, потому что роли коор- динатора, автора и инспектора объединять не следует. В то же время к инспек- ции не следует привлекать более шести человек, потому что группой большего размера слишком трудно управлять. Ученые обнаружили, что наличие более двух- трех инспекторов обычно не повышает эффективность обнаружения дефектов (Bush and Kelly, 1989; Porter and Votta, 1997). Однако это лишь обобщенные дан- ные: по-видимому, оптимальная методика проведения инспекции зависит от типа инспектируемого материала (Wiegers, 2002). Проанализируйте свой опыт и при- способьте эти рекомендации к своей ситуации. Общая процедура инспекции Инспекция включает несколько отдельных этапов. Планирование Автор проекта или кода предоставляет его координатору. Коор- динатор решает, кто будет выполнять обзор, определяет дату и место проведения инспекционного собрания, после чего предоставляет инспекторам проект или код с контрольным списком, концентрирующим внимание инспекторов на тех или иных аспектах. Инспектируемый материал следует распечатать с номерами строк, что- бы участникам инспекции было проще ориентироваться в нем во время собрания. Обзор Если инспекторы плохо знакомы с инспектируемым фрагментом систе- мы, автор может посвятить примерно один час описанию технической среды, в которой создан проект или код. Однако наличие подобного обзора может при- водить к нежелательным результатам, подталкивая к неверному толкованию не- 480 ЧАСТЬ V Усовершенствование кода ясных моментов инспектируемого проекта или кода. Как я уже отмечал, проект и код должны говорить сами за себя. Подготовка Каждый инспектор сам ищет в проекте или коде ошибки, руководствуясь при этом полученным конт- рольным списком. Выполняя обзор прикладного кода, написанного на высо- коуровневом языке, инспектор может проанализировать за час около 500 строк. При обзоре системного кода, также написанного на высо- коуровневом языке, производительность труда инспектора составляет лишь око- ло 125 строк в час (Humphrey, 1989). Наиболее эффективный темп подготовки может колебаться в широком диапазоне, поэтому храните данные о быстроте подготовки к инспекциям в вашей организации — это поможет вам лучше гото- виться к будущим инспекциям. В некоторых организациях было обнаружено, что эффективность инспекций повышается, если поручить каждому инспектору рассмотреть проблему под определенным углом. Так, инспектора можно попросить подойти к инспекции с точки зрения программиста, который будет сопровождать программу, клиента или проектировщика. Пока что эта методика изучена недостаточно полно, но имею- щиеся данные говорят о том, что такие обзоры позволяют найти больше ошибок, чем общие обзоры. Еще одной разновидностью подготовки к инспекции является выполнение каж- дым инспектором одного или нескольких сценариев. Сценарии могут включать конкретные вопросы, на которые инспектор должен дать ответ, например: «Есть ли требования, которым не удовлетворяет этот проект?» Сценарий может также ставить перед инспектором определенную задачу, такую как составление списка требований, которым удовлетворяет конкретный проект. Вы также можете пору- чить нескольким инспекторам проанализировать материал с начала до конца, в обратном порядке или «вдоль и поперек». Инспекционное собрание Координатор поручает одному из участников (не ав- тору) начать изложение проекта или чтение кода (Wiegers, 2003) с объяснением всей логики, в том числе всех ветвей каждой логической структуры. Во время этой презентации секретарь записывает обнаруженные ошибки, но как только участ- ники приходят к выводу, что они нашли ошибку, ее обсуждение прекращается. Секретарь регистрирует тип и серьезность ошибки, и инспекция продолжается. Если инспекция теряет фокус, координатору следует привлечь внимание группы и вернуть обсуждение в нужное русло. Темп рассмотрения проекта или кода не должен быть ни слишком медленным, ни слишком быстрым. Если темп слишком низок, участники инспекции теряют кон- центрацию, и продуктивность работы снижается. Если темп слишком высок, группа может упустить ошибки, которые в противном случае были бы обнаружены. Как и темп подготовки, оптимальный темп инспекции зависит от конкретной среды. Храните соответствующие данные, чтобы со временем вы могли определить са- мую эффективную скорость инспекции в своей организации. В некоторых ком- паниях было обнаружено, что оптимальная скорость инспекции системного кода равна 90 строкам в час. При инспекции прикладного кода скорость может дости- Перекрестная ссылка Перечень контрольных списков, помога- ющих повысить качество кода, приведен после содержания книги. ГЛАВА 21 Совместное конструирование 481 гать 500 строк в час (Humphrey, 1989). Если вы только начинаете проводить инс- пекции, можете ориентироваться на анализ 150–200 непустых и не являющихся комментариями строк исходного кода в час (Wiegers, 2002). Не обсуждайте на собраниях способы решения проблем. Группа должна сосредо- точиться на обнаружении дефектов. В некоторых группах участникам инспекций даже запрещают обсуждать, действительно ли дефект является дефектом. Эти раз- работчики исходят из того, что любой аспект проекта, кода или документации, который хоть кому-то кажется дефектом, нуждается в пояснении. Как правило, собрание не должно продолжаться более двух часов. Конечно, это не значит, что по окончании двух часов вы должны подать ложный сигнал пожар- ной тревоги, но опыт IBM и других компаний показывает, что инспекторы не могут поддерживать нужную концентрацию более двух часов. По этой же причине не- разумно проводить более одной инспекции в день. Отчет об инспекции В день проведения инспекционного собрания коорди- натор составляет отчет об инспекции (электронное письмо или что-либо подоб- ное), указывая в нем все найденные дефекты, их тип и серьезность. Отчет об ин- спекции помогает гарантировать исправление всех дефектов и облегчает созда- ние контрольного списка, обращающего внимание на проблемы, специфические для организации. Если вы храните данные о времени, затраченном на инспекции, и о числе обнаруженных ошибок, вы сможете подтвердить эффективность инс- пекций достоверными данными. Иначе вы сможете лишь сказать, что инспекции кажутся оптимальным вариантом. Разумеется, это не убедит сторонников тести- рования или других методик. Благодаря отчетам вы также сможете узнать, что ин- спекции в вашей среде не работают. В этом случае вы можете изменить инспек- ции или отказаться от них. Сбор данных важен и потому, что любая новая мето- дология должна оправдывать свое использование. Исправление дефектов Координатор поручает кому-нибудь — обычно авто- ру — исправить все дефекты, указанные в составленном списке. Контроль Координатор отвечает за контроль решения всех задач, поставлен- ных во время инспекции. В зависимости от числа обнаруженных ошибок и их се- рьезности вы можете поручить инспекторам провести повторную инспекцию в полном объеме или проинспектировать только исправленные фрагменты. Кроме того, вы можете позволить автору исправить дефекты без всякого контроля. Дополнительные собрания Хотя во время инспекции участникам не дозволя- ется обсуждать решения обнаруженных проблем, некоторые разработчики могут испытывать такое желание. Вы можете провести неформальное дополнительное собрание, позволяющее заинтересованным сторонам обсудить решения проблем по окончании официальной инспекции. Оптимизация инспекций Накопив опыт проведения инспекций «по книге», вы скорее всего обнаружите несколько способов их улучшения. Однако изменять инспекции следует дисцип- линированно. Адаптируйте процесс выполнения инспекций так, чтобы вы могли узнать, приносят ли изменения выгоду. 482 ЧАСТЬ V Усовершенствование кода Устранение или объединение каких-нибудь этапов инспекции требует затрат, которые часто не оправдываются получаемой выгодой (Fagan, 1986). Если вы ис- пытываете соблазна изменить процесс инспекции без оценки результатов изме- нения, не делайте этого. Если вы выполнили оценку и увидели, что измененная инспекция более эффективна, — вперед! Проводя инспекции, вы заметите, что определенные типы ошибок встречаются чаще других. Создайте контрольный список, обращающий внимание инспекто- ров на эти типы ошибок. Обнаружив новые типы частых ошибок, добавляйте их в список. Если некоторые ошибки из первоначального списка стали встречаться реже, удалите их из списка. После нескольких инспекций вы получите контрольный список, отражающий особенности вашей организации и указывающий на слабые стороны, над которыми следует поработать вашим программистам. Ограничьте контрольный список одной страницей. Более объемные списки трудно исполь- зовать на нужном при инспекции уровне детальности. Личностные аспекты инспекций Суть инспекции заключается в обнаружении дефектов в проекте или коде, а не в изучении альтернатив, не в спорах о том, кто прав, а кто виноват, и уж ни в коем случае не в критике автора проекта или кода. И для автора, и для дру- гих участников инспекция должна быть положительным опытом, укрепляющим командный дух и способствующим обучению. Она не должна вызывать у автора неприязни к членам группы или подталкивать его к поиску новой работы. Комментарии вро- де «любому, кто знает Java, известно, что эффективнее организовать цикл от 0 до num-1, а не от 1 до num» абсолютно неуместны, и в случае надобности координа- тор должен ясно указать на это. Критика проекта или кода по вполне понятным причинам будет задевать само- любие его автора. Автор должен быть готов к тому, что инспекторы могут указать ему на дефекты, которые на самом деле не являются дефектами. Однако автору следует принять к сведению каждый предполагаемый дефект. Это не значит, что автор должен согласиться с сутью критики. Просто во время обзора автору не надо защищать свою работу. После обзора он может обдумать каждое замечание и ре- шить, обосновано ли оно. Инспекторы должны помнить, что именно автору принадлежит право принятия окон- чательного решения о том, что делать с дефектом. Пусть инспекторы ищут дефекты (и предлагают решения после обзора), но не покушаются на права автора. Инспекции и «Совершенный код» При подготовке второго издания «Совершенного кода» я на собственном опыте убедился в эффективности инспекций. Работая над первым изданием книги, я писал черновой вариант главы, оставлял его в ящике стола на пару недель, после чего перечитывал и исправлял найденные ошибки. Далее я раздавал проверенную гла- ву примерно десятку коллег, которые выполняли ее обзор, причем некоторые подходили к этому весьма ответственно. В итоге я исправил все обнаруженные ими ошибки. Через несколько недель я самостоятельно выполнил еще один об- Дополнительные сведения Об- суждение обезличенного про- граммирования (egoless program- ming) можно найти в книге «The Psychology of Computer Prog- ramming, 2d ed.» (Weinberg, 1998). ГЛАВА 21 Совместное конструирование 483 зор и исправил еще ряд ошибок. Наконец я отправил рукопись издателю, и ее проверили литературный редактор, технический редактор и корректор. Книга продается уже более 10 лет, и за это время читатели нашли в ней около 200 не- точностей и ошибок. Трудно поверить, что в книге, прошедшей столько обзоров, оказалось так много ошибок. Увы, это так. Работая над вторым изданием, я решил определить облас- ти, на которые нужно обратить особое внимание, и провел формальные инспек- ции первого издания. Группы из трех-четырех инспекторов подготовились к ним в соответствии с принципами, описанными в этой главе. К моему удивлению, в ходе формальных инспекций мы нашли еще несколько сотен ошибок, которые, несмотря на все приложенные в свое время усилия, все-таки просочились в пер- вое издание. Если до этого ценность формальных инспекций и вызывала у меня хоть какие-то сомнения, при работе над вторым изданием книги они развеялись. Инспекции: резюме Используемые при инспекциях контрольные списки поддерживают концентра- цию разработчиков на важных задачах. Стандартные контрольные списки и стан- дартные роли обеспечивают систематичность процесса инспекции. Кроме того, наличие петли формальной обратной связи, используемой для улучшения конт- рольных списков и слежения за темпом подготовки к инспекциям и темпом их проведения, делает процесс инспекции самоорганизующимся. Как бы инспекция ни начиналась, благодаря постоянной оптимизации и высокой эффективности управления процессом инспекции она быстро становится эффективным спосо- бом устранения дефектов и ошибок. Специалисты Института разработки ПО (Software Enginee- ring Institute, SEI) создали модель зрелости процессов (Capa- bility Maturity Model, CMM), позволяющую оценить эффек- тивность процесса разработки ПО (SEI, 1995). Процесс ин- спекции соответствует самому высокому уровню эффектив- ности. Он является систематичным, повторяется и самооп- тимизируется на основе обратной связи, поддающейся оценке. Эти идеи вы мо- жете приспособить ко многим методикам, описываемым в данной книге. При рас- пространении на всю компанию эти идеи позволят добиться максимально воз- можного уровня качества и продуктивности. Контрольный список: эффективные инспекции Создали ли вы контрольные списки, обращающие вни- мание инспекторов на области, с которыми ранее были связаны проблемы? Посвящена ли инспекция обнаружению, а не исправлению дефектов? Рассмотрели ли вы целесообразность использования разных сценариев, помогающих инспекторам сосредоточиться на важных аспектах подготовки? Достаточный ли объем времени предоставляется инспекторам для подготовки к инспекционным собраниям? Все ли инспекторы адекватно готовятся к собраниям? Дополнительные сведения О разработанной в SEI концепции зрелости процесса разработки см. работу «Managing the Soft- ware Process» (Humphrey, 1989). http://cc2e.com/2199 484 ЧАСТЬ V Усовершенствование кода Назначили ли вы каждому участнику инспекции отдельную роль: координа- тора, инспектора, секретаря и т. д.? Продуктивен ли темп собрания? Ограничили ли вы время собрания двумя часами? Обладают ли все участники инспекции специальными навыками проведе- ния инспекций? Обладает ли координатор навыками координирования инс- пекций? Собираете ли вы данные о типах ошибок, обнаруженных при каждой ин- спекции, для адаптации контрольных списков к особенностям своей орга- низации? Собираете ли вы данные о темпе подготовки к инспекции и проведения самой инспекции для оптимизации этих процессов в будущем? Контролируется ли решение задач, поставленных во время инспекции, не- посредственно координатором или при помощи повторной инспекции? Понимают ли руководители, что им не следует посещать инспекционные собрания? Составили ли вы план контроля вносимых исправлений, гарантирующий их корректность? 21.4. Другие методики совместной разработки ПО Другие типы совместной разработки исследованы хуже, чем инспекции или пар- ное программирование, поэтому мы рассмотрим их менее подробно. В число методик совместной разработки, описываемых в этом разделе, входят анализ проекта или кода, чтение кода и презентация. Анализ проекта или кода Анализ (walk-through) проекта или кода — популярный тип обзора. Этот термин не имеет точного определения и по крайней мере некоторую часть его популяр- ности можно приписать тому факту, что почти любой тип обзора можно назвать «анализом». Из-за отсутствия точного определения трудно сказать, что такое анализ. Несом- ненно, анализ предполагает участие двух или более человек, обсуждающих про- ект или код. Он может быть совсем неформальным, таким как разговор у доски без какой бы то ни было подготовки. В то же время он может быть очень форма- лизован: примером может служить запланированное собрание с просмотром презентации, подготовленной отделением дизайна, и отправкой формального отчета руководителям. В некотором смысле единственным необходимым условием проведения анализа является «присутствие двух-трех человек в одном месте». Сторонникам анализа нравится расплывчатость такого определения, поэтому я просто укажу некоторые главные аспекты анализа и позволю вам разбираться с остальными деталями самостоятельно: 쐽 за проведение и координацию анализа обычно отвечает автор проекта или кода, подвергающегося обзору; ГЛАВА 21 Совместное конструирование 485 쐽 предметом анализа являются технические вопросы — это рабочее собрание; 쐽 все участники готовятся к анализу, изучая проект или код и выискивая в нем ошибки; 쐽 анализ позволяет опытным программистам передавать опыт и дух корпоратив- ной культуры молодым программистам; с другой стороны, молодые програм- мисты во время анализа могут предложить новые методологии и подвергнуть сомнению старые и, возможно, уже неэффективные методики; 쐽 как правило, анализ длится от 30 до 60 минут; 쐽 главная цель анализа — обнаружение ошибок, а не их исправление; 쐽 руководители в анализе не участвуют; 쐽 идея анализа обладает значительной гибкостью и легко адаптируется к специ- фическим потребностям организации. Каких результатов ждать от анализа? При грамотном и дисциплинированном использовании анализ может принести результаты, похожие на результаты инспекции, т. е. в типичной ситуации он по- зволяет обнаружить в программе 20–40% ошибок (Myers, 1979; Boehm, 1987b; Yourdon, 1989b; Jones, 1996). Тем не менее обычно анализ значительно менее эффективен, чем инспекция (Jones, 1996). При неразумном использовании анализ невыгоден. Нижняя граница эф- фективности анализа — 20% — не заслуживает особого внимания, к тому же по крайней мере в одной организации (Boeing Computer Services) взаимные обзоры кода оказались «очень дорогими». Специалисты Boeing обнару- жили, что участников проекта было трудно убедить согласованно применять ме- тодики анализа, а при повышенном давлении внешних факторов проведение ана- лиза стало практически невозможным (Glass, 1982). Опыт оказания консалтинговых услуг, накопленный в моей компании за после- дние 10 лет, заставил меня более критично относиться к анализу. Я обнаружил, что если люди плохо отзывались о технических обзорах, то почти всегда это было связано с неформальными методиками (такими как анализ), а не с формальными инспекциями. По сути обзор является собранием, а проводить собрания дорого. Если вы хотите потратиться на проведение собрания, его следует организовать как формальную инспекцию. Если подвергающийся обзору материал не оправды- вает затрат на проведение формальной инспекции, он не оправдывает затрат на проведение собрания вообще. В таких случаях вам лучше использовать чтение документации или другой менее интерактивный подход. Итак, инспекции обеспечивают более высокую эффективность устранения оши- бок, чем анализ. Какая же причина может заставить кого-то использовать анализ? Если обзор выполняется большой группой разработчиков, анализ — хороший вариант обзора, потому что он позволяет изучить проблему под многими разны- ми углами зрения. Если каждый участник анализа приходит к выводу, что реше- ние не имеет серьезных недостатков, скорее всего так оно и есть. Если вы привлекаете к обзору специалистов из других организаций, анализ так- же может быть предпочтительным вариантом. Роли, назначаемые при инспекции, более формализованы, и их эффективное исполнение требует некоторой прак- 486 ЧАСТЬ V Усовершенствование кода тики. Разработчики, не имеющие опыта участия в инспекциях, не смогут показать все, на что они способны. Если вы хотите, чтобы они внесли свой вклад в общее дело, анализ может оказаться оптимальной методикой обзора. Инспекция более целенаправленна, чем анализ, и обычно более выгод- на. Следовательно, если вы выбираете стандартную методику обзора для своей организации, выберите сначала инспекцию, если только у вас нет убедительной причины поступить иначе. Чтение кода Чтение кода — альтернатива инспекции и анализу. Данная методика подразуме- вает, что вы читаете исходный код в поисках ошибок, обращая при этом внима- ние и на его качественные аспекты, такие как проект, стиль, удобочитаемость, удобство сопровождения и эффективность. Исследование, проведенное в Лаборатории проектирования ПО NASA, показало, что при чтении кода разработчики находили около 3,3 дефек- та в час, а при тестировании — около 1,8 ошибки в час (Card, 1987). Кроме того, на всем протяжении проекта чтение кода позволяло найти на 20–60% боль- ше ошибок, чем разные виды тестирования. Как и анализ, чтение кода не имеет точного определения. Обычно при чтении кода двое или более человек независимо изучают код, после чего обсуждают его вме- сте с автором. Методика чтения кода описана ниже. 쐽 В начале подготовки к собранию автор кода раздает листинги участникам обзора. Листинги включают от 1000 до 10 000 строк; типичный объем — 4000 строк. 쐽 Двое или более разработчиков читают код. Чтобы поддержать дух соревнова- ния, привлекайте к чтению кода минимум двух человек. Если в чтении кода уча- ствуют три человека или более, оценивайте вклад каждого из них, чтобы вы знали, как дополнительные участники влияют на результаты. 쐽 Участники обзора читают код независимо друг от друга. Обычно продуктив- ность составляет примерно 1000 строк в день. 쐽 После того как участники обзора завершили чтение кода, автор кода прово- дит собрание. Собрание продолжается один-два часа и фокусируется на про- блемах, обнаруженных при чтении кода. Никто не пытается анализировать код строку за строкой. Строго говоря, собрание даже не является необходимостью. 쐽 Автор кода исправляет обнаруженные проблемы. Различие между чтением кода и инспекцией и анализом в том, что чте- ние кода в большей степени ориентировано на индивидуальный обзор кода, а не на собрание. Это позволяет каждому участнику обзора уделять больше времени непосредственно поиску проблем. Меньше времени тратится на проведение собраний, предполагающих, что каждый участник активен только часть времени, и требующих значительных усилий для координации действий группы. Меньше времени тратится на отсрочку собрания до тех пор, пока каждый член группы не найдет два свободных часа. Чтение кода особенно полезно, если учас- тников обзора разделяют большие расстояния. |