Б. Страуструп - Язык программирования С++. Специальное издание, 3-изд. Бином. 2004 (1160791), страница 171
Текст из файла (страница 171)
Цели и средства Целью профессионального программирования является поставка готового продукта, который удовлетворил бы пользователей. Главные средства для этого — создать программу с ясной внутренней структурой и вырастить группу проектировщиков и программистов, достаточно квалифицированных и имеющих стимул, чтобы быстро реагировать па новые методы и возможности.
Почему? Внутренняя струюура программы н процесс ее создания в идеале не должны волновать конечного пользователя. Я скажу больше.' если конечному пользователю 23.3. Цели и средства 763 приходится беспокоиться о том, как писалась программа, то с этой программой что-то неладно, Так почему же вюкно, какова структура программы, и какие люди ее создавали? Программа должна иметь ясную внутреннюю структуру, чтобы ее было легче: ° тестировать; ° переносить на другие системы; ° обслуживать; ° расширять; изменять; понимать. Главное в том, чтобы каждый успешно разработанный программный продукт имел свою жизнь, на протяжении которой с ним бы работали разные программисты и проектировщики, он бы переносился на новую аппаратуру, приспосабливался к непредвиденным задачам и так или иначе переделывался, За время жизни программного продукта должны рождаться его новые версии с приемлемым уровнем ошибок н с разумными затратами.
Не планируя этого, вы планируете неудачу. Отметим, что хотя конечные пользователи в идеале не должны знать внутреннюю структуру системы, в действительности, они могут ею заинтересоваться. Например, пользователь может захотеть узнать кое-что о проекте системы, чтобы оце. нить ее надежность или способность к переделкам и расширению. Если рассматриваемый программный продукт не представляет собой завершенной системы — например, вто наоор библиотек для построения других программ — то пользователи захотят узнать больше «подробностей», чтобы получше применить библиотеки или воспользоваться ими как источником идей.
Должен быть найден баланс между отсутствием общего проекта и слишком большим упором на структуру. Первое ведет к бесконечному срезанию углов («мы только сдадим эту программу, а проблему решим в следующей версии»). Второе ведет к слишком усложненному проекту, в котором сущность теряется в формализме, и к ситуациям, когда реализация задерживается из-за постоянных реорганизаций программы («но эта новая структура гораздо лучше старой; люди подождут»). Это также часто приводит к тому, что система начинает требовать столько ресурсов, что большинство потенциальных пользователей не смогут себе позволить ее приобрести. Такое балансирование — самый трудный аспект проектирования, и именно здесь проявляются талант и опыт.
Этот выбор труден для отдельного проектировщика или программиста, и еще труднее его сделать в больших проектах, где участвует много людей разной«квалификации и опыта. Программа должна производиться и обслуживаться организацией, способной делать это несмотря на смену персонала, руководства и изменение структуры управления. Обычный подхол к этой проблеме заключается в том, чтобы свести разработку системы к задачам относительно низкого уровня, подгоняемых под грубую общую схему.
То есть идея заключается в том, что создается класс быстро обучаемых (дешевых) взаимозаменяемых программистов низкого уровня («кодировщиков») и класс не таких дешевых, но столь же взаимозаменяемых (н стало быть столь же малоцснных) проектировщиков. Предполагается, что кодировщики не принимают проектных решений, в то время как проектировщики пе утруждают себя черной работой по вниканию в детали кодирования.
Такой подход часто приводит к неудаче. Там, где он работает, в результате получаются чрезмерно громоздкие системы с низкой производительностью. 764 Глава 23. Разработка и проектирование Проблемы этого подхода таковы: ° недостаточная связь между реальными разработчиками и проектировщиками, что ведет к упущенным возможностям, задержкам, неэффективности и повторяющимся проблемам, так как никто не учится на ошибках; ° узкие рамки для проявления инициативы со стороны реальных разработчиков, что ведет к недостаточному профессиональному росту, заглушенпю инициативы, разболтанности и высокой текучести кадров.
По сути дела, такой системе це хватает механизма обратной связи, чтобы люди учились на чужом опыте. Это растрата человеческого таланта. Создание среды разработки, в рамках которой человек может проявлять разнообразные таланты, развивать новые способности, вносить идеи и радоваться своей работе — это нс просто пель, достойная сама по себе, но вещь, приносящая практическую экономическую выгоду. С другой стороны, нельзя строить систему, обслулгивать ее и разрабатывать документацию без какой-либо бюрократической структуры, Просто найти лучших людсй н дать им наброситься на проблему самым подходящим с нх точки зрения образом часто является идеальным началом для проектов, требующих новшеств.
Однако по мере развития проекта становится необходимым уделять внимание календарному планированию, специализации и формальным связям между участниками проекта. Слишком жесткая система может остшювить рост и задушить ношпества. Здесь как раз и испытываются талант и опыт руководителя. Для отдельной личности подобная дилемма заклгочается в выборе, где попытаться проявить ум, а где просто «действовать по инструкции». Рекомендация — думать нс только о ближайшем выпуске текущей программы, но и о долгосрочных целях. Беспокоиться только о блихгайшсм выпуске программы значит планировать неудачу.
Мы должны разрабатывать организацию и стратегию разработки программы, нацеленные на производство и обслуживание многих выпусков многих проектов, мы должны планировать серию успехов. Цель «проектирования» — создать ясную и сравнительно простую внутреннюю структуру программы, иногда называемую архитектурой. Другими словами, мы хотим создать среду, в которую естественно впишутся отдельные части программы, и которая сама направляла бы написание фрагментов кода, Проект — это конечный продукт процесса проектирования (если в итеративном процессе существует конечный продукт).
На нем фокусируется связь между проектировщиком и программистом, а также между программистами. Здесь важно иметь чувство меры. Если я — отдельный программист и разрабатываю небольшую программку, которую собираюсь реализовать завтра, соответствующий уровень точности и подробности проекта может быть на уровне нескольких набросков на обратной стороне конверта. С лругой стороны, разработка системы с участием сотен проектировщиков и программистов может потребовать томов спецификаций, тщательно написанных в соответствии со стандартом и нормами. Определение соответствующего уровня подробности, точности и формальности проекта — сама по себе непростая техническая и управленческая задача.
В этой и следующих главах я предполагшо, что проект системы выражается набором об ьявлений классов (как правило, опуская закрытые части объявлений как ненужные подробности) и связей между ними. Это упрощение. В конкретный проект входит гораздо больше всего; например, согласование классов и функций, организация программы, 765 23.4. Процесс разработки позволяющая минимизировать перекомпиляцию, вопросы долговременного хранения и использования многих компьютеров. Однако для рассмотрения на данном уровне детализации необходимо упрощение, и главной целью проектирования с применением С++ являются классы. Некоторые из перечисле|шых аспектов упоминаются на протяжении этой главы, а некоторые, прямо влияющие на проектирование программ па С++, рассматриваются в главах 24 и 25. Для более детального обсуждения и рассмотрения примеров объектно-ориентированного проектирования обратитесь к ~Воосп, 1994).
Различие между анализом и проектированием я оставлю недо конца уточненным, поскольку обсуждение этой темы выходит за пределы книги и очень чувствительно к различиям в конкретных методах проектирования. Главное — выбрать метод анализа, соответствующий стилю проектирования, и стиль проектирования, соответствующий стилю программирования и применяемому языку. 23.4. Процесс разработки Разработка программного продукта — итеративный и последовательный процесс.
За время разработки многократно возвращаются к каждой стадии процесса, и каждый раз конечный результат на данной стадии улучшается. Вообще говоря, этот процесс не имеет начала и конца. Проектируя и реализуя систему, вы начинаете с основы, заложенной другими людьми,— с их проектов, библиотек и прикладных программ. Заканчивая, вы оставляете проект и программу другим для улучшения, пересмотра, расширения и переноса на другие системы.
Гстественно, специфический проект может иметь определенные начало н конец, и необходимо ~хотя часто довольно трудно) ясно и точно ограьпичить проект по времени. Однако, считая, что все заканчивается с «последним выпуском», вь| можете породить серьезные проблемы для ваших преемников (часто для вас самих в другой роли). Одним из следствий данного подхода является то, что последующие разделы можно читать в любом порядке, поскольку аспекты проектирования и реализации в реальном проекте могут почти произвольно перемежаться.
То есть <проекта почти всегда переделывается, основываясь на предыдущих проектах и опыте других реализаций. Кроме того, проект ограничивается календарными планами, квалификацией участников, совместимостью отдельных частей и т. д. Главная трудность для проектировщнка/ менеджера/программиста заключается в создании процесса, не удушающего новшеств и не разрушающего обратной связи, необходимых для успешной разработки. Процесс разработки имеет три этапа: ° анализ: определение границ решаемой проблемы; ° проектирование: создание общей структуры системы; ° реализация: написание и тестирование программы.
Пожалуйста, помните об итеративной природе процесса -- эти этапы намеренно не пронумерованы. Отметим, что некоторые важные аспекты в разработке программы не проявляютсяя как отдельные стадии, поскольку долягны пронизывать весь процесс, а им егпих ° экспериментирование; ° тестирование; ° анализ проекта и реализации; ° документирование; ° менеджмент. 766 Глава 23.
![](https://s.studizba.com/z.php?f=/templates/si/i/noavatar.png&w=100&h=100&t=1"){kind=avatar}
