Б. Страуструп - Язык программирования С++ (1119446), страница 76

Просмтор этого файла доступен только зарегистрированным пользователям. Но у нас супер быстрая регистрация: достаточно только электронной почты!

Текст из файла (страница 76)

Похоже, это в природе какиндивидуума, так и организации - браться за проекты на пределе своих возможностей. Если задача несодержит определенный вызов, нет смысла уделять особое внимание ее проектированию. Такие задачирешаются в рамках уже устоявшейся структуры, которую не следует разрушать. Только еслизамахиваются на что-то амбициозное, появляется потребность в новых, более мощных средствах иприемах. Кроме того, существует тенденция у тех, кто "знает как делать", перепоручать проектновичкам, которые не имеют таких знаний.Не существует "единственного правильного способа" для проектирования и создания всей системы.

Ябы считал веру в "единственный правильный способ" детской болезнью, если бы этой болезньюслишком часто не заболевали и опытные программисты. Напомним еще раз: только по той причине, чтоприем успешно использовался в течение года для одного проекта, не следует, что он без всякихизменений окажется столь же полезен для другого человека или другой задачи. Всегда важно не иметьпредубеждений.Убеждение в том, что нет единственно верного решения, пронизывает весь проект языка С++, и, восновном, по этой причине в первом издании книги не было раздела, посвященного проектированию: яне хотел, чтобы его рассматривали как "манифест" моих личных симпатий. По этой же причине здесь,как и в главах 12 и 13, нет четко определенного взгляда на процесс развития программногообеспечения, скорее здесь просто дается обсуждение определенного круга, часто возникающих,вопросов и предлагаются некоторые решения, оказавшиеся полезными в определенных условиях.За этим введением следует краткое обсуждение целей и средств развития программного обеспечения в$$11.2, а дальше глава распадается на две основных части:-$$11.3 содержит описание процесса развития программного обеспечения.-$$11.4 содержит некоторые практические рекомендации по организации этого процесса.Взаимосвязь между проектированием и языком программирования обсуждается в главе 12, а глава 13посвящена вопросам проектирования библиотек для С++.284Бьерн Страуструп.Язык программирования С++Очевидно, большая часть рассуждений относится к программным проектам большого объема.Читатели, которые не участвуют в таких разработках, могут сидеть спокойно и радоваться, что все этиужасы их миновали, или же они могут выбрать вопросы, касающиеся только их интересов.

Нет нижнейграницы размера программы, начиная с которой имеет смысл заняться проектированием прежде, чемначать писать программу. Однако все-таки есть нижняя граница, начиная с которой можно использоватькакие-либо методы проектирования. Вопросы, связанные с размером, обсуждаются в $$11.4.2.Труднее всего в программных проектах бороться с их сложностью. Есть только один общий способборьбы со сложностью: разделяй и властвуй.

Если задачу удалось разделить на две подзадачи,которые можно решать в отдельности, то можно считать ее решенной за счет разделения более, чемнаполовину. Этот простой принцип применим для удивительно большого числа ситуаций. В частности,использование модулей или классов при разработке программных систем позволяет разбить программуна две части: часть реализации и часть, открытую пользователю – которые связаны между собой (видеале) вполне определенным интерфейсом. Это основной, внутренне присущий программированию,принцип борьбы со сложностью. Подобно этому и процесс проектирования программы можно разбитьна отдельные виды деятельности с четко определенным (в идеале) взаимодействием между людьми,участвующими в них.

Это основной, внутренне присущий проектированию, принцип борьбы сосложностью и подход к управлению людьми,занятыми в проекте.В обоих случаях выделение частей и определение интерфейса между частями - это то место, гдетребуется максимум опыта и чутья. Такое выделение не является чисто механическим процессом,обычно оно требует проницательности, которая может появиться только в результате доскональногопонимания системы на различных уровнях абстракции (см. $$11.3.3, $$12.2.1 и $$13.3). Близорукийвзгляд на программу или на процесс разработки программного обеспечения часто приводит кдефектной системе.

Отметим, что как программы, так и программистов разделить просто. Труднеедостигнуть эффективного взаимодействия между участниками по обе стороны границы, не нарушая ееи не делая взаимодействие слишком жестким.Здесь предложен определенный подход к проектированию, а не полное формальное описание методапроектирования. Такое описание выходит за предметную область книги.

Подход, предложенный здесь,можно применять с различной степенью формализации, и он может служить базой для различныхформальных спецификаций. В тоже время нельзя считать эту главу рефератом, и здесь не делаетсяпопытка рассмотреть каждую тему, относящуюся к процессу разработки программ или изложить каждуюточку зрения. Это тоже выходит за предметную область книги.

