Совершенный код. Совершенный код. Мастер-класс. Стив Макконнелл. Руководство по стилю программирования и конструированию по
 Скачать 5.88 Mb.
|
|
ГЛАВА 20 Качество ПО 471 Г Л А В А 2 1 Совместное конструирование Содержание 21.1. Обзор методик совместной разработки ПО 21.2. Парное программирование 21.3. Формальные инспекции 21.4. Другие методики совместной разработки ПО Связанные темы Качество ПО: глава 20 Тестирование, выполняемое разработчиками: глава 22 Отладка: глава 23 Предварительные условия конструирования: главы 3 и 4 Вероятно, вам знакома одна довольно распространенная ситуация. Вы подходите к столу другого программиста и говорите: «Не мог бы ты взглянуть на этот код? Он не работает». Вы начинаете объяснять: «Причиной не может быть вот это, потому что я сделал то#то и то#то. Причиной также не может быть это, потому что я сделал вот это. Кроме того, причиной не может быть… подожди… Это может быть причи# ной. Спасибо!» Вы решили проблему, хотя ваш «помощник» не произнес ни слова. Так или иначе все методики совместного конструирования направлены на фор# мализацию процесса проверки вашей работы другими программистами с целью устранения ошибок. Если вы уже читали об инспекциях и парном программировании, вы найдете в этой главе мало нового. Возможно, вас заинтересуют данные об эффективности инспекций (раздел 21.3), а также методика чтения кода (раздел 21.4). Вы также можете взглянуть на табл. 21#1 «Сравнение методик совместного конструирова# ния» в конце главы. Если ваши знания основаны только на опыте, читайте даль# ше! Каждый человек имеет собственный опыт, поэтому некоторые идеи окажутся для вас новыми. http://cc2e.com/2185 472 ЧАСТЬ V Усовершенствование кода 21.1. Обзор методик совместной разработки ПО «Совместным конструированием» можно называть парное программирование, формальные инспекции, неформальные технические обзоры, чтение документа# ции, а также другие методики, подразумевающие разделение ответственности за те или иные результаты работы между несколькими программистами. В моей ком# пании термин «совместное конструирование» ввел в обиход Мэтт Пелокуин (Matt Peloquin) где#то в 2000 году. По#видимому, примерно тогда же независимо от нас этот термин стали использовать и в других компаниях. Все методики совместного конструирования основаны на идее, что раз# работчики плохо находят определенные дефекты в своей работе и что каждый человек имеет свои недостатки, поэтому качество работы повы# сится, если ее проверит кто#то другой. Исследования, проведенные в Институте разработки ПО (Software Engineering Institute), показали, что разработчики допус# кают в среднем от 1 до 3 дефектов в час при проектировании и от 5 до 8 дефек# тов в час при кодировании (Humphrey, 1997). Ясно, что устранение этих дефек# тов — обязательное условие эффективного конструирования. Совместное конструирование дополняет другие методики контроля качества Главной целью совместного конструирования является повышение каче# ства ПО. Как уже отмечалось в главе 20, само по себе тестирование ПО имеет довольно невысокую эффективность: средний уровень определе# ния дефектов равен примерно 30% при блочном тестировании, 35% при интег# рационном тестировании и 35% при ограниченном бета#тестировании. В то же время средняя эффективность инспекций проектов и кода равна соответственно 55% и 60% (Jones, 1996). Дополнительное преимущество совместного конструи# рования состоит в том, что оно сокращает время разработки, что в свою очередь снижает расходы. Предварительные отчеты о результатах парного программирования го# ворят о том, что оно позволяет достигнуть примерно такого же качества кода, что и формальные инспекции (Shull et al., 2002). Затраты на разра# ботку при применении только парного программирования оказываются примерно на 10–25% выше, чем при программировании в одиночку, но зато сокращение сро# ков разработки составляет около 45%, что может оказаться решающим преиму# ществом над разработкой в одиночку (Boehm and Turner, 2004), хотя не над инс# пекциями, которые приводят к похожим результатам. Технические обзоры изучаются гораздо дольше, чем парное программирование, и результаты проведенных исследований впечатляют. В IBM обнаружили, что каждый час инспекции предотвращал около 100 часов аналогичной работы (тестирования и исправления дефектов) (Holland, 1999). ГЛАВА 21 Совместное конструирование 473 Принятие инициативы, основанной на инспекциях, позволило компании Ray# theon снизить объем затрат на исправление дефектов с 40% общей стоимости проектов примерно до 20% (Haley, 1996). Специалисты Hewlett#Packard сообщили, что благодаря программе инспекций они добились экономии примерно 21,5 млн долларов в год (Grady and Van Slack, 1994). В компании Imperial Chemical Industries обнаружили, что затраты на сопровож# дение пакета, состоящего примерно из 400 программ, составляли лишь около 10% от затрат на сопровождение аналогичного пакета программ, которые не были подвергнуты инспекции (Gilb and Graham, 1993). Исследование крупных программ показало, что каждый час инспекций предот# вращал в среднем 33 часа сопровождения программ и что инспекции иногда были аж в 20 раз эффективнее тестирования (Russell, 1991). В организации, занимающейся сопровождением ПО, до введения обзоров кода изменения одной строки оказывались ошибочными в 55% случаев. После вве# дения обзоров этот показатель снизился до 2% (Freedman and Weinberg, 1990). В целом после введения обзоров программисты стали правильно выполнять с первого раза 95% изменений. До введения обзоров с первого раза правильно выполнялись менее 20% изменений. Одна группа программистов разработала 11 программ. Первые пять, разрабо# танные без выполнения обзоров, содержали в среднем 4,5 ошибки на 100 строк кода. Другие шесть программ, подвергавшиеся инспекциям, содержали в сред# нем 0,82 ошибки на 100 строк кода. Иначе говоря, проведение обзоров сни# жало уровень ошибок более чем на 80% (Freedman and Weinberg, 1990). Кейперс Джонс сообщает, что во всех изученных им программных проектах с 99%#ым или более высоким уровнем устранения дефектов использовались формальные инспекции. С другой стороны, ни в одном проекте с 75%#ой или более низкой эффективностью устранения дефектов формальные инспекции не проводились (Jones, 2000). Многие из этих исследований подтверждают Главный Закон Контроля Качества ПО, согласно которому уменьшение числа дефектов в программе приводит к со# кращению времени ее разработки. Самые разные исследования показали, что методики совместной разра# ботки не только обеспечивают более высокую эффективность нахожде# ния ошибок, чем тестирование, но и позволяют находить типы ошибок, на которые тестирование указать не может (Myers 1978; Basili, Selby, and Hutchens, 1986). Как сказал Карл Вигерс, «человек, выполняющий обзор, может обратить вни# мание на неясные сообщения об ошибках, неадекватные комментарии, жестко за# кодированные значения переменных и повторяющиеся фрагменты кода, которые следует объединить. При тестировании все это невозможно» (Wiegers, 2002). Кроме того, программисты, знающие, что их работа будет подвергнута обзору, выпол# няют ее более добросовестно. Таким образом, даже при высокой эффективности тестирования в программу контроля качества следует включить обзоры или дру# гие методики совместной разработки. 474 ЧАСТЬ V Усовершенствование кода Совместное конструирование способствует усвоению корпоративной культуры и обмену опытом программирования Стандарты программирования можно выразить на бумаге и распространить среди сотрудников, но если их не обсуж# дать и не поощрять их применение, никто не будет их со# блюдать. Обзоры — важный механизм предоставления про# граммистам обратной связи, касающейся их кода. Код, стан# дарты и причины стандартизации кода — все эти темы до# стойны обсуждения во время обзоров. Программисты должны получать информацию не только о том, насколько хорошо они следуют стандартам, но и о более субъективных аспектах программирования, таких как фор# матирование, использование комментариев, имен перемен# ных, локальных и глобальных переменных, методик проек# тирования и т. д. Начинающие программисты нуждаются в советах более опытных коллег, а более опытные и, как пра# вило, более занятые — в мотивации, которая подтолкнула бы их к передаче опыта. Обзоры — тот механизм, который создает начинающим и опытным программистам все усло# вия для обсуждения технических вопросов. Таким образом, обзоры способству# ют повышению качества не только текущего кода, но и будущих программ. В одной группе было обнаружено, что использование формальных инспекций быстро повысило компетентность всех разработчиков до уровня самых лучших (Tackett and Van Doren, 1999). Все формы совместного конструирования предполагают совместное владение результатами работы При совместном владении весь код принадлежит группе, а не отдельным программистам, поэтому изучать и изменять его могут разные члены группы. Это обеспечивает несколько важных преимуществ: увеличение числа программистов, разрабатывающих и анализирующих конкретный код, способствует повышению его качества; уход одного из участников проекта не приводит к серь# езным последствиям, потому что каждый фрагмент кода известен нескольким программистам; возможность поручить исправление ошибок любому из нескольких программистов позволяет ускорить исправле# ние дефектов. В некоторых методологиях, таких как экстремальное программирование, реко# мендуется формально объединять программистов в пары и чередовать задания, назначенные конкретным парам. В моей компании обнаружили, что и без фор# Неформальные процедуры об- зоров передавались от челове- ка человеку в общей культуре программирования задолго до того, как информация об этом стала появляться в печатных ма- териалах. Необходимость обзо- ров была настолько очевидна лучшим программистам, что они редко упоминали об этом в ста- тьях и книгах, тогда как худшие программисты считали, что они настолько хороши, что их рабо- та не нуждается в обзорах. Дениел Фридмен и Джеральд Вайнберг (Daniel Freedman and Gerald Weinberg) Перекрестная ссылка Все мето- дики совместного конструиро- вания объединяет идея совме- стного владения. В некоторых моделях разработки код при- надлежит его автору, а возмож- ность изменения кода других программистов ограничивается писаными или неписаными пра- вилами. Совместное владение предъявляет более высокие тре- бования к координации труда, особенно к управлению конфи- гурацией ПО (см. раздел 28.2). ГЛАВА 21 Совместное конструирование 475 мальной организации пар программисты могут по ходу дела хорошо ознакомиться с кодом своих коллег. Для этого мы комбинируем формальные и неформальные технические обзоры, используем в случае надобности парное программирование и поручаем исправление дефектов поочередно разным программистам. Сотрудничество возможно не только во время конструирования, но и до и после него Эта книга посвящена конструированию, поэтому основное внимание в этой гла# ве уделяется сотрудничеству при детальном проектировании и кодировании. Однако большинство принципов совместного конструирования, описываемых в этой главе, можно использовать и на этапах оценки, планирования, определения требований, разработки архитектуры, тестирования и сопровождения програм# мы. Изучив ресурсы, указанные в конце этой главы, вы сможете применять мето# дики совместной разработки на большинстве этапов создания ПО. 21.2. Парное программирование При парном программировании один программист печатает код на клавиатуре, а второй следит за тем, чтобы в программу не вкрались ошибки, и думает о пра# вильности кода в стратегическом масштабе. Первоначально парное программи# рование приобрело популярность благодаря экстремальному программированию (Beck, 2000), но теперь парное программирование используется более широко (Williams and Kessler, 2002). Условия успешности парного программирования Базовая идея парного программирования проста, но из него можно извлечь еще большую выгоду, следуя нескольким советам. Поддерживайте парное программирование стандартами кодирования Парное программирование не будет эффективным, если члены пары будут тратить время на споры о стиле кодирования. Попытайтесь стандартизовать то, что в главе 5 было названо «несущественными атрибутами» программирования, чтобы програм# мисты могли сосредоточиться на стоящей перед ними «существенной» задаче. Не позволяйте парному программированию превратиться в наблюдение Член пары, не занимающийся непосредственно написанием кода, должен быть активным участником программирования. Он должен анализировать код, думать о том, что реализовать в следующую очередь, оценивать проект программы и планировать тестирование кода. Не используйте парное программирование для реализации простых фраг' ментов Члены одной группы, использовавшие парное программирование для написания наиболее сложного кода, обнаружили, что выгоднее посвятить 15 ми# нут детальному проектированию на доске и затем программировать поодиночке (Manzo, 2002). В большинстве организаций, пробующих парное программирова# ние, в итоге приходят к выводу, что в парах лучше выполнять не все, а только некоторые части работы (Boehm and Turner, 2004). 476 ЧАСТЬ V Усовершенствование кода Регулярно меняйте состав пар и назначаемые парам задачи Как и при дру# гих методиках совместной разработки, при парном программировании выгода объясняется тем, что каждый из программистов изучает разные части системы. Регулярно меняйте состав пар для стимуляции «перекрестного опыления» — не# которые эксперты рекомендуют выполнять это каждый день (Reifer, 2002). Объединяйте в пару людей, предпочитающих одинаковый темп работы Если один партнер работает слишком быстро, парное программирование начи# нает терять смысл. Более быстрый член пары должен снизить темп, или пару сле# дует разбить и сформировать в другом составе. Убедитесь, что оба члена пары видят экран Эффективность парного про# граммирования могут снижать даже такие, казалось бы, банальные вопросы, как не# правильное расположение монитора и слишком мелкий шрифт. Не объединяйте в пару людей, которые не нравятся друг другу Эффек# тивность работы в паре зависит от соответствия характеров двух программистов. Бессмысленно объединять в пару людей, которые плохо ладят друг с другом (Beck, 2000; Reifer, 2002). Не составляйте пару из людей, которые ранее не программировали в паре Парное программирование приносит максимальную выгоду, если хотя бы один из партнеров имеет опыт работы в паре (Larman, 2004). Назначьте лидера группы Если все члены вашей группы хотят выполнить все программирование в парах, возложите на кого#то ответственность за распреде# ление задач, контроль результатов и связь с людьми, не участвующими в проекте. Достоинства парного программирования Парное программирование имеет целый ряд достоинств. В сравнении с одиночным программированием оно позволяет программистам успешнее противостоять стрессу. Члены пар поощряют друг друга поддержи# вать высокое качество кода даже в напряженных условиях, подталкивающих к быстрому написанию «грязного» кода. Оно повышает качество кода. Удобочитаемость и понятность кода всех про# граммистов повышаются до уровня кода лучшего программиста группы. Оно ускоряет разработку системы. Как правило, пары пишут код быстрее, до# пуская при этом меньше ошибок. Соответственно в конце проекта группе при# ходится тратить меньше времени на исправление дефектов. Оно обеспечивает все остальные общие преимущества совместного констру# ирования, такие как распространение корпоративной культуры, обучение не# опытных программистов и содействие совместному владению результатами работы. ГЛАВА 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% бюджета проекта и обычно снижают общую сумму расхо# дов на реализацию системы. Инспекции позволяют также оценить прогресс, но только технический. Как пра# вило, для этого нужно узнать, выполняются ли технические аспекты работы и хорошо ли они выполняются. Ответы на оба этих вопроса являются побочными продуктами формальных инспекций. Роли участников инспекции Один из важнейших аспектов инспекции состоит в том, что каждый ее участник играет свою особую роль. Координатор Координатор должен поддерживать темп инспекции достаточ# но высоким, чтобы она была продуктивной, и в то же время достаточно низким, чтобы участники инспекции могли найти максимум ошибок. Координатор дол# жен обладать адекватной технической компетентностью: он может не быть экс# пертом в конкретном фрагменте инспектируемого проекта или кода, но обязан понимать соответствующие детали. Координатор также управляет другими аспек# тами инспекции, такими как распределение фрагментов проекта или кода между инспекторами, распространение контрольных списков инспекции, организация собрания, отчет о результатах инспекции и контроль решения задач, поставлен# ных на инспекционном собрании. Автор Автор проекта или кода играет во время инспекции относительно неболь# шую роль. Одной из целей инспекции как раз и является гарантия того, что про# ект или код говорит сам за себя. Если проект или код, подвергающийся инспек# ции, кажется неясным, автору поручают его улучшить. Иначе автор должен объяс# нить не совсем ясные части проекта или кода и, если нужно, рассказать, почему аспекты, которые кажутся ошибочными, на самом деле такими не являются. Если инспекторы плохо знакомы с конкретной частью системы, автор может предо# ставить им полезную информацию при подготовке к инспекционному собранию. |