Совершенный код. Совершенный код. Мастер-класс. Стив Макконнелл. Руководство по стилю программирования и конструированию по
 Скачать 5.88 Mb.
|
|
ГЛАВА 19 Общие вопросы управления 453 Максимум в 10 точек принятия решения не является абсолютным ограничением. Используйте количество этих точек как сигнал, предупреждающий о том, что метод, возможно, стоит перепроектировать. Не считайте его неколебимым правилом. Оператор case со многими вариантами может иметь более 10 элементов, но в зависимости от назначения case может быть глупо разбивать его на части. Другие виды сложности Измерение сложности, предложенное Маккейбом, — не единственный значимый показатель, но он наиболее широко обсуждался в компьютерной литературе и особенно поле# зен при рассмотрении управляющей логики. Другие пока# затели включают количество используемых данных, число уровней вложенности в управляющих конструкциях, число строк кода, число строк между успешными обращениями к переменной («диапа# зон»), число строк, в которых используется переменная («время жизни») и объем ввода и вывода. Некоторые исследователи разработали составные показатели слож# ности, основанные на сочетании перечисленных простых вариантов. Контрольный список: вопросы по управляющим структурам Используют ли выражения идентификаторы true и false, а не 1 и 0? Сравниваются ли логические значения с true и false неявно? Сравниваются ли числовые значения со своими тестовыми значениями явно? Выполнено ли упрощение выражений с помощью введения новых логиче- ских переменных, использования логических функций и таблиц решений? Составлены ли логические выражения позитивно? Сбалансированы ли пары скобок? Используются ли скобки везде, где они необходимы для большей ясности? Заключены ли логические выражения в скобки целиком? Написаны ли условия в соответствии с расположением чисел на числовой прямой? Используются ли в программах на Java выражения вида a.equals(b), а не a == b там, где это необходимо? Очевидно ли применение пустых операторов? Выполнено ли упрощение глубоко вложенных выражений с помощью повтор- ной проверки части условия, преобразования в операторы if-then-else или case, перемещения части кода в отдельные методы, преобразования с ис- пользованием более обеъктно-ориентированной модели или они были улуч- шены как-то иначе? Если метод содержит более 10 точек принятия решения, есть ли хорошая причина, чтобы не перепроектировать его? Дополнительные сведения Отлич- ное обсуждение показателей сложности см. в «Software En– gineering Metrics and Models» (Conte, Dunsmore and Shen, 1986). http://cc2e.com/1985 454 ЧАСТЬ IV Операторы Ключевые моменты Упрощение и облегчение чтения логических выражений вносит существенный вклад в качество вашего кода. Глубокая вложенность затрудняет понимание метода. К счастью, вы сравнитель# но легко можете ее избежать. Структурное программирование — это простая, но все еще злободневная идея: вы можете построить любую программу с помощью комбинации последова# тельностей, выборов и итераций. Уменьшение сложности — ключ к написанию высококачественного кода. ГЛАВА 19 Общие вопросы управления 455 Часть V УСОВЕРШЕНСТВОВАНИЕ КОДА Глава 20. Качество ПО Глава 21. Совместное конструирование Глава 22. Тестирование, выполняемое разработчиками Глава 23. Отладка Глава 24. Рефакторинг Глава 25. Стратегии оптимизации кода Глава 26. Методики оптимизации кода 456 ЧАСТЬ V Усовершенствование кода Г Л А В А 2 0 Качество ПО Содержание 20.1. Характеристики качества ПО 20.2. Методики повышения качества ПО 20.3. Относительная эффективность методик контроля качества ПО 20.4. Когда выполнять контроль качества ПО? 20.5. Главный Закон Контроля Качества ПО Связанные темы Совместное конструирование: глава 21 Тестирование, выполняемое разработчиками: глава 22 Отладка: глава 23 Предварительные условия конструирования: главы 3 и 4 Актуальность предварительных условий для современных программных про# ектов: соответствующий подраздел раздела 3.1 В этой главе мы рассмотрим методики повышения качества ПО в контексте кон# струирования. Конечно, вся эта книга посвящена повышению качества ПО, но в данной главе вопросы качества и контроля качества обсуждаются более целена# правленно. Темой этой главы являются скорее общие вопросы, а не практичес# кие методики контроля качества. Практические советы, касающиеся совместной разработки, а также тестирования и отладки, можно найти в трех следующих главах. 20.1. Характеристики качества ПО Качество ПО имеет внешние и внутренние характеристики. К внешним характе# ристикам относятся свойства, которые осознает пользователь программы. Они описаны ниже. Корректность — отсутствие/наличие дефектов в спецификации, проекте и реализации системы. Практичность — легкость изучения и использования системы. http://cc2e.com/2036 ГЛАВА 20 Качество ПО 457 Эффективность — степень использования системных ресурсов. Эта характе# ристика учитывает такие факторы, как быстродействие приложения и требуе# мый им объем памяти. Надежность — способность системы выполнять необходимые функции в пред# определенных условиях; средний интервал между отказами. Целостность — способность системы предотвращать неавторизованный или некорректный доступ к своим программам и данным. Идея целостности под# разумевает ограничение доступа к системе для неавторизованных пользова# телей, а также обеспечение правильности доступа к данным, т. е. одновремен# ное изменение взаимосвязанных данных, хранение только допустимых значе# ний и т. д. Адаптируемость — возможность использования системы без ее изменения в тех областях или средах, на которые она не была ориентирована непосред# ственно. Правильность — степень безошибочности системы, особенно в отношении вывода количественных данных. Правильность характеризует выполнение системой ее функций, а не то, создана ли она корректно. Этим правильность отличается от корректности. Живучесть — способность системы продолжать работу при вводе недопус# тимых данных или в напряженных условиях. Некоторые из этих характеристик перекрываются, однако каждая имеет свои отли# чительные черты, которые в одних случаях выражены сильнее, а в других слабее. Внешние характеристики — единственная категория свойств ПО, которая волну# ет пользователей. Пользователей беспокоит легкость работы с ПО, а не легкость его изменения. Их заботит корректность ПО, а не удобочитаемость или структи# рованность кода. Программистов волнуют и внешние характеристики ПО, и внутренние. Раз уж эта книга посвящена программированию, основное внимание в ней уделяется внут# ренним характеристикам качества, которые перечислены ниже. Удобство сопровождения — легкость изменения программной системы с це# лью реализации дополнительных возможностей, повышения быстродействия, исправления дефектов и т. д. Гибкость — возможный масштаб изменения системы с целью использования ее в тех областях или средах, на которые она не была непосредственно ори# ентирована. Портируемость — легкость изменения системы с целью использования в сре# дах, на которые она не была ориентирована непосредственно. Возможность повторного использования — масштабность и легкость ис# пользования частей системы в других системах. Удобочитаемость — легкость чтения и понимания исходного кода системы, особенно на детальном уровне отдельных операторов. Тестируемость — возможная степень выполнения блочного и системного те# стирования программы и проверки ее соответствия требованиям. 458 ЧАСТЬ V Усовершенствование кода Понятность — легкость понимания системы и на уровне общей организации, и на детальном уровне отдельных операторов. Понятность характеризует со# гласованность системы на более общем уровне, чем удобочитаемость. Как и внешние, некоторые из этих внутренних характеристик качества перекры# ваются, но при этом каждая из них имеет важные отличительные черты. Внутренние характеристики качества ПО — главная тема этой книги, и в этой главе мы их подробнее рассматривать не будем. Различие между внутренними и внешними характеристиками качества размыто, потому что на некотором уровне первые влияют на вторые. Если программа не# достаточно понятна или неудобна в сопровождении, в ней трудно исправлять де# фекты, что в свою очередь влияет на такие внешние характеристики, как коррек# тность и надежность. ПО, страдающее от недостатка гибкости, нельзя улучшить в ответ на запросы пользователей, что сказывается на его практичности. Суть ска# занного в том, что одни характеристики качества облегчают жизнь пользовате# лям, а другие — программистам. Вам следует знать, какие из них какие, и пони# мать, когда и как эти характеристики взаимодействуют. Рис. 20'1. Концентрация на одной внешней характеристике качества ПО может влиять на другую характеристику положительно, отрицательно, а может и не влиять Улучшение некоторых аспектов качества неизбежно приводит к ухудшению дру# гих. Необходимость согласования решения с рядом противоречащих целей дела# ет разработку ПО поистине инженерной дисциплиной. Взаимосвязь внешних характеристик качества пояснена на рис. 20#1. Подобные отношения имеют мес# то и между внутренними характеристиками. Самый интересный аспект этой диаграммы в том, что концентрация на одной конкретной характеристике не всегда предполагает компромисс с другой харак# теристикой. Одни характеристики связаны между собой обратным отношением, другие — прямым, а третьи вообще не зависят друг от друга. Так, корректность характеризует степень, в которой работа системы соответствует спецификации. ГЛАВА 20 Качество ПО 459 Живучесть характеризует способность системы продолжать работу даже в непред# виденных условиях. Стремление повысить корректность приводит к снижению живучести и наоборот. В то же время концентрация на адаптируемости повыша# ет живучесть и наоборот. Диаграмма, показанная на рис. 20.1 иллюстрирует только типичные отношения между характеристиками качества. В конкретном проекте две характеристики могут быть связаны и нетипичным отношением. Поэтому при размышлении о качестве полезно думать о конкретных целевых характеристиках и о том, способствует одна из них достижению другой или препятствует. 20.2. Методики повышения качества ПО Контроль качества ПО — это планомерная и систематичная программа действий, призванная гарантировать, что система обладает желательными характеристика# ми. Вероятно, самый лучший способ разработки высококачественного приложе# ния — сосредоточиться на самом приложении, однако при контроле качества нужно также концентрироваться на процессе разработки. Целевые характеристики качества ПО Одной из эффективных методик по# вышения качества ПО является явное определение целевых внешних и внутрен# них характеристик. Не имея явных целей, программисты могут сосредоточиться не на тех характеристиках качества, на которых следовало бы. Явный контроль качества Одна распространенная проблема, связанная с кон# тролем качества, заключается в том, что качество воспринимается как вторичная цель. В некоторых организациях быстрое и «грязное» программирование является скорее правилом, чем исключением. Программисты вроде Глобального Гарри, ко# торые быстро «завершают» работу над программами, наполняя при этом их дефек# тами, получают большее вознаграждение, чем такие программисты, как Высокока# чественный Генри, которые пишут прекрасные программы, убеждаясь в их прак# тичности. Не следует удивляться тому, что в подобных организациях программис# ты не считают качество главным приоритетом. Руководители должны показать про# граммистам, что качество — одна из важнейших целей. Явный контроль качества делает это очевидным, и программисты отвечают соответствующим образом. Стратегия тестирования Тестирование программы может предоставить детальную оценку ее надежности. Частью контроля качества является разработка стратегии тестирова# ния, учитывающей требования к системе, ее архитектуру и проект. Довольно часто разработчики рассматривают тестирование как главный метод и оценки, и повыше# ния качества. В оставшейся части главы будет показано, что это слишком объемная задача, чтобы ее можно было выполнить исключительно путем тестирования. Принципы разработки ПО Технический характер ПО во время его разработки должен контролироваться рядом прин# ципов. Такие принципы используются на всех этапах раз# работки ПО, включая определение проблемы, выработку тре# бований, конструирование и тестирование системы. Прин# ципы разработки ПО, описываемые в этой книге, в некотором смысле являются принципами конструирования. Перекрестная ссылка О тести- ровании см. главу 22. Перекрестная ссылка Один класс принципов разработки ПО, актуальных для конструирова- ния, обсуждается в разделе 4.2. 460 ЧАСТЬ V Усовершенствование кода Неформальные технические обзоры Многие разработчики сами выполняют обзор своей работы до проведения формального обзора. Неформальный обзор может выражаться в самостоятельной проверке проекта или кода, а также в ана# лизе кода вместе с коллегами. Формальные технические обзоры Важный аспект уп# равления процессом разработки ПО — исправление проблем на этапе «наименьших затрат», т. е. когда на разработку си# стемы потрачен минимальный объем средств и когда решение проблемы окажется наиболее дешевым. Для достижения этой цели служат «ворота качества» — пери# одические тесты или обзоры, позволяющие определить, достаточным ли качеством обладает система на конкретном этапе разработки, чтобы перейти к следующему этапу. Ворота качества обычно используются при переходе от определения тре# бований к разработке архитектуры, от разработки архитектуры к конструирова# нию, а также от конструирования к тестированию системы. «Воротами» может быть инспекция, обзор системы, выполняемый коллегами или заказчиками, а также аудит. «Ворота качества» не предполагают, что этапы выработки требований или разработки архитектуры нужно выполнить на 100%; они позволяют определить, достаточно ли хоро# ши требования или архитектура, чтобы разработчики мог# ли перейти к следующим этапам. В одних случаях «ворота качества» могут требо# вать определения только самых важных аспектов архитектуры, а в других — оп# ределения почти всех деталей. Разумеется, это зависит от природы конкретного проекта. Внешний аудит Внешний аудит — это отдельный тип технического обзора, слу# жащий для определения статуса проекта или качества разрабатываемой системы. Аудит выполняют специалисты другой организации, которые сообщают резуль# таты своей работы тому, кто оплачивает аудит, обычно руководителям. Процесс разработки Каждый из упомянутых элементов явно связан с контролем качества и неявно — с процессом разработки ПО. Методи# ки разработки, включающие действия, направленные на контроль качества, способствуют созданию более качествен# ного ПО. Другие процессы, не являющиеся сами по себе аспектами контроля качества, также влияют на качество ПО. Процедуры контроля изменений Повышению качества ПО часто препятствуют неконтролируемые изменения. Не# контролируемые изменения требований могут снижать эф# фективность проектирования и кодирования. Неконтролируемые изменения про# екта могут приводить к несоответствию кода и требований, несогласованности отдельных фрагментов кода и лишней трате времени на вынужденное изменение кода. Неконтролируемые изменения самого кода могут приводить к появлению в нем внутренних противоречий и затрудняют слежение за тем, какой код был под# Перекрестная ссылка О зависи- мости подходов к разработке ПО от типа проекта см. раздел 3.2. Дополнительные сведения Разра- ботка ПО как процесс обсужда- ется в книге «Professional Software Development» (McConnell, 1994). Перекрестная ссылка О контро- ле изменений см. раздел 28.2. Перекрестная ссылка Об обзо- рах и инспекциях см. главу 21. ГЛАВА 20 Качество ПО 461 вергнут полному обзору и тестированию, а какой — нет. Изменения естественным образом вызывают дестабилизацию системы и снижение ее качества, поэтому эф# фективный контроль изменений — важнейшее условие достижения высокого ка# чества ПО. Оценка результатов Только оценив результаты выполнения плана контроля качества, вы сможете узнать, эффективен ли он. Оценка позволяет не только уз# нать эффективность плана, но и изменить процесс разработки контролируемым образом с целью его улучшения. Кроме того, вы можете извлечь дополнительную выгоду, оценивая сами атрибуты качества: корректность, практичность, эффектив# ность и т. д. Обсуждение оценки атрибутов качества см. в главе 9 книги «Principles of Software Engineering» (Gilb, 1988). Прототипирование Прототипированием называют разработку реа# листичных моделей важных функций системы. Так, разработчики могут использовать прототипирование для определения удобства пользователь# ского интерфейса, времени выполнения важных вычислений или объема памя# ти, нужного для хранения типичных наборов данных. Анализ 16 опубликованных и 8 неопубликованных исследований конкретных случаев, посвященный сравне# нию прототипирования с традиционными методиками разработки, основанны# ми на спецификациях, показал, что прототипирование повышает эффективность проектирования, способствует более полному удовлетворению потребностей пользователей и облегчает сопровождение ПО (Gordon and Bieman, 1991). Задание целей Явное задание целевых аспектов качества — простой и очевидный способ повы# шения качества ПО, но его легко упустить. Будут ли программисты на самом деле преследовать явные заданные цели? Да, будут, если цели будут им известны и если цели будут разумны. Программисты не могут стремиться к достижению постоян# но изменяющихся или недостижимых . Джеральд Вайнберг и Эдвард Шульман провели один очень интересный экспери# мент, посвященный изучению влияния задания целевых аспектов качества на производительность труда программистов (Weinberg and Schulman, 1974). Они попросили пять групп разработчиков написать одну и ту же программу и указали одни и те же пять целевых характеристик качества, но каждой группе было ска# зано оптимизировать разные характеристики: одной — минимизировать объем используемой программой памяти, второй — обратить максимальное внимание на ясность выводимых данных, третьей — создать как можно более удобочитае# мый код, четвертой — сделать программу максимально компактной, а пятой — написать программу за минимальное время. В табл. 20#1 показано, какое место заняла каждая группа по каждому целевому показателю. 462 ЧАСТЬ V Усовершенствование кода Табл. 20-1. Места, занятые каждой группой по каждому целевому показателю Целевая характеристика качества, на которую Читабель- группа должна была Минималь- ность выво- Читабель- Минималь- обратить максимальное ный объем димых ность Компакт- ное время внимание памяти данных кода ность кода разработки Минимальный объем 1 4 4 2 5 памяти Читабельность 5 1 1 5 3 выводимых данных Читабельность кода 3 2 2 3 4 Компактность кода 2 5 3 1 3 Минимальное время 4 3 5 4 1 разработки Источник: «Goals and Performance in Computer Programming» (Weinberg and Schulman, 1974). Результаты впечатляют: четыре из пяти групп выполнили поставленные перед ними задачи лучше всех остальных групп. Оставшаяся группа за# няла в своей категории второе место. Никакой группе не удалось преус# петь в достижении всех целей. Что из этого следует? То, что люди на самом деле делают то, о чем вы их просите. Программисты действительно стремятся к достижению поставленных целей, но они должны знать, что это за цели. И еще одно следствие: как и ожидалось, целе# вые характеристики качества конфликтуют, поэтому преуспеть в достижении всех целей почти невозможно. 20.3. Относительная эффективность методик контроля качества ПО Не все методики контроля качества имеют одинаковую эффективность. Эффек# тивность многих методик в плане нахождения и устранения дефектов уже извес# тна. В данном разделе мы обсудим этот и некоторые другие аспекты «эффектив# ности» методик контроля качества. Эффективность обнаружения дефектов Некоторые методики более эффективны в обнаружении дефектов, чем другие, к тому же разные методики приводят к обнаружению разных дефектов. Одним из способов оценки методик нахождения дефектов является определение про# цента обнаруженных дефектов из общего числа дефектов, имеющихся в программе на конкретном этапе. Показатели эффективности нахождения дефектов при использовании некоторых популярных методик указаны в табл. 20#2. Если бы строители возводили здания так, как программисты пишут программы, первый же дятел уничтожил бы цивилизацию. Джеральд Вайнберг (Gerald Weinberg) |