Реферат по этой тематике можно найти в[2]. В этой книге используется достаточно общая и традиционная терминология. Самые "интересные"термины, как: проектирование, прототип, программист - имеют в литературе несколько определений,часто противоречащих друг другу, поэтому предостерегаем вас от того, чтобы, исходя из принятых ввашем окружении определений терминов, вы не вынесли из книги то, на что автор совершенно нерассчитывал.11.2 Цели и средстваЦель программирования - создать продукт, удовлетворяющий пользователя. Важнейшим средствомдля достижении этой цели является создание программы с ясной внутренней структурой и воспитаниеколлектива программистов и разработчиков, имеющих достаточный опыт и мотивацию, чтобы быстро иэффективно реагировать на все изменения.Почему это так? Ведь внутрення структура программы и процесс, с помощью которого она получена, видеале никак не касаются конечного пользователя.

Более того, если конечный пользователь почему-тоинтересуется тем, как написана программа, то что-то с этой программой не так. Почему, несмотря наэто, так важны структура программы и люди, ее создавшие? В конце концов конечный пользовательничего об этом не должен знать.Ясная внутренняя структура программы облегчает:-тестирование,-переносимость,-сопровождение,-расширение,285Бьерн Страуструп.-реорганизацию и-понимание.Язык программирования С++Главное здесь в том, что любая удачная большая программа имеет долгую жизнь, в течение которойнад ней работают поколения программистов и разработчиков, она переносится на новую машину,приспосабливается к непредусмотренным требованиям и несколько раз перестраивается.

Во все времяжизни необходимо в приемлемое время и с допустимым числом ошибок выдавать версии программы.Не планировать все это - все равно, что запланировать неудачу.Отметим, что, хотя в идеальном случае случае пользователи не должны знать внутреннюю структурусистемы, на практике они обычно хотят ее знать.

Например, пользователь может желать познакомитьсяв деталях с разработкой системы с целью научиться контролировать возможности и надежностьсистемы на случай переделок и расширений. Если рассматриваемый программный продукт есть неполная система, а набор библиотек для получения программных систем, то пользователь захочетузнать побольше "деталей", чтобы они служили источником идей и помогали лучше использоватьбиблиотеку.Нужно уметь очень точно определить объем проектирования программы. Недостаточный объемприводит к бесконечному срезанию острых углов ("побыстрее передадим систему, а ошибку устраним вследующей версии"). Избыточный объем приводит к усложненному описанию системы, в которомсущественное теряется в формальностях, в результате чего при реорганизации программы получениеработающей версии затягивается ("новая структура намного лучше старой, пользователь согласенждать ради нее").

К тому же возникают такие потребности в ресурсах, которые непозволительны длябольшинства потенциальных пользователей. Выбор объема проектирования - самый трудный момент вразработке, именно здесь проявляется талант и опыт. Выбор трудно сделать и для одногопрограммиста или разработчика, но он еще труднее для больших задач, где занято много людейразного уровня квалификации.Организация должна создавать программный продукт и сопровождать его, несмотря на изменения вштате, в направлении работы или в управляющей структуре. Распространенный способ решения этихпроблем заключался в попытке сведения процесса создания системы к нескольким относительнопростым задачам, укладывающимся в жесткую структуру.

Например, создать группу легко обучаемых(дешевых) и взаимозаменяемых программистов низкого уровня ("кодировщиков") и группу не такихдешевых, но взаимозаменяемых (а значит также не уникальных) разработчиков. Считается, чтокодировщики не принимают решений по проектированию, а разработчики не утруждают себя"грязными" подробностями кодирования. Обычно такой подход приводит к неудаче, а где онсрабатывает, получается слишком громоздкая система с плохими характеристиками.Недостатки такого подхода состоят в следующем:-слабое взаимодействие между программистами и разработчиками приводит к неэффективности,промедлению, упущенным возможностям и повторению ошибок из-за плохого учета и отсутствияобмена опытом;-сужение области творчества разработчиков приводит к слабому профессиональному росту,безынициативности, небрежности и большой текучести кадров.По сути, подобные системы - это бесполезная трата редких человеческих талантов. Созданиеструктуры, в рамках которой люди могут найти применение разным талантам, овладеть новым родомдеятельности и участвовать в творческой работе - это не только благородное дело, но и практичное,коммерчески выгодное предприятие.С другой стороны, нельзя создать систему, представить документацию по ней и бесконечно еесопровождать без некоторой жесткой организационной структуры.

Для чисто новаторского проектахорошо начать с того, что просто найти лучших специалистов и позволить им решать задачу всоответствии с их идеями. Но по мере развития проекта требуется все больше планирования,специализации и строго определенного взаимодействия между занятыми в нем людьми. Под строгоопределенным понимается не математическая или автоматически верифицируемая запись (хотя этобезусловно хорошо там, где возможно и применимо), а скорее набор указаний по записи, именованию,документации, тестированию и т.п. Но и здесь необходимо чувство меры.

Слишком жесткая структураможет мешать росту и затруднять совершенствование. Здесь подвергается проверке талант и опытменеджера. Для отдельного работника аналогичная проблема сводится к определению, где нужно286Бьерн Страуструп.Язык программирования С++проявить смекалку, а где действовать по рецептам.Можно рекомендовать планировать не на период до выдачи следующей версии системы, а на болеедолгий срок. Строить планы только до выпуска очередной версии - значит планировать неудачу.

Характеристики

Список файлов книги