Руководство по стилю программирования и конструированию по
 Скачать 7.6 Mb.
|
|
ГЛАВА 3 Семь раз отмерь, один раз отрежь: предварительные условия 51 При разработке архитектуры следует соблюдать баланс между недостаточным и чрезмерным определением системы. Ни на какую часть архитектуры не следует обращать больше внимания, чем она заслуживает; не следует разрабатывать одну часть в ущерб другой. Архитектура должна отражать все требования, не включая ненужных элементов. В архитектуре должны быть явно определены области риска, указаны его причи- ны и описаны действия по сведению риска к минимуму. Архитектура должна включать описания системы с разных точек зрения. Планы дома включают поэтажный план, план перекрытий, электрические схемы и т. д. Качество архитектуры ПО также повысится, если включить в нее описания раз- ных взглядов на систему, которые позволят найти ошибки и помогут программи- стам полностью понять проект системы (Kruchten, 1995). Наконец, элементы архитектуры не должны вызывать у вас чувство неловкости. В архитектуру не следует включать что-то только для того, чтобы угодить началь- нику. Архитектура не должна включать ничего, что было бы трудно понять. Именно вы будете претворять ее в жизнь — как же вы ее реализуете, если не будете в ней разбираться? Контрольный список: архитектура Следующий список вопросов позволяет сделать вывод о качестве архитектуры. Этот список не является исчерпы- вающим руководством по проектированию архитектуры — это прагматичный способ оценки того, что вы получаете на программистском конце пищевой цепи разработки ПО. Используйте его как основу для создания собственного контрольного списка. Как и в случае аналогичного списка вопро- сов о требованиях, при работе над неформальным проектом некоторые вопро- сы будут неактуальны, однако при работе над более крупным проектом боль- шинство из них пригодится. Специфические аспекты архитектуры Ясно ли описана общая организация программы? Включает ли специфика- ция грамотный обзор архитектуры и ее обоснование? Адекватно ли определены основные компоненты программы, их области ответственности и взаимодействие с другими компонентами? Все ли функции, указанные в спецификации требований, реализуются ра- зумным, не слишком большим и не слишком малым, числом компонентов? Приведено ли описание самых важных классов и их обоснование? Приведено ли описание организации данных и ее обоснование? Приведено ли описание организации и содержания БД? Определены ли все важные бизнес-правила? Описано ли их влияние на систему? Описана ли стратегия проектирования GUI? Сделан ли GUI модульным, чтобы его изменения не влияли на оставшуюся часть программы? Приведено ли описание стратегии ввода-вывода данных и ее обоснование? http://cc2e.com/0337 5 2 ЧАСТЬ 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 5 4 ЧАСТЬ 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 5 6 ЧАСТЬ 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 ГЛАВА 3 Семь раз отмерь, один раз отрежь: предварительные условия 57 쐽 Если не проведено адекватное проектирование архитектуры, во время конст- руирования вы можете решать верную проблему неверным способом. По мере написания кода для неверной архитектуры цена изменений архитектуры воз- растает, так что перед началом программирования вы должны проверить и правильность архитектуры. 쐽 Выбор подхода к конструированию должен определяться принятым подходом к предварительным условиям конструирования. 5 8 ЧАСТЬ I Основы разработки ПО http://cc2e.com/0489 Г Л А В А 4 Основные решения, которые приходится принимать при конструировании Содержание 쐽 4.1. Выбор языка программирования 쐽 4.2. Конвенции программирования 쐽 4.3. Волны развития технологий 쐽 4.4. Выбор основных методик конструирования Связанные темы 쐽 Предварительные условия: глава 3 쐽 Определение типа ПО, над которым вы работаете: раздел 3.2 쐽 Влияние размера программы на ее конструирование: глава 27 쐽 Управление конструированием: глава 28 쐽 Проектирование ПО: главы 5–9 Как только вы убедились, что адекватный фундамент для конструирования про- граммы создан, фокусом подготовки становятся решения, более специфичные для конструирования. В главе 3 мы обсудили программные эквиваленты чертежей и разрешений на конструирование. Как правило, у программистов нет особого кон- троля над этими подготовительными действиями, поэтому главной темой главы 3 была оценка того, с чем приходится работать в начале конструирования. Эта глава посвящена тем аспектам подготовки, за которые прямо или косвенно отве- чают отдельные программисты и технические руководители проекта. Мы рассмот- рим выбор специфических инструментов и непосредственную подготовку к ра- боте над приложением. Если вы думаете, что уже достаточно знаете о подготовке к конструированию, можете сразу перейти к главе 5. |