Совершенный код. Совершенный код. Мастер-класс. Стив Макконнелл. Руководство по стилю программирования и конструированию по
 Скачать 5.88 Mb.
|
|
ГЛАВА 3 Семь раз отмерь, один раз отрежь: предварительные условия 49 Купить или создавать самим? Самый радикальный подход к созданию ПО — не создавать его вообще, а купить или загрузить из Интернета бесплат# ное ПО с открытым исходным кодом. Вы можете приобре# сти элементы управления GUI, менеджеры БД, процессоры изображений, компоненты для работы с графикой и диа# граммами, компоненты для коммуникации по Интернету, компоненты обеспечения безопасности и шифрования, обработки электронных таблиц и текста — список почти бесконечен. Одним из главных достоинств про# граммирования с использованием современных GUI#сред является объем функ# циональности, который вы получаете автоматически: классы для работы с графи# кой, менеджеры диалоговых окон, обработчики событий клавиатуры и мыши, код, поддерживающий любые принтеры и мониторы и т. д. Если архитектура не подразумевает применение готовых компонентов, она дол# жна объяснять, в каких аспектах компоненты, которые будут разработаны, ока# жутся лучше готовых библиотек и компонентов. Повторное использование Если план предусматривает применение существующего кода, тестов, форматов данных и т. д., архитектура должна объяснять, как повторно использованные ре# сурсы будут адаптированы к другим архитектурным особенностям, если это бу# дет сделано. Стратегия изменений Так как при создании продукта и программисты, и пользо# ватели обучаются, приложение скорее всего в период разра# ботки будет изменяться. Причинами этого могут быть изме# нения типов данных, форматов файлов, функциональности, реализация новых функций и т. д. Изменения могут быть новыми возможностями, которые были запланированы заранее или не были реализованы в первой версии системы. Поэтому разработчику архитектуры ПО следует сделать ее достаточно гибкой, чтобы в систему можно было легко внести вероятные изменения. Архитектура должна четко описывать стратегию изменений. Архитектура должна показывать, что возможные улучшения рассматривались и что реализация наиболее вероятных улучшений окажется наиболее простой. Если вероятны из# менения форматов ввода или вывода данных, стиля взаимо# действия с пользователями или требований к обработке, архитектура должна показывать, что все эти изменения были предвосхищены и каждое из них будет ограничено неболь# шим числом классов. Архитектурный план внесения изме# нений может быть совсем простым: включить в файлы данных номера версий, за# резервировать поля на будущее, спроектировать файлы так, чтобы в них можно было добавить новые таблицы и т. д. Если применяется генератор кода, архитек# тура должна показывать, что он поддерживает возможность внесения предпола# гаемых изменений. Перекрестная ссылка Список типов коммерческих программ- ных компонентов см. в подраз- деле «Библиотеки кода» разде- ла 30.3. Перекрестная ссылка О систе- матичной обработке изменений см. раздел 28.2. Ошибки проектирования часто являются довольно тонкими и объясняются эволюцией, при которой по мере реализации новых функций и возможностей разработчики забывают о сде- ланных ранее предположениях. Фернандо Дж. Корбати (Ferrnando J. Corbatу) 50 ЧАСТЬ I Основы разработки ПО В архитектуре должны быть отражены стратегии, которые позволяют программистам не ограничивать имеющийся у них выбор раньше времени. Так, архитектура может опре# делять, что вместо жестко закодированных тестов if будет применяться метод, основанный на проверке таблиц. Дан# ные таблиц можно хранить во внешнем файле, а не вклю# чать в программу, что позволит вносить в нее изменения без перекомпиляции. Общее качество архитектуры Хорошая спецификация архитектуры должна описывать классы системы, инфор# мацию, скрываемую каждым классом, и обосновывать принятые и отвергнутые варианты проекта системы. Архитектура должна быть продуманным концептуальным целым, включающим несколько специфических дополнений. Главный тезис самой популярной книги по разработке ПО «Мифический человеко#месяц» гласит, что основной пробле# мой, характерной для крупных систем, является поддержание их концептуальной целостности (Brooks, 1995). Хорошая архитектура должна соответствовать про# блеме. Изучая архитектуру, вы должны испытывать удовольствие от того, насколько естественным и простым кажется решение. Вам должно казаться, что проблема и архитектура неразрывно связаны. Вам следует знать, как архитектура изменялась во время ее проектирования. Каж# дое изменение должно быть четко согласовано с общей концепцией. Архитекту# ра не должна быть похожа на проект бюджета Конгресса США, предусматриваю# щий расходы на мероприятия, повышающие популярность чиновников. Цели архитектуры должны быть четко сформулированы. Проект системы, глав# ным требованием к которой является модифицируемость, будет отличаться от проекта системы, которая должна показывать высочайшую производительность, даже если по функциональности обе системы будут одинаковы. В архитектуре должны быть обоснованы важнейшие принятые решения. С подо# зрением относитесь к обоснованиям из разряда «мы всегда так делали». Здесь уместно вспомнить одну поучительную историю. Бет хотела приготовить туше# ное мясо по прославленному рецепту, передававшемуся из поколения в поколе# ние в семье ее мужа Абдула. Абдул сказал, что его мать солила кусок мяса, перчи# ла, обрезала его края, укладывала в горшок, закрывала и ставила в духовку. На вопрос Бет «Зачем обрезать оба края?» Абдул ответил: «Не знаю, я всегда так делал. Спро# шу у мамы». Он позвонил ей и услышал: «Не знаю, просто я так всегда делала. Спрошу у твоей бабушки». А бабушка заявила: «Понятия не имею, почему вы так делаете. Я делала так потому, что мой горшок был маловат». Хорошая архитектура ПО не зависит ни от платформы, ни от языка. Пожалуй, вы не сможете проигнорировать среду конструирования, однако максимальная не# зависимость от среды позволит вам устоять перед соблазном создать слишком подробную архитектуру и избежать работы, которую лучше выполнять во время конструирования. Если программа ориентирована на конкретную платформу или должна быть разработана на конкретном языке, это правило неактуально. Перекрестная ссылка О мерах, позволяющих не ограничивать возможность выбора, см. под- раздел «Тщательно выбирайте время связывания» раздела 5.3. Перекрестная ссылка О соотно- шении атрибутов качества см. раздел 20.1. ГЛАВА 3 Семь раз отмерь, один раз отрежь: предварительные условия 51 При разработке архитектуры следует соблюдать баланс между недостаточным и чрезмерным определением системы. Ни на какую часть архитектуры не следует обращать больше внимания, чем она заслуживает; не следует разрабатывать одну часть в ущерб другой. Архитектура должна отражать все требования, не включая ненужных элементов. В архитектуре должны быть явно определены области риска, указаны его причи# ны и описаны действия по сведению риска к минимуму. Архитектура должна включать описания системы с разных точек зрения. Планы дома включают поэтажный план, план перекрытий, электрические схемы и т. д. Качество архитектуры ПО также повысится, если включить в нее описания раз# ных взглядов на систему, которые позволят найти ошибки и помогут программи# стам полностью понять проект системы (Kruchten, 1995). Наконец, элементы архитектуры не должны вызывать у вас чувство неловкости. В архитектуру не следует включать что#то только для того, чтобы угодить началь# нику. Архитектура не должна включать ничего, что было бы трудно понять. Именно вы будете претворять ее в жизнь — как же вы ее реализуете, если не будете в ней разбираться? Контрольный список: архитектура Следующий список вопросов позволяет сделать вывод о качестве архитектуры. Этот список не является исчерпы- вающим руководством по проектированию архитектуры — это прагматичный способ оценки того, что вы получаете на программистском конце пищевой цепи разработки ПО. Используйте его как основу для создания собственного контрольного списка. Как и в случае аналогичного списка вопро- сов о требованиях, при работе над неформальным проектом некоторые вопро- сы будут неактуальны, однако при работе над более крупным проектом боль- шинство из них пригодится. Специфические аспекты архитектуры Ясно ли описана общая организация программы? Включает ли специфика- ция грамотный обзор архитектуры и ее обоснование? Адекватно ли определены основные компоненты программы, их области ответственности и взаимодействие с другими компонентами? Все ли функции, указанные в спецификации требований, реализуются ра- зумным, не слишком большим и не слишком малым, числом компонентов? Приведено ли описание самых важных классов и их обоснование? Приведено ли описание организации данных и ее обоснование? Приведено ли описание организации и содержания БД? Определены ли все важные бизнес-правила? Описано ли их влияние на систему? Описана ли стратегия проектирования GUI? Сделан ли GUI модульным, чтобы его изменения не влияли на оставшуюся часть программы? Приведено ли описание стратегии ввода-вывода данных и ее обоснование? http://cc2e.com/0337 52 ЧАСТЬ I Основы разработки ПО Указаны ли оценки степени использования ограниченных ресурсов, таких как потоки, соединения с БД, дескрипторы, пропускная способность сети? Приведено ли описание стратегии управления такими ресурсами и ее обо- снование? Описаны ли требования к защищенности архитектуры? Определяет ли архитектура требования к объему и быстродействию всех классов, подсистем и функциональных областей? Описывает ли архитектура способ достижения масштабируемости системы? Рассмотрены ли вопросы взаимодействия системы с другими системами? Описана ли стратегия интернационализации/локализации? Определена ли согласованная стратегия обработки ошибок? Определен ли подход к отказоустойчивости системы (если это требуется)? Подтверждена ли возможность технической реализации всех частей системы? Определен ли подход к реализации избыточной функциональности? Приняты ли необходимые решения относительно «покупки или создания» компонентов системы? Описано ли в спецификации, как повторно используемый код будет адапти- рован к другим аспектам архитектуры? Сможет ли архитектура адаптироваться к вероятным изменениям? Общее качество архитектуры Все ли требования отражены в архитектуре? Является ли какая-нибудь часть системы чрезмерно или недостаточно про- работанной? Заданы ли явные ожидания по этому поводу? Является ли вся архитектура концептуально целостной? Независим ли высокоуровневый проект системы от платформы и языка, который будет использован для его реализации? Указаны ли мотивы принятия всех основных решений? Удовлетворяет ли вас — программиста, который будет реализовывать сис- тему, — разработанная архитектура? 3.6. Сколько времени следует посвятить выполнению предварительных условий? Время, уходящее на определение проблемы, выработку тре# бований и проектирование архитектуры ПО, зависит от особенностей проекта. Как правило, если проект развива# ется без проблем, работа над требованиями, архитектурой и предварительным планированием поглощает 10–20% уси# лий и 20–30% времени (McConnell, 1998; Kruchten, 2000). Эти показатели не включают затраты на детальное проектиро# вание — оно является частью конструирования. Если требования нестабильны и вы работаете над крупным формальным проектом, то для решения проблем с требованиями, которые будут обнаружены на ранних этапах конструирования, вам, вероятно, понадобятся услуги специалиста по ана# лизу требований. Предусмотрите консультации с ним и выделите ему время на ре# визию требований — и пригодная для работы версия требований в ваших руках. Перекрестная ссылка Объем времени, необходимый для ра- боты над предварительными условиями, зависит от типа проекта. Об адаптации предва- рительных условий к специфи- ческому проекту см. раздел 3.2. ГЛАВА 3 Семь раз отмерь, один раз отрежь: предварительные условия 53 Если требования нестабильны и вы работаете над небольшим неформальным проектом, вам, наверное, придется решать проблемы с требованиями самостоя# тельно. Выделите время на грамотное определение требований, чтобы их измен# чивость как можно слабее повлияла на конструирование. Каким бы проект ни был — формальным или неформаль# ным, — если требования нестабильны, рассматривайте ра# боту над ними как отдельный проект. Оцените время, нуж# ное для выполнения оставшейся части проекта, после завер# шения работы над требованиями. Это разумно: трудно ожи# дать, что вы сможете составить график работы до того, как будете знать, что создаете. Представьте, что вас хотят нанять для строительства дома. Заказчик говорит: «Сколько будет стоить ваша работа?» Вы обоснованно спрашиваете: «Что мне нужно построить?», на что заказчик от# вечает: «Я не могу сказать вам, но сколько это будет стоить?» Что вы сделаете? Попрощаетесь с заказчиком и отправитесь домой. Ясно, что клиенты не попросят вас предъявить им счет, пока не расскажут, какой дом надо построить. Им не нужно, чтобы вы пришли с досками, молотком и гвоз# дями и начали тратить их деньги до того, как архитектор завершит работу над чертежами. Однако люди, как правило, разбираются в создании ПО хуже, чем в лестницах и дверных проемах, поэтому ваши клиенты могут не сразу понять, почему вы хотите сделать выработку требований отдельным проектом. Возможно, вам придется объяснить им причины этого. Выделяя время на проектирование архитектуры ПО, поступайте так же, как и при выработке требований. Если над данным типом ПО вы еще не работали, выдели# те больше времени. Убедитесь, что время на создание качественной архитектуры будет выделено не в ущерб другим этапам. Если нужно, сделайте отдельным про# ектом и работу над архитектурой. Дополнительные ресурсы Ниже я привел список ресурсов, посвященных работе над требованиями. Выработка требований В следующих книгах вы найдете гораздо более подробную информацию о выработке требований. Wiegers, Karl. Software Requirements, 2d ed. Redmond, WA: Microsoft Press, 2003. В этом практическом руководстве описываются все детали выработки требований, в том числе сбор информации о требованиях, их анализ, составление специфи# кации требований, проверка требований и управление ими. Robertson, Suzanne and James Robertson. Mastering the Requirements Process. Reading, MA: Addison#Wesley, 1999. Хорошая альтернатива книге Карла Вигерса, ориенти# рованная на более подготовленных специалистов по выработке требований. Gilb, Tom. Competitive Engineering. Reading, MA: Addison#Wesley, 2004. В этой книге рассматривается язык требований Гил# Перекрестная ссылка О подхо- дах к изменениям требований см. подраздел «Что делать при изменении требований во вре- мя конструирования програм- мы?» раздела 3.4. http://cc2e.com/0344 http://cc2e.com/0351 http://cc2e.com/0358 54 ЧАСТЬ I Основы разработки ПО ба, известный как «Planguage». Кроме того, в ней описывается специфический подход Гилба к разработке требований, проектированию, оценке проектирования и эволюционному управлению проектом. Загрузить книгу можно с Web#сайта Тома Гилба по адресу www.gilb.com. IEEE Std 830%1998. IEEE Recommended Practice for Software Requirements Specifications. Los Alamitos, CA: IEEE Computer Society Press. Этот документ представляет собой руководство IEEE#ANSI по созданию спецификаций требований к ПО. В нем опи# сываются элементы, которые следует включать в документ спецификации, и рас# сматриваются некоторые альтернативные варианты. Abran, Alain, et al. Swebok: Guide to the Software Engineering Body of Knowledge. Los Alamitos, CA: IEEE Computer Society Press, 2001. В этом руководстве приведено подробное описание выработки требований к ПО. Загрузить его можно с Web#сайта www.swebok.org. Ниже указаны хорошие альтернативы названным книгам. Lauesen, Soren. Software Requirements: Styles and Techniques. Boston, MA: Addison#Wesley, 2002. Kovitz, Benjamin L. Practical Software Requirements: A Manual of Content and Style. Manning Publications Company, 1998. Cockburn, Alistair. Writing Effective Use Cases. Boston, MA: Addison#Wesley, 2000. Разработка архитектуры В последние несколько лет было опубликовано много книг, посвященных разработке архитектуры ПО. Одними из луч# ших я считаю следующие. Bass, Len, Paul Clements, and Rick Kazman. Software Architecture in Practice, 2d ed. Boston, MA: Addison#Wesley, 2003. Buschman, Frank, et al. Pattern%Oriented Software Architecture, Volume 1: A System of Patterns. New York, NY: John Wiley & Sons, 1996. Clements, Paul, ed. Documenting Software Architectures: Views and Beyond. Boston, MA: Addison#Wesley, 2003. Clements, Paul, Rick Kazman, and Mark Klein. Evaluating Software Architectures: Meth% ods and Case Studies. Boston, MA: Addison#Wesley, 2002. Fowler, Martin. «Patterns of Enterprise Application Architecture». Boston, MA: Addison# Wesley, 2002. Jacobson, Ivar, Grady Booch, and James Rumbaugh. The Unified Software Development Process. Reading, MA: Addison#Wesley, 1999. IEEE Std 1471%2000. Recommended Practice for Architectural Description of Software% Intensive Systems. Los Alamitos, CA: IEEE Computer Society Press. Этот документ явля# ется руководством IEEE#ANSI по созданию спецификаций архитектуры ПО. http://cc2e.com/0365 http://cc2e.com/0372 ГЛАВА 3 Семь раз отмерь, один раз отрежь: предварительные условия 55 Общие подходы к разработке ПО Издано много книг, посвященных разным подходам к выпол# нению программных проектов. В одних рассматриваются бо# лее последовательные подходы, в других — более итеративные. McConnell, Steve. Software Project Survival Guide. Redmond, WA: Microsoft Press, 1998. В этой книге рассмотрен один конкретный способ выполнения проекта, подчер# кивающий обдуманное заблаговременное планирование, выработку требований и работу над архитектурой, за которыми следует тщательное выполнение проек# та. Такой подход обеспечивает долговременную предсказуемость финансовых и временных затрат, позволяет создавать высококачественное ПО и характеризу# ется умеренной гибкостью. Kruchten, Philippe. The Rational Unified Process: An Introduction, 2d ed. Reading, MA: Addison#Wesley, 2000. В этой книге представлен «архитектурно#центрический и оп# ределяемый моделью использования» подход к выполнению проектов. Как и в «Software Project Survival Guide», здесь особое внимание уделяется предваритель# ным действиям, обеспечивающим высокую долговременную предсказуемость фи# нансовых и временных затрат, умеренную гибкость работы и способствуют со# зданию высококачественного ПО. В некоторых аспектах этот подход сложнее, чем описанные в «Software Project Survival Guide» и «Extreme Programming Explained: Embrace Change». Jacobson, Ivar, Grady Booch and James Rumbaugh. The Unified Software Development Process. Reading, MA: Addison#Wesley, 1999. Здесь представлено более глубокое об# суждение тем, рассматриваемых в «The Rational Unified Process: An Introduction», 2d ed. Beck, Kent. Extreme Programming Explained: Embrace Change. Reading, MA: Addison# Wesley, 2000. Бек описывает высокоитеративный подход, который фокусируется на итеративной разработке требований к приложению и его проектов в сочета# нии с конструированием. Подход «экстремального программирования» обладает невысокой долговременной предсказуемостью, но обеспечивает высокую гибкость. Gilb, Tom. Principles of Software Engineering Management. Wokingham, England: Addison# Wesley, 1988. Подход Гилба предусматривает исследование главных вопросов пла# нирования, выработки требований и проектирования архитектуры на ранних этапах проекта и последующую непрерывную адаптацию планов проекта по мере прогресса. Этот подход характеризуется долговременной предсказуемостью и высокой гибкостью, а создаваемые на его основе приложения отличаются высо# ким качеством. Он сложнее подходов, описанные в «Software Project Survival Guide» и «Extreme Programming Explained: Embrace Change». McConnell, Steve. Rapid Development. Redmond, WA: Microsoft Press, 1996. В этой книге описан инструментальный подход к планированию проекта. Используя представ# ленные в книге инструменты, опытный специалист по планированию проектов сможет создать план, прекрасно адаптированный к уникальным особенностям проекта. Boehm, Barry and Richard Turner. Balancing Agility and Discipline: A Guide for the Per% plexed. Boston, MA: Addison#Wesley, 2003. В этой книге исследуется контраст меж# ду гибкой разработкой и разработкой, основанной на планировании. Особенно http://cc2e.com/0379 56 ЧАСТЬ I Основы разработки ПО интересны четыре раздела главы 3: «A Typical Day using PSP/TSP», «A Typical Day using Extreme Programming», «A Crisis Day using PSP/TSP» и «A Crisis Day using Extreme Programming». Глава 5 посвящена использованию рискованных подходов с целью уравновешивания гибкости, что может служить руководством по выбору между гибким методом или методом, основанным на планировании. В главе 6 приводится хорошо сбалансированная перспектива. Приложение Е включает подробные опыт# ные данные о гибких методах разработки. Larman, Craig. Agile and Iterative Development: A Manager’s Guide. Boston, MA: Add# ison Wesley, 2004. Это основанное на тщательных исследованиях введение в гиб# кие эволюционные стили разработки включает обзор подходов Scrum, Extreme Programming, Unified Process и Evo. Контрольный список: предварительные условия Установили ли вы тип проекта, над которым работае- те, и адаптировали ли вы к нему свой подход? Достаточно ли хорошо определены и достаточно ли ста- бильны требования для начала конструирования? (См. контрольный список вопросов о требованиях). Достаточно ли хорошо определена архитектура для начала конструирова- ния? (См. контрольный список вопросов об архитектуре). Рассмотрели ли вы другие, уникальные для конкретного проекта факторы риска, чтобы они не снижали эффективность конструирования? Ключевые моменты Главной целью подготовки к конструированию является снижение риска. Убе# дитесь, что проводимая вами подготовка снижает риск, а не повышает его. Если вы хотите разрабатывать высококачественное ПО, внимание к качеству должно быть частью процесса разработки ПО с начала до конца. Внимание к качеству в начале процесса оказывает наибольшее влияние на итоговое каче# ство приложения. Одним из аспектов профессии программиста является объяснение руководи# телям и коллегам процесса разработки ПО, в том числе важности адекватной подготовки к программированию. Предварительные условия конструирования в большой степени зависят от типа проекта, над которым вы работаете: многие проекты призывают к использо# ванию высокоитеративного подхода, другие — более последовательного. При отсутствии грамотного определения проблемы вы можете на этапе кон# струирования потратить силы на решение неверной проблемы. Если не проведена адекватная выработка требований, вы можете упустить важ# ные детали проблемы. Изменения требований после конструирования обхо# дятся в 20–100 раз дороже, чем на предыдущих этапах, поэтому перед нача# лом программирования обязательно убедитесь в правильности требований. http://cc2e.com/0386 |