Бьерн Страуструп. Язык программирования С++. Специальное издание (2011) (1004033), страница 174
Текст из файла (страница 174)
Обе проблемы легче описать, чем решить, и в любом случае имеется соблазн счесть бурную деятельность гарантией успешного продвижения к желаемой цели. Естественно, что по мере продвижения проекта разные его фазы становятся более или менее важными. В самом начале акцент делается на анализе и проектировании, а вопросы написания конкретного кода в этот момент не столь актуальны. Постепенно акцент перемешается на связку проектирование-программирование, а затем и на связку программирование-тестирование. Однако никогда нельзя 100%-но фокусироваться на отдельных стадиях, забывая про все остальные. Глава 23. Общий взгляд на разработку программ. Проектирование 820 Помните, что если вы не знаете, чего хотите достичь, ничего не поможет — ни внимание к деталям, ни правильные приемы менеджмента, ни передовые методики проектирования, ничего.
Большая часть проектов проваливается как раз по причине отсутствия четко определенной и реалистичной цели. Нужно ясно понимать свою цель, четко определять промежуточные фазы разработки и не пьпаться подменять техническими приемами отсутствие перечисленного. При наличии четкой цели используйте все доступные методы, даже если они требуют серьезных инвестиций; люди работают лучше в условиях хорошего финансирования и благоприятной социальной и технологической среды.
Однако не думайте, что следовать этому совету легко. 23.4.1. Цикл разработки Разработка программной системы является итеративным процессом. Основной цикл заключается в повторе следующих шагов: О. Исследование проблемы. 1. Создание общего проекта. 2. Нахождение стандартных компонентов. Приспособление компонентов к проекту. 3. Создание новых стандартных компонентов. Их приспособление к проекту.
4. Сборка проекта. Для аналогии рассмотрим автомобильный завод. Чтобы запустить производство, нужен полный общий проект нового типа автомобиля. Самый первый набросок будет отталкиваться от предварительного анализа и состоять в словесном описании, относящемся скорее к области применения автомобиля, а не к техническим деталям его устройства, позволяющим добиться заявленных целей. Принятие решения о требуемых свойствах автомобиля является самым трудным решением.
Правильно принятое решение часто является плодом озарения одной сверхпроницательной личности. Многие проекты испытывают дефицит четко заявленных целей, и по этой причине они часто терпят неудачу. Допустим, что мы хотим построить среднего размера седан с четырьмя дверями и довольно мощным двигателем. После этого совершенно необязательно набрасываться на выполнение проекта автомобиля (и его узлов) с нуля. Аналогично, программисту на этом этапе также нет смысла сразу же составлять программный проект и начинать писать код. Намного лучше сначала посмотреть, какие компоненты уже имеются на заводе или у надежных поставщиков.
Найденные таким образом компоненты не обязаны в точности подходить для нового автомобиля. Их всегда можно будет в дальнейшим приспособить для этой цели. Неплохо сразу же написать спецификации для будущих версий этих компонентов, чтобы они лучше подходили для нового автомобиля. Например, пусть имеется двигатель со всеми подходящими характеристиками, кроме слегка недостаточной мощности, но есть возможность слегка турбировать этот двигатель для достижения желаемой мощности без внесения изменений в базовую конструкцию.
Выполнить такое турбирование без внесения изменений в базовый проект двигателя можно лишь тогда, когда такой аспект модификаций был учтен при выполнении исходного проекта двигателя. Ясно, что эта форма доработки двигателя выполняется во взаимодействии с поставщиком двигателя. 23.4. Процесс разработки 821 Проектировщик программного продукта и программист находятся в схожем положении. Например, они могут использовать полиморфные классы и шаблоны для подгонки готовых компонентов. Но, конечно, не следует думать, что можно осуществить произвольную подгонку, если только разработчик компонента заранее не заложил в него зту возможность.
Выявив наличие и определив возможности готовых стандартных компонентов, разработчик не бросается на проектирование новых (недостающих) компонентов для автомобиля. Например, оказалось, что нигде нет подходящего кондиционера, а под капотом есть свободное пространство (.-образной формы. Прямолинейным решением будет разработка кондиционера Е-образной формы. Но вероятность приспособить в дальнейшем такую экзотику под другие машины (даже после сильной подгонки) крайне мала.
В результате не удастся снизить совокупную стоимость разработки за счет тиражирования решения на большую партию самых разных машин, а эффективная жизнь нашего кондиционера будет весьма короткой. В результате более мудрым решением будет разработка собственного кондиционера традиционных форм и габаритов с широкими возможностями приспособления к разным конкретным случаям и нуждам. Это, конечно, займет больше времени и сил, чем проработка частного (.-решения, и возможно повлечет за собой внесение изменений в первоначальный дизайн разрабатываемого нового автомобиля, чтобы он мог принять кондиционер более традиционной формы и габаритов. Возможно даже, что более традиционный кондиционер после этого снова нужно будет довести (в соответствии с заложенными в его проект вариантами модификации), чтобы сделать его великолепно подходящим новому автомобилю.
И снова отмечаем, что проектировщик системы и программист находятся в аналогичном положении, и им тоже не следует сразу же писать узкоспецифичный код вместо разработки универсального решения, которое имеет шанс стать общеупотребительным стандартом в будущем. Наконец, исчерпав потенциал готовых стандартных компонентов, мы собираем «окончательный» проект.
Мы используем в нем столь малое количество специфических компонентов, насколько это возможно, ибо в уме мы держим простую мысль, что уже в следуюгцем году нам придется все начинать сначала, разрабатывая очередную модель автомобиля, и специфические компоненты при этом придется либо сильно переделывать, либо выбросить совсем. Печально, но опыт разработки программных компонентов говорит о том, что немногие части программы удается хотя бы выделить в четко очерченные компоненты, и еше меньше из них находит свое применение за пределами оригинального проекта. Я не утверждаю, что все проектировщики автомобилей поступают столь рационально, как мы это описали, и не все проектировщики программ допускают перечисленные выше ошибки.
Я, просто, твердо полагаю, что описанную (автомобильную) модель можно и нужно с разумными поправками использовать в процессе разработки программных продуктов. Данная глава и последующая рассматривают технологии, позволяющие применять описанную модель в рамках языка С++. Но я все же подчеркиваю, что из-за нематериальной природы компьютерных программ трудно полностью избежать указанных ошибок (824.3.1, 824.3.4), и в 823.5.3 я показываю, что от использования приведенной здесь модели людей часто удерживают корпоративные стандарты. Отметим, что эта модель разработки хороша именно в долгосрочной перспективе.
Если ваш горизонт распространяется только до ближайшего выпуска, разработ- Глава 23. Общий взгляд на разработку программ. Проектирование 822 ка и создание стандартных компонентов теряет для вас всякий смысл. Это будет выглядеть для вас излишними проблемами (и затратами). Наша модель предлагается для организаций, трудовая жизнь которых распространяется на многие выпуски крупных программных продуктов, чтобы могли оправдать себя дополнительные инвестиции в инструменты (менеджмента, проектирования и программирования) и обучение персонала (менеджеров, проектировщиков и программистов).
Можно считать это наброском фабрики по производству программных продуктов. Забавно, но он отличается лишь масштабом от реальной практики талантливых и предусмотрительных индивидуальных программистов, которые с годами набирают отличный запас приемов, проектов, инструментов и библиотек, резко усиливающих их персональную производительность. Похоже, что многим организациям не удается воплотить в жизнь работающие методики индивидуальных программистов из-за близорукости или неумения управлять ими в более крупных масштабах. Отметим, что совершенно неразумно ожидать от стандартных компонентов абсолютной универсальности.
Могут появиться несколько международных стандартных библиотек, но большинство из них останется стандартными лишь в рамках конкретных стран, отраслей, организаций, отделов и прикладных областей. Мир просто слишком велик, чтобы ограничиваться немногими универсальными стандартами. Стремление к чрезмерной универсальности на начальных стадиях самых первых проектов почти наверняка повлечет за собой то, что эти проекты никогда не будут завершены.
Цикл разработки потому и цикл, что нужно черпать опыт из полученных в рамках очередной итерации работающих систем 523.4.3.6). 23.4.2. Цели проектирования Каковы задачи, стоящие перед проектированием? Безусловно достижение простоты, но простоты в каком смысле, ведь проект должен развиваться? Он будет расширяться, портироваться, настраиваться и вообще меняться столь большим числом способов, что их невозможно предвидеть. Следовательно, мы должны стремиться к тому, чтобы в проект системы и ее реализацию было легко вносить изменения. Нет ничего удивительно в том, что требования к системе и изменения в проект будут несколько раз вноситься даже при разработке самого первого выпуска продукта.
Из всего этого следует, что система должна проектироваться таким образом, чтобы оставаться сколь возможно простой под воздействием серии модификаций. Мы должны закладывать изменения в проект, то есть мы должны стремиться к: ° гибкости, ° расширяемости, ° переносимости. Лучше всего это достигается попыткой изоляции и инкапсулирования тех чаппей системы, которые более всего подвержены потенииальным изменениям, с тем чтобы в дальнейшем проектировщики и программисты вносили изменения в четко очерченные отдельные части системы. Это выполняется путем выявления ключевых концепций разработки и соотнесения их с определенным классом, в исключительное ведение которого передается вся работа с информацией, относящейся к концепции.
В таком случае изменения можно сосредоточить в единственном классе. 23.4. Процесс разработки 823 В идеале, необходимые изменения в концепции можно было бы выполнять с помощью введения производного класса (З23.4.3.5) или передачей нового параметра шаблону. Конечно, идеал легче правазгласитяь, чеж реально аеущестлвить. Рассмотрим пример. В программе моделирования погодных явлений возникла необходимость визуализировать тучу. Как нам сделать это? Мы не можем написать внешнюю процедуру для показа тучи, поскольку ее вид зависит от ее внутреннего состояния, а о нем должна знать только сама туча.
![](https://s.studizba.com/z.php?f=/templates/si/i/noavatar.png&w=100&h=100&t=1"){kind=avatar}
