Бьерн Страуструп. Язык программирования С++. Специальное издание (2011) (1004033), страница 172
Текст из файла (страница 172)
Или они могут сосредоточиться на подмножестве вопросов, касающихся их индивидуальных проблем. Не существует столь малых программ, для которых были бы вредны общая проработка и создание проекта работы до ее выполнения. Однако существуют столь малые программные проекты, для которых подойдуг любые частные приемы проектирования, программирования и документирования. См. 523.5.2 по поводу вопросов, связанных с масштабом программ.
Самой большой проблемой в разработке программ является сложность. Для борьбы со сложностью есть только одно универсальное средство — разделяй и властвуй. Задачу, которую удается разделить на две относительно независимые подзадачи, можно считать более чем наполовину решенной. Этот простой принцип можно реализовывать разными способами.
В частности, применение модуля или класса в проекте системы разделяет программу две части — на реализацию и ее пользователей, взаимодействующих (в идеале) исключительно через хорошо спроектированный интерфейс. Это фундаментальный подход к борьбе со сложностью программ. Аналогично, процесс проектирования программного продукта может быть разбит на отдельные действия с четко определенными взаимодействиями между участвующими в проекте людьми.
Это фундаментальный подход к борьбе со сложностью процесса разработки и связанными с ним человеческими отношениями. Для обоих случаев вычленение отдельных частей и определение интерфейса их взаимодействия требует максимального опыта и тонкого вкуса. Такое вычленение — это вовсе не простой механический процесс, а нечто, требующее проникновения в самую суть проблемы, для чего требуется глубокое понимание системы на подходящем уровне ее абстракции (см.
823.4.2, 824.3.! и 825.3). Близорукий взгляд на процесс разработки программ часто приводит к их серьезным изъянам. Отметим также, что в реальной жизни любое разделение, будь-то частей программы или людей, вынолняетсе значительно легче, чем их эффективное взаимодействие по разные стороны барьера без разрушения этого барьера и с предоставлением средств коммуникации, достаточных для эффективной кооперации. Настоящая глава рассматривает именно подход к проектированию, а не метод проектирования целиком, что очевидным образом выходит за рамки данной книги.
Представленный нами подход может использоваться с разной степенью формализации, и он может служить основой для разных степеней формализации. Аналогич- 23.3. Цели и средства 815 но, данная глава не служит литературным обзором по проектированию и разработке программных продуктов, так что в ней не затрагиваются все относящиеся к изучаемой проблеме вопросы и не перечисляются все известные точки зрения. Такой обзор представлен в книге (ВоосЬ, 19941. Используемые в данной главе термины являются общепринятыми и широко употребляемыми.
Особо повторяемые терми-' ны, такие как проект (с(ез(цп), прототип (ргоГо(уре) и программист (рлоягаттег) имеют в литературе множество разных и зачастую противоречащих друг другу определений. Пожалуйста, постарайтесь не попасться на удочку узко понимаемых определений и не прочтите в данной главе чего-нибудь такого, чего я вовсе не намеревался сказать. 23.3. Цели и средства Целью профессионального программирования является изготовление и поставка законченного программного продукта, который удовлетворит заказчиков и/или иных его пользователей.
Главным средством достижения такой цели является четкое понимание внутренней структуры программы, для чего требуется вырастить группу проектировщиков и программистов, достаточно квалифицированную и хорошо мотивированную для быстрого реагирования на новые обстоятельства н возможности. Почему так? Ведь вроде бы внутренняя структура программы и детали процесса ее изготовления не должны волновать заказчика (пользователя). Более того, если конечный пользователь вынужден беспокоиться о таких деталях, то с программой явно что-то не в порядке. Тогда почему же внутренняя структура программа и качество изготавливающего программу коллектива разработчиков так важны? Ответ на этот вопрос таков — ясная внутренняя структура программы нужна для того, чтобы ее было легче (быстрее и надежнее): ° тестировать, ° портировать (переносить на другие системы), ° сопровождать и поддерживать, ° расширять, ° модифицировать, ° понимать.
Главная мысль состоит в том, что каждая успешная программа имеет определенное время жизни, в течение которого с ней работают разные группы проектировшиков и программистов, она переносится на новые виды аппаратуры, подстраивается под непредвиденные обстоятельства и, вообще, так или иначе периодически изменяется. За время жизни программного продукта своевременно появляются его новые версии с приемлемым уровнем ошибок. Не планировать указанных аспектов поведения программного продукта — заранее обрекать его на неудачу. Далее, хотя конечные пользователи и не обязаны знать внутреннюю структуру программной системы, они вполне могут сами захотеть это сделать.
Например, пользователь может захотеть узнать поподробнее внутренний дизайн системы для того, чтобы оценить ее надежность и/или способность к модификациям и расширению. Если программный продукт не представляет собой завершенной системы, например, 816 Глава 23.
Общий взгляд на разработку программ. Проектирование это может быть набор вспомогательных библиотек, то в этом случае пользователи захотят узнать побольше деталей с целью более эффективного их использования. В реальных разработках приходится искать разумный баланс между отсутствием общего проекта (четкой внутренней структуры) и слишком большим упором на архитектурные аспекты.
Первая крайность приводит к бесконечному «мы только сдадим эту программу, а все остальные проблемы решим в следующей версии», Вторая же крайность приводит к переусложненным проектам, в которых суть скрывается за формализмом и часто задерживается выпуск программ («новая структура программы намного лучше старой; люди с удовольствием подождут»).
Кроме того, зто часто приводит к излишним требованиям максимальных компьютерных ресурсов, которые пользователи не всегда могут себе позволить. Такое балансирование — самый сложный аспект проектированин, в котором ярче всего раскрываются настоящие таланты и настоятельно требуется изрядный опыт. Этот выбор труден даже для индивидуального проектировщика и программиста, и его тем более сложно сделать в больших программных проектах, в которых задействовано множество людей с разным опытом и квалификацией.
Программы должны производиться и обслуживаться организациями, способными делать это несмотря на смену персонала и менеджеров. Часто для этого стараются осуществлять разработку так, что вся работа разбивается на узкоспециализированные слои, жестко встраиваемые в общую структуру разработки. Для этого формируется множество быстро обучаемых (дешевых) и взаимозаменяемых программистов низкого уровня (кодировщиков — «содегз») и множество не столь дешевых, но столь же взаимозаменяемых проектировщиков. От кодировшиков не требуется принимать архитектурных решений, в то время как проектировщики не обязаны разбираться в мелких и низкоуровневых деталях кода. Такой подход, однако, нередко ведет к неудачам.
Там, где он все-таки работает, получаются переусложненные системы с плохой производительностью. Проблемы этого подхода заключаются в следующем: ° недостаточное взаимодействие и взаимопонимание между проектировщиками и кодировщиками приводит к упущенным возможностям, задержкам, неэффективности и повторению проблем из-за того, что никто не накапливает предыдущий опыт и не учится на ошибках; ° узкие рамки работы специалистов сковывают иниииативу, мешают профессиональному росту, способствуют разболтанности и высокой текучке кадров. По сути дела, такой системе не хватает каналов обратной связи, чтобы люди могли плодотворно общаться и учиться на опыте других. Это растрата человеческого таланта. Создание среды и структуры осуществления процесса разработки программ, в которых люди проявляют таланты, развивают способности, предлагают свои идеи и радуются результатам — это не только благородная цель, достойная сама по себе, но и практическая вещь, приносящая зкономическую выгоду.
С другой стороны, строить программную систему, документировать и поддерживать ее в безусловном порядке невозможно без некоторой бюрократической организационной структуры. Просто найти подходящих людей н дать нм наброситься на задачу наилучшим с их точки зрения образом часто бывает идеальным началом для инновационных проектов. Дальше, по мере развития проекта, растет необходимость в планировании, специализации и установлении более формальных связей 23 3 Цели и средства в12 между участниками проекта.
Под словом «формальных» я не имел в виду нечто строго математическое (хотя в отдельных случаях и это не исключается), а скорее набор рекомендаций по именованию, документированию, тестированию и т,д. Тут, естественно, требуется вкус и чувство меры.
Слишком жесткая организация может придушить рост и творчество. Здесь как раз и испытываются талант и опыт руководителя. Для индивидуальных программистов дилемма заключается в том, чтобы выбрать между изобретательством и копированием известных «книжных образцов». Моя рекомендация — думать не только о ближайшем выпуске, но и о более долгосрочных проблемах. Беспокоиться исключительно о ближайшем выпуске программы — значит планировать неудачу. Нужно разрабатывать стратегию организации процесса разработки программных продуктов, нацеленную на множество выпусков множества продуктов, то есть нужно планировать целую серию успехов.
![](https://s.studizba.com/z.php?f=/templates/si/i/noavatar.png&w=100&h=100&t=1"){kind=avatar}
