Бьерн Страуструп.
Язык программирования С++
290
больших усилий, и даже придется для приспособления более универсального блока изменить общее
описание проекта машины. Поскольку новый блок разрабатывался для более общего применения, чем
наше L-образное чудище, предположительно, для него потребуется некоторая подгонка, чтобы
полностью удовлетворить наши пересмотренные запросы. Подобная же альтернатива возникает и у
программиста или разработчика программного обеспечения: вместо того, чтобы создать программу,
привязанную к конкретному проекту, разработчик может спроектировать новую достаточно
универсальную программу, которая будет иметь хорошие шансы стать стандартной в определенной
области.
Наконец, когда мы прошлись по всем стандартным компонентам, составляется "окончательное" общее
описание проекта. Несколько специально разработанных средств указываются как возможные.
Вероятно, в следующем году придется для новой модели повторить наши шаги, и как раз эти
специальные средства придется переделать или выбросить. Как ни печально, но опыт традиционно
проектировавшихся программ показывает, что лишь несколько частей системы можно выделить в
отдельные компоненты и лишь несколько из них пригодны вне данного проекта.
Мы не пытаемся утверждать, что все разработчики машин действуют столь разумно, как в приведенном
примере, а разработчики программ совершают все указанные ошибки. Утверждается, что указанная
методика разработки машин применима и для программного обеспечения. Так, в этой и следующей
главах даны приемы использования ее для С++. Тем не менее можно сказать, что сама природа
программирования способствует совершению указанных ошибок ($$12.2.1 и $$12.2.5). В разделе 11.4.3
опровергается профессиональное предубеждение против использования описанной здесь модели
проектирования. Заметим, что модель развития программного обеспечения хорошо применима только
в расчете на большие сроки. Если ваш горизонт сужается до времени выдачи очередной версии, нет
смысла создавать и поддерживать функционирование стандартных компонентов. Это просто приведет к
излишним накладным расходам. Наша модель рассчитана на организации со временем жизни, за
которое проходит несколько проектов, и с размерами, которые позволяют нести дополнительные
расходы и на средства проектирования, программирования, и на сопровождение проектов, и на
повышение квалификации разработчиков, программистов и менеджеров. Фактически это эскиз
некоторой фабрики по производству программ. Как ни удивительно, она только масштабом отличается
от действий лучших программистов, которые для повышения своей производительности в течении лет
накапливали запас приемов и методов проектирования, создавали инструменты и библиотеки. Похоже,
что большинство организаций просто не умеет воспользоваться достижениями лучших сотрудников, как
из-за отсутствия предвидения, так и по неспособности применить эти достижения в достаточно
широком объеме.
Все-таки неразумно требовать, чтобы "стандартные компоненты" были стандартными универсально.
Существует лишь малое число международных стандартных библиотек, а в своем большинстве
компоненты окажутся стандартными только в пределах страны, отрасли, компании, производственной
цепочки, отдела или области приложения и т.д. Просто мир слишком велик, чтобы универсальный
стандарт всех компонентов и средств был реальной или желанной целью проекта.
Достарыңызбен бөлісу: