Б. Страуструп - Язык программирования С++. Специальное издание, 3-изд. Бином. 2004 (1160791), страница 179
Текст из файла (страница 179)
Хуже того, такие чрезмерно изощренные системы часто очень трудно анализировать, так что становится нелегко различить, где можно избежать затрат, а где нельзя. Таким образом отбивается всякое желание анализа и оптимизации. Оптимизация должна рождаться 785 23,5. Менеджмент в результате анализа и измерения быстродействия, а не из игр с программой. «Интуиция» проектировщика или программиста, особенно когда речь идет об относительно больших системах, — ненадежное средство в том, что касается эффективности. Важно избегать конструкций, неэффективных по своей природе, и тех, которые для достижения приемлемого уровня быстродействия потребуют много времени и умственных усилий. Также важно минимизировать использование непереносимых конструкций и средств, поскольку при их применении проект будет обречен вечно работать со старыми (менее мощными и/или более дорогими) компьютерами.
23.5. Менеджмент Когда это имеет хоть какой-то смысл, большинство людей делают то, за что их поощряют. В частности, если в контексте проекта вы получаете определенные рычаги для управления другими лицами и их наказания, только исключительный программист и проектировщик будет рисковать своей карьерой, чтобы перед лицом неодобрения, рав нодушия или волокиты со стороны руководства делать то, что он считает правильным'.
Из этого следует, что в организации должна бьггь введена система поощрений, соответствующая установленным целям проектирования и программирования. Однако, слишком часто такого не происходит: серьезного изменения в стиле программирования можно достичь лишь через соответствующее изменение стиля проектирования, а н то, и другое, чтобы быть эффективным, как правило, требует изменения в стиле менеджмента. Умственная и организационная инерция слишком легко приводит к лоюлизации изменений, которая не соответствует глобальным переменам, требующимся для достижения успеха.
Довольно характерный пример — переход на новый язык, который бы поддерживал объектно-ориентированное программирование, вроде С++, без соответствующего изменения в стратегии проектирования для получения преимуьчес тв от объектно-ориентированного подхода (см, также 8 24.2). Другой пример — переход на «объектно-ориентированное проектирование», оставаясь со старым не объектно-ориентированным языком программирования. 23.5.1.
Повторное использование Увеличение повторного использования уже готовых проектов и программ часто называют в качестве главной причины для выбора нового языка программирования или стратегии проектирования. Однако большинство организаций поощряет отдельных работников и целые коллективы, предпочитающие изобретать велосипед. Например, производительность программиста часто измеряют по числу строк кода; будет ли он писать маленькие программы, основанные на стандартных библиотеках, жертвуя своим доходом и, возможно, положением? Менеджеру могут платить в зависимости от количества людей в его подразделении; станет ли он пользоваться программами, разработанными в другом месте, когда вместо этого можно нанять еще пару программистов в свое подразделение? Фирма может получить госзаказ, где доход определяется процентом от затрат; станет ли эта фирма минимизировать свой доход, используя самые эффективные средства разработки? Стимулировать повтор- ' В организации, которая обращается со своими программвстамн, как г полвымн идиотами, вскоре будут работать только те программвсты, которые жеяают и способны вести себя как полные идиот»к Глава 2З.
Разработка и проектирование ное использование трудно, но если руководство не найдет способа поощрять и вознаграждать за это, повторного использования не будет. Повторное использование — это социальная проблема. Я могу воспользоваться чьей-то программой, если: ]1] Она работает: чтобы годиться к повторному использованию, программа должна быть пригодной к использованию вообще. [2] Она понятна: очень важны структура программы, комментарии, документация и руководство по применению. 13] Она может сосуществовать с программами, написанными без учета необходимости взаимодействия с ней.
'1«] Она сопровождается (илн я хочу сам сопровождать ее; как правило, я не хочу). (5] Она экономична (могу ли я разделить затраты на разработку и сопровождение с другими пользователями?). '16] Я могу ее найти. К этому мы можем добавить, что компонента бывает не готова к повторному использованию, пока кто-то не «использует ее повторном Задача подгонки компоненты к новой среде, как правило, ведет к усовершенствованию операций, универсализации ее поведения и улущпению се способности сосуществовать с другими программами.
Пока все эти действия не будут проделаны хотя бы раз, даже компоненты, спроектированные н реализованные с величайшим вниманием, будут иметь неожиданные острые углы. Мой опыт говорит, что условия, необходимые для повторного использования, возникнут только тогда, когда кто-то займется этим вплотную. В маленьких коллективах это, как правило, означает, что кто-то (намеренно или случайно) становится «хранителемь общих библиотек н документации. В больших организациях ато означает, что группе или отделу поручается собирать, строить, документировать, популяризировать и обслуживать программы для использования несколькими группами.
Важность таких групп по «стандартным компонентам«нельзя переоценить. Заметьте, что в первом приближении система отражает организацию, произведшую ес. Если организация не имеет механизма поддержки и поощрения кооперации и совместного использования, кооперация и совместное использование станут редкостью. Группы по стандартным компонентам должны активно продвигать свои компоненты. Это подразумевает, что наличив традиционной хорошей документации необходимо, но не достаточно. Кроме нее группа стандартных компонент должна выпускать руководства по применению и другую информацию, которая позволит потенциальному пользователю найти компоненту и понять, зачем она может пригодиться.
Это означает, что группа по стандартным компонентам должна заняться деятельностью, традиционно ассоциирующейся с маркетингом н повьппением квалификации сотрудников. По возможности члены этой группы должны работать в тесном контакте с производителями приложений, поскольку только тогда они смогут понять потребности пользователей и осознать возможности совместного использования компонент в разных разработках. Из этого следует, что в таких организациях должны быть обеспечены консультации с группой по стандартным компонентам и передача информации в нее и из нее.
Успех групп по стандартным компонентам должен измеряться успехом их клиентов. Если их успех оценивается просто количеством средств и инструментов, в полезности которых удалось убедить организации, такие группы деградируют и стано- 757 23,5. Менеджмент вятся просто распространителями коммерческих программ и поборниками вечных переделок. Не все программы нуждаются в повторном использовании, и способность к повторному использованию не является универсальной характеристикой. Утверждение, что компонент «годится к повторному применению», не означает, что его повтор1)ое использование не потребует серьезной работы.
В большинстве случаев переход к другой среде разработки потребует значительных усилий. В этом отношении возможность повторного использования очень напоминает переносимость. Важно отметиз ь, что повторное использование — это результат проектирования, направленного на повторное использование, уточнения компонегп, основанного на опыте, и сознательных усилий, направленных иа поиск компонент, годящихся для повторного использования. Повторное использование не возникает по волшебству из безлумного применения особенностей нового языка или приемов кодирования.
Такис особенности С++, как классы, виртуальные функции и шаблоны, позволяют выразить проект так, что повторное использование становится легче (и следовательно более вероятно), но сами по себе эти средства не гарантируют возможности повторного использования. 23.5,2. Масштаб Отдельная личность или организация легко поддаются стремлению «делать вещи правильноо». В официальном переложении это часто звучит как «разработка и строгое соблюдение соответствующих процедур».
В обоих случаях здравый смысл может стать первой жертвой искреннего и пылкого стремления улучшить принятый ход вещей. К несчастью, когда теряется здравый смысл, нет прелелов непреднамеренно наносимому вреду. Рассмотрим стадии процесса разработки, перечисленные в ~ 23А, и этапы проектирования, перечисленные в Я 23.4.3. Относительно легко переработать эти соображения в методику проектирования, где каждын этап определен точно и имеет четко обозначенный вход и выход, а также полуформальиое обозначение для выражения этого входа и выхода.
![](https://s.studizba.com/z.php?f=/templates/si/i/noavatar.png&w=100&h=100&t=1"){kind=avatar}
