Б. Страуструп - Язык программирования С++. Специальное издание, 3-изд. Бином. 2004 (1160791), страница 172
Текст из файла (страница 172)
Разработка и проектирование «Сопровождение» программы просто подразумевает дополнительные проходы по циклу разработки Я 2ЗА.6). Очень важно, чтобы анализ, проектирование и реализация не слишком разделялись, и чтобы участники разработки имели некую оощую культуру, позволяющую эффективно общаться. Слишком часто в больших проектах все это отсутствует. В идеале люди на протяжении процесса переходят от одного этапа к другому; лучший способ переноса нетривиальной информации — это хранить ее в голове одного человека. К сожалению, организации часто устанавливают барьеры против такого последовательного перехода, например, предоставляя проектировщикам более высокий статус и/или более высокий оклад, чем «простым программистам».
Если среди сотрудников не практикуется хождение туда-сюда для того, чтобы учить и учиться, их нужно по крайней мере поощрять регулярно беседовать с участниками «других» этапов разработки. Для небольших и средних проектов часто не делается различий между анализом и проектированием; эти две фазы сливаются в одну.
В маленьких проектах часто не делают различия между проектированием и программированием. Этим решаются проблемы общения. Важно придать данному проекту подходящий уровень формализации и поддерживать соответствующий уровень разделения между его фазами (З 23.5.2). Здесь не существует единственно верного рецепта.
Описанная модель разработки программного продукта в корне отличается от традиционной «модели водопада». В модели водопада процесс разработки в организованной линейной манере поэтапно проходит все фазы от анализа до тестирования. Модель водопада имеет фундаментальный изъяв, заключающийся в том, что информация течет лишь в одном направлении. Когда проблемы находятся «внизу по течению», часто возникает сильное методологическое и организационное давление, призванное обеспечить их решение непосредственно «по месту выявления»; то есть не затрагивая предыдущие этапы процесса.
Этот дефицит обратной связи ведет к ущербности проекта, а исправления «по месту выявления» приводят к «корявой» реализации. В случаях, когда информация течет назад, к источнику, и приводит к изменениям в проекте, процесс замедляется, и поэтому люди противятся изменениям, неохотно и медленно реагируя на информацию «снизу». В качестве довода в пользу «неизменности» и решения проблем «на месте» часто говорят, что одно подразделение не должно переделывать свою работу из-за прихоти другого. В частности, к тому времени, когда находится серьезная ошибка, часто порочным решением уже порождено столько бумаг, что по сравнению с усилиями, связанными с изменением документации, изменения в программе кажутся ничтожными.
Таким образом, в разработке программного продукта проблема, связанная с «бугяажной работой», играет нс последнюю роль. Естественно, как ни организуй разработку болыпой системы, подобные проблемы могут возникать и возникают. В конце концов, какое-то бумаги необходимы. Однако стремление к линейной модели разработки (людели водопада) сильно увеличивает вероятность того, что эти проблемы выйдут из-под контроля. Недостаток модели водопада заключается в недостаточной обратной связи и неспособности реагировать на изменения.
Опасность же описанного здесь итеративного подхода — в соблазне принять серию несвязных изменений за реальную мысль и прогресс. Обе проблемы легче выявить, чем решить, и в любом деле легко и соблазни- 23.4. Процесс разработки тельно счесть бурную деятельность гарантом движения к цели. Естественно, с развитием проекта те илн иные этапы стшювятся более нли менее важными. Сначала упор делается на анализ и проектирование, а программирование привлекает меньше внимания. С течением времени акцент перемещается на проектирование и программирование, а затем на программирование и тестирование.
Однако, никогда нельзя фокусироваться только на одной стадии процесса чанализ/проектирование/программирование», полностью забывая про осталы1ые. Помните, что ни внимание к деталям, ни применение соответствующих приемов менеджмента, ни передовые методы вам не помогут, если у вас нет ясного представления, чего вы хотите достичь. Волыцзя часть проектов кончается неудачей именно из-за отсутствия четко определенной и реалисти шой цели, чем из-за каких-либо других причин. Что бы вы ни делали и как бы ни плутали, ясно понимайте свою цель, определите осязаемые вехи и верстовые столбы, и не ищите технических решений для социальных проблем.
С другой стороны, используйте всякие подходящие доступные методы — даже если они требуют инвестиций; с подходящими средствами и в хорошем окружении люди работают лучше. Пе думайте, что следовать этому совету легко, 23.4.1. Цикл разработки Разработка системы является итеративным процессом. Главный цикл состоит из многократных повторений следукпцих этапов: 10) исследование проблемы; Щ создание общего проекта; 12) выявление стандартных компонент; ° приспособление компонент для данного проекта; ~3) создание новых стандартных компонент; ° приспособление компонент для дашюго проекта; 141 сборка проекта.
В качестве аналогии рассмотрим автомобильный завод. Чтобы запустить производство, нужен общий проект нового типа автомобиля. Первый набросок будет основан на некотором анализе и определении данного автомобиля в общих словах, относящихся больше к его назначению, а не к тому, как достичь соответствующих свойств. Решение о том, какие свойства желательны (или, в идеале, выработка относительно простой схемы для определения того, какие свойства желательны), часто является самым трудным. Правильное принятие решения — это как правило, дело одной чпроницательной> личности, и часто это называют видением (шзюп).
Проекты, когда они не имеют такой ясной цели, практически всегда обречены на неудачу. Скажем, мы хотим построить средних размеров легковую машину с четырьмя дверями и довольно мощным двигателем. Первая стадия в проектировании, несомненно, состоит не в том, чтобы начинать сходу проектировать автомобиль (и все входящие в него агрегаты). Проектировщику программного продукта или программисту в подобной ситуации было бы тоже неразумно браться сразу за проектирование и программирование. Первая стадия заключается в выяснении того, какие компоненты уже имеются на заводе или у надежных поставщиков. Найденные таким образом компоненты не обязаны в точности подходить для нового автомобиля. Есть способы приспособить ком- 768 Глава 23, разработка и проектирование поненты.
Также не стоит упускать возможность повлиять на характеристики «следующего выпуска» таких компонент, чтобы сделать их более подходящими для данного проекта. Например, может быть, имеется двигатель с нужными свойствами, но с чуть-чуть недостаточной мощностью. Или мы, или поставщик, могли бы незначительно подправить двигатель, чтобы восполнить этот недостаток без изменения основного проекта. Отметим, что такая подгонка «без изменения основного проекта» вряд ли возможна, если первоначальный проект не предусматривал такую возможность.
Такая подгонка, как правило, требует сотрудничества между вами и поставщиком двигателей. Проектировщик и программист находятся в схожих отношениях. В частности, полиморфные классы и шаблоны могут эффективно использоваться для подгонки, Однако, не ожидайте, что сможете произвольно менять все, что захотите, если разработчик класса не предусмотрел подобных возможностей.
Определив все стандартные компоненты, проектировщик автомобиля не бросается проектировать оптимальные новые компоненты для новой машины. Это было бы слишком дорого. Допустим, нигде нет подходящего кондиционера, а под капотом есть подходящее Г-образное пространство. Одним из решений было бь1 спроектировать такой Г-образный кондиционер. Однако слишком низка вероятность, что такой странный кондиционер пригодится для установки на другие автомобили — даже после подгонки. Это означает, что наш автомобильный проектировщик не сможет разделить стоимость производства такого кондиционера с другими типами автомобилей, и кондиционер будет слишком уникален, чтобы быть рентабельным. Таким образом, стоило бы спроектировать кондиционер более широкого применения — более простой формы и более пригодный для подгонки, чем Г-образный.
Это, вероятно, потребует больше работы, чем разработка конкретного, хотя и странного Г-образного кондиционера, и повлечет внесение изменений в общий проект автомобиля, чтобы приспособить его к разрабатываемому более стандартному кондиционеру. Поскольку новый кондиционер разработан для более широкого применения, чем наше Г-образное чудо, вероятно, его придется немного подогнать, чтобы он в точности подошел к нашему исправленному проекту.
И снова очевидна аналогия с проектировщиком программного продукта и программистом. Вместо написания специальной подпрограммы для данного проекта они могут разработать новый универсальный компонент, который будет хорошим кандидатом в стандартные средства общего назначения. И, наконец, исчерпав потенциал стандартных компонент, мы собираем «оконча. тельный» проект.
Мы должны использовать наименьшее возможное число специально разработанных деталей, поскольку на следующий год нам снова придется проектировать новую модель, и специально разработанные детали нам, весьма вероятно, придется переделывать или выбросить. Печально, но опыт традиционного проектирования программ говорит, что це многие части системы можно хотя бы выделить как отдельные компоненты, и совсем незначительная их часть находит применение вне изначального проекта.
![](https://s.studizba.com/z.php?f=/templates/si/i/noavatar.png&w=100&h=100&t=1"){kind=avatar}
