Совершенный код. Совершенный код. Мастер-класс. Стив Макконнелл. Руководство по стилю программирования и конструированию по
 Скачать 5.88 Mb.
|
|
ГЛАВА 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 строк в день. После того как участники обзора завершили чтение кода, автор кода прово# дит собрание. Собрание продолжается один#два часа и фокусируется на про# блемах, обнаруженных при чтении кода. Никто не пытается анализировать код строку за строкой. Строго говоря, собрание даже не является необходимостью. Автор кода исправляет обнаруженные проблемы. Различие между чтением кода и инспекцией и анализом в том, что чте# ние кода в большей степени ориентировано на индивидуальный обзор кода, а не на собрание. Это позволяет каждому участнику обзора уделять больше времени непосредственно поиску проблем. Меньше времени тратится на проведение собраний, предполагающих, что каждый участник активен только часть времени, и требующих значительных усилий для координации действий группы. Меньше времени тратится на отсрочку собрания до тех пор, пока каждый член группы не найдет два свободных часа. Чтение кода особенно полезно, если учас# тников обзора разделяют большие расстояния. ГЛАВА 21 Совместное конструирование 487 Изучив результаты 13 обзоров, специалисты AT&T обнаружили, что важ# ность собраний, посвященных обзору, была относительно невысокой: 90% дефектов разработчики находили при подготовке к собраниям и только около 10% во время самих собраний (Votta, 1991; Glass, 1999). Презентация Презентацией (dog#and#pony show) называют обзор, при котором система демон# стрируется заказчику. Такие обзоры — обычное дело при разработке ПО для пра# вительственных организаций, которые часто требуют выполнения обзоров тре# бований, проектов и кода. Цель презентации — показать заказчику, что работа продвигается успешно, так что это обзор, выполняемый руководителями, а не технический обзор. Не рассматривайте презентации как способ повышения технического качества продукции. Подготовка к ним может оказывать косвенное влияние на техниче# ское качество, но обычно при этом больше времени тратится на подготовку эф# фектных слайдов, а не на повышение качества ПО. Для повышения технического качества ПО используйте инспекции, анализ или чтение кода. 21.5. Сравнение методик совместного конструирования Каковы различия между разными методиками совместного конструирования? Основные характеристики каждой методики указаны в табл. 21#1. Табл. 21-1. Сравнение методик совместного конструирования Парное Формальная Неформальный Характеристика программирование инспекция обзор (анализ) Назначаются ли участникам Да Да Нет конкретные роли? Проводится ли формальное Возможно Да Нет обучение исполнению конкретных ролей? Кто «управляет» Разработчик, сидящий Координатор Обычно автор сотрудничеством? за клавиатурой Фокус сотрудничества Проектирование, коди# Только обнаруже# Разный рование, тестирование ние дефектов и исправление дефектов Сфокусирован ли обзор? Действия фокусируются Да Нет Направляются ли усилия неформально, если на поиск наиболее частых вообще фокусируются типов ошибок? Выполняется ли контроль Да Да Нет исправления найденных ошибок? Предоставляется ли отдель# Это второстепенный Да Это второсте# ным программистам подроб# фактор пенный фактор ная обратная связь для сокращения числа ошибок в будущем? ( см. след. стр.) 488 ЧАСТЬ V Усовершенствование кода Табл. 21-1. (окончание) Парное Формальная Неформальный Характеристика программирование инспекция обзор (анализ) Используется ли анализ Нет Да Нет результатов для повышения эффективности процесса? Полезна ли методика Возможно Да Да не на этапе конструиро# вания? Типичный процент 40–60% 45–70% 20–40% обнаруживаемых дефектов В отличие от формальных инспекций эффективность парного программирова# ния не подтверждена десятилетиями исследований, но первоначальные данные свидетельствуют о том, что оно примерно эквивалентно инспекциям; отзывы компаний, использующих парное программирование, также положительны. Если парное программирование и формальные инспекции примерно эквивален# тны по показателям качества итогового кода, стоимости и быстроты разработки, при выборе одной из этих двух методик можно руководствоваться личными пред# почтениями, а не техническими аспектами. Кому#то нравится работать в одиноч# ку, лишь иногда отказываясь от этого режима для проведения инспекционных собраний. Кто#то предпочитает сотрудничество с коллегами. Выбрать методику можно на основе предпочтений конкретных членов группы, а подгруппам мож# но позволить самим выбрать способ выполнения большей части работы. Можете комбинировать разные методики, если это целесообразно. Дополнительные ресурсы Ниже я указал ряд работ, посвященных методикам совмес# тного конструирования. Парное программирование Williams, Laurie and Robert Kessler. Pair Programming Illuminated. Boston, MA: Add# ison Wesley, 2002. В этой книге подробно рассматриваются все аспекты парного программирования, в том числе соответствие личностей (например, эксперт и новичок, интроверт и экстраверт) и другие вопросы реализации. Beck, Kent. Extreme Programming Explained: Embrace Change. Reading, MA: Addison Wesley, 2000. Кент Бек вкратце рассматривает парное программирование и пока# зывает, как его улучшить, дополнив другими методиками, такими как определение стандартов кодирования, частая интеграция и регрессивное тестирование. Reifer, Donald. «How to Get the Most Out of Extreme Programming/Agile Methods», Pro% ceedings, XP/Agile Universe 2002. New York, NY: Springer; pp. 185–196. В этой статье обобщен опыт использования экстремального программирования и методик гибкой разработки, а также указаны условия успешности парного программирования. http://cc2e.com/2106 ГЛАВА 21 Совместное конструирование 489 Инспекции Wiegers, Karl. Peer Reviews in Software: A Practical Guide. Boston, MA: Addison Wesley, 2002. В этой книге подробно рассматриваются разные виды обзоров, в том числе формальные инспекции и менее формальные методики. Она основана на тщатель# ных исследованиях, имеет практическую направленность и легко читается. Gilb, Tom and Dorothy Graham. Software Inspection. Wokingham, England: Addison# Wesley, 1993. В этой книге подробно обсуждаются инспекции, выполнявшиеся в начале 1990#х. Она имеет практическую направленность и включает исследова# ния конкретных инспекционных программ, проводившихся в нескольких орга# низациях. Fagan, Michael E. «Design and Code Inspections to Reduce Errors in Program Develop# ment». IBM Systems Journal, 15, no. 3 (1976): 182–211. Fagan, Michael E. «Advances in Software Inspections». IEEE Transactions on Software Engineering, SE#12, no. 7 (July 1986): 744–51. Две этих статьи написаны разработ# чиком методики инспекций. В них вы найдете суть того, что нужно знать для проведения инспекций, в том числе описание всех стандартных форм инспекций. Соответствующие стандарты IEEE Std 1028%1997 — стандарт обзоров ПО. IEEE Std 730%2002 — стандарт планирования контроля качества ПО. Ключевые моменты Как правило, методики совместной разработки позволяют находить больше дефектов, чем тестирование, и делать это более эффективно. Методики совместной разработки и тестирование приводят к обнаружению разных типов ошибок, поэтому программа контроля качества ПО должна вклю# чать и обзоры, и тестирование. Главными аспектами формальной инспекции, обеспечивающими максималь# ную эффективность обнаружения дефектов, являются использование конт# рольных списков, подготовка, назначение хорошо определенных ролей и по# стоянное улучшение процесса. Формальная инспекция — более эффективный способ обнаружения дефектов, чем анализ проекта или кода. Парное программирование и инспекции примерно эквивалентны по показа# телям расходов и качества итогового кода. Парное программирование может оказаться особенно полезным, если вы хотите сократить срок разработки си# стемы. Некоторые разработчики предпочитают работать в паре, а не самосто# ятельно. Формальные инспекции можно использовать для проверки не только кода, но и других результатов труда, таких как требования, проекты и тесты. Анализ и чтение кода — альтернативы инспекциям. Чтение кода позволяет каждому участнику более эффективно использовать свое время. 490 ЧАСТЬ V Усовершенствование кода Г Л А В А 2 2 Тестирование, выполняемое разработчиками Содержание 22.1. Тестирование, выполняемое разработчиками, и качество ПО 22.2. Рекомендуемый подход к тестированию, выполня# емому разработчиками 22.3. Приемы тестирования 22.4. Типичные ошибки 22.5. Инструменты тестирования 22.6. Оптимизация процесса тестирования 22.7. Протоколы тестирования Связанные темы Качество ПО: глава 20 Методики совместного конструирования: глава 21 Отладка: глава 23 Интеграция: глава 29 Предварительные условия конструирования: глава 3 Тестирование — самая популярная методика повышения качества, подкрепленная многими исследованиями и богатым опытом разработки коммерческих прило# жений. Существует множество видов тестирования: одни обычно выполняют сами разработчики, а другие — специализированные группы. Виды тестирования пе# речислены ниже. Блочным тестированием называют тестирование полного класса, метода или небольшого приложения, написанного одним программистом или группой, выполняемое отдельно от прочих частей системы. Тестирование компонента — это тестирование класса, пакета, небольшого при# ложения или другого элемента системы, разработанного несколькими програм# мистами или группами, выполняемое в изоляции от остальных частей системы. http://cc2e.com/2261 ГЛАВА 22 Тестирование, выполняемое разработчиками 491 Интеграционное тестирование — это совместное выполнение двух или бо# лее классов, пакетов, компонентов или подсистем, созданных несколькими программистами или группами. Этот вид тестирования обычно начинают про# водить, как только созданы два класса, которые можно протестировать, и про# должают до завершения работы над системой. Регрессивным тестированием называют повторное выполнение тестов, направ# ленное на обнаружение дефектов в программе, уже прошедшей этот набор тестов. Тестирование системы — это выполнение ПО в его окончательной конфигу# рации, интегрированного с другими программными и аппаратными система# ми. Предметом тестирования в этом случае являются безопасность, произво# дительность, утечка ресурсов, проблемы синхронизации и прочие аспекты, которые невозможно протестировать на более низких уровнях интеграции. В этой главе «тестированием» я называю тестирование, выполняемое разработ# чиками, которое обычно включает три первых вида тестирования из приведен# ного списка, но иногда может включать также регрессивное тестирование и тес# тирование системы. Многие другие виды тестирования обычно выполняют не раз# работчики, а специализированный персонал: в качестве примеров можно приве# сти бета#тестирование, тестирование системы на предмет одобрения заказчиком, тестирование производительности, тестирование конфигурации, платформенное тестирование, тестирование в стрессовом режиме, тестирование удобства исполь# зования и т. д. Эти виды тестирования мы рассматривать не будем. Тестирование обычно разделяют на две обширных категории: «тестиро# вание методом черного ящика» и «тестирование методом белого (про# зрачного) ящика». В первом случае тестировщик не владеет сведениями о внутренней работе тестируемого элемента. Очевидно, что это не так, если вы тестируете собственный код. При тестировании методом белого ящика внутрен# няя реализация тестируемого элемента тестировщику известна. Тестируя собствен# ный код, вы используете именно этот вид тестирования. Оба вида имеют свои плюсы и минусы; в данной главе основное внимание уделяется тестированию методом белого ящика, потому что именно его выполняют сами разработчики. Порой термины «тестирование» и «отладка» используют взаимозаменяемо, но внимательные программисты различают два этих процесса. Тестирование — это средство обнаружения ошибок, тогда как отладка является средством поиска и устранения причин уже обнаруженных ошибок. Эта глава посвящена исключитель# но обнаружению ошибок. Об исправлении ошибок см. главу 23. Тема тестирования не ограничивается тестированием во время конструирования. Информацию о тестировании системы, тестировании в стрессовом режиме, тес# тировании методом черного ящика и других вопросах, ориентированных на спе# циалистов по тестированию, можно найти в работах, указанных в разделе «До# полнительные ресурсы» в конце главы. 492 ЧАСТЬ V Усовершенствование кода 22.1. Тестирование, выполняемое разработчиками, и качество ПО Тестирование — важная часть любой программы контроля качества, а зачастую и единственная. Это печально, так как разнообразные методики совместной разработки позволя# ют находить больше ошибок, чем тестирование, и в то же время обходятся более чем вдвое дешевле в расчете на одну обнаруженную ошибку (Card, 1987; Russell, 1991; Kaplan, 1995). Каждый из отдельных этапов тестирования (блочное тести# рование, тестирование компонентов и интеграционное тестирование) обычно позволяет найти менее 50% ошибок. Комбинация этапов тестирования часто при# водит к обнаружению менее 60% ошибок (Jones, 1998). Если у программиста спросить, какой из этапов разработ# ки ПО менее всего похож на другие, он наверняка ответит: «Тестирование». По ряду описанных ниже причин большин# ство разработчиков испытывают при тестировании затруд# нения. Цель тестирования противоположна целям других эта# пов разработки. Его целью является нахождение ошибок. Успешным считается тест, нарушающий работу ПО. Все ос# тальные этапы разработки направлены на предотвращение ошибок и недопу# щение нарушения работы программы. Тестирование никогда не доказывает отсутствия ошибок. Если вы тщательно протестировали программу и обнаружили тысячи ошибок, значит ли это, что вы нашли все ошибки или в программе все еще остались тысячи других оши# бок? Отсутствие ошибок может указывать как на безупречность программы, так и на неэффективность или неполноту тестов. Тестирование не повышает качества ПО — оно указывает на качество програм# мы, но не влияет на него. Стремление повысить качество ПО за счет увеличе# ния объема тестирования подобно попытке снижения веса путем более час# того взвешивания. То, что вы ели, прежде чем встать на весы, определяет, сколько вы будете весить, а использованные вами методики разработки ПО определя# ют, сколько ошибок вы обнаружите при тестировании. Если вы хотите снизить вес, нет смысла покупать новые весы — измените вместо этого свой рацион. Если вы хотите улучшить ПО, вы должны не тестировать больше, а програм# мировать лучше. Тестирование требует, чтобы вы рассчитывали найти ошибки в сво# ем коде. В противном случае вы, вероятно, на самом деле их не найдете, но это будет всего лишь самоисполняющимся пророчеством. Если вы за# пускаете программу в надежде, что она не содержит ошибок, их будет слиш# ком легко не заметить. В исследовании, которое уже стало классическим, Глен# форд Майерс попросил группу опытных программистов протестировать про# грамму, содержащую 15 известных дефектов. В среднем программисты нашли лишь 5 из 15 ошибок. Лучший программист обнаружил только 9. Главной при# чиной неэффективного обнаружения ошибок было недостаточно вниматель# Перекрестная ссылка Об обзо- рах ПО см. главу 21. Программы — не люди, а ошиб- ки — не микробы: программа не может нахвататься ошибок, об- щаясь с другими дефектными программами. Ошибки всегда допускают программисты. Харлан Миллз (Harlan Mills) |