Adde parvum parvo magnus acervus erit.
[Складывай малое с малым, и получишь большую кучу.]
ОВИДИЙ
Если ответственность за спецификацию функций отделить от ответственности за быстрое создание недорогого продукта, то чем сдержать изобретательский энтузиазм архитектора?
Принципиальное решение - обеспечение всестороннего, тщательного и доброжелательно обмена информацией между архитектором и разработчиком. Однако имеются и более тонкие решения, которые заслуживают внимания.
Дисциплина взаимодействия для архитектора
Архитектор, строящий здание, действует в рамках сметы, используя методы оценки, которые в последующем подтверждаются или корректируются заявками подрядчиков. Часто случается, что все предложения выходят за рамки сметы. Тогда архитектор пересматривает свои оценки в сторону увеличения сметы, а проект - в сторону сокращения, и цикл повторяется. Иногда он предлагает подрядчикам способы удешевления реализации его проекта в сравнении с избранными ими способами.
Сходные процессы происходят с архитектором компьютерных или программных систем. Однако у него есть то преимущество, что предложения подрядчика можно получить на ранних стадиях проектирования, часто - в любой момент. Недостатком обычно является то, что работа идет с единственным подрядчиком, который может менять цену в зависимости от степени своей удовлетворенности проектом. На практике, процесс общения, начатый на ранних этапах и продолжающийся непрерывно, может дать архитектору верную оценку стоимости, а разработчику - уверенность в проекте, не снимая при этом четкого разграничения сфер ответственности.
У архитектора, когда он сталкивается с неприемлемо высокой стоимостью, есть два выхода: сократить проект или воздействовать на стоимость, предлагая более дешевые способы реализации. Второй способ неизбежно вызывает эмоции, ведь архитектор оспаривает то, как строитель справляется со своим делом.
Чтобы успешно справиться с этим, архитектору необходимо:
- помнить, что ответственность за изобретательность и творчество, проявляемые при реализации, несет строитель, поэтому архитектор предлагает, а не требует;
- всегда быть готовым предложить некоторый способ реализации своих замыслов и быть готовым согласиться с любым другим способом, позволяющим решить задачу не хуже;
- выдвигая такие предложения, действовать без шума и огласки;
- не рассчитывать на признательность за сделанные предложения.
Обычно разработчик парирует предложением изменений в архитектуре. Часто он прав - реализация какой-нибудь малосущественной детали может оказаться неожиданно дорогостоящей.
Самодисциплина - эффект второй системы
Первый проект архитектора стремится к скромности и ясности. Архитектор понимает, что не знает, чем занимается, поэтому он занимается этим со старанием и самоограничением.
При работе над первым проектом ему постоянно приходят в голову то одни, то другие "украшения". Они откладываются в сторону для использования "в следующий раз". В конце концов, первая система закончена, и архитектор, с твердой уверенностью в себе и продемонстрированным освоением этого класса
систем, готов к созданию нового проекта.
Эта вторая система таит наибольшие опасности для проектировщика. При работе над третьей и последующими системами закрепляется полученный ранее опыт в отношении общих характеристик таких систем, а различия между ними выявляют те части опыта, которые носят частный характер и не могут быть обобщены.
Общая тенденция заключается в перегруженности проекта второй системы идеями и украшательствами, благоразумно отложенными в сторону при работе над первым проектом. В результате получается, говоря словами Овидия, "большая куча". Рассмотрим, например, архитектуру IBM 709, воплощенную позднее в машине 7090. Это - модернизация, вторя система для очень успешной и хорошо скроенной системы 704. Набор команд был настолько богат и изобилен, что регулярно использовалась примерно лишь половина его.
Рассмотрим в качестве более сильного примера архитектуру, разработку и даже реализацию компьютера Stretch, которые дали выход сдерживающимся изобретательским стремлениям многих людей, для большинства которых это было вторая система. Вот что пишет в своем обзоре Стрейчи (Strachey):
У меня создалось впечатление, что некоторым образом Stretch являет собой окончание определенного направления разработок. Как и некоторые ранние компьютерные программы, эта система чрезвычайно изобретательна, чрезвычайно сложна и очень эффективна, но в то же время является сырой, расточительной и неизящной, оставляя ощущение, что эти вещи можно делать лучшим образом.1
Operating System/360 была второй системой для большинства своих проектировщиков. Группы проектировщиков пришли после работы над дисковой операционной системой 1410-7010, операционной системой Stretch, системой реального времени Project Mercury и IBSYS для 7090. Едва ли кто-то из них имел опыт работы над двумя предшествующими операционными системами. Поэтому OS/360 является ярким примером эффекта второй системы, аналогом Stretch в искусстве программирования, к которому в полной мере применимы и похвалы, и упреки приведенной критики Стрейчи.
Например, в OS/360 отводится 26 байт для резидентной процедуры преобразования даты, чтобы правильно обрабатывать 31 декабря в високосном году (когда это 366-й день). Это можно было оставить оператору.
Эффект второй системы имеет и другое проявление, кроме простого украшательства функциями. Это - склонность к усовершенствованию методов, само существование которых стало анахронизмом благодаря изменениям в базовых принципах системы. OS/360 содержит многочисленные примеры, подтверждающие это.
Рассмотрим редактор связей, предназначенный для загрузки независимо скомпилированных программ и разрешения их перекрестных ссылок. Помимо этой основной функции он также управляет программными оверлеями. Это одно из лучших когда-либо созданных средств работы с оверлеями. Оно позволяет создавать оверлейную структуру внешним образом при редактировании связей, не трогая исходного кода. Оно позволяет изменять структуру оверлеев без перекомпиляции при каждом прогоне. Оно предоставляет богатый выбор полезных опций и возможностей. В известном смысле, это завершающий итог многолетней разработки технологии статических оверлеев.
И в то же время это последний и совершеннейший динозавр, поскольку входит в систему, в которой многопрограммность является обычным режимом, а динамическое распределение памяти - базовым принципом. Это вступает в прямой конфликт с понятием использования статических оверлеев. Несколько лучше работала бы система, если бы усилия, потраченные на управление оверлеями, были перенаправлены на то, чтобы ускорить работу средств поддержки динамического распределения памяти и перекрестных ссылок!
Более того, редактор связей требует так много памяти, и сам содержит столько оверлеев, что даже при использовании только для редактирования без управления оверлеями уступает в скорости большинству системных компиляторов. Ирония состоит в том, что назначение редактора связей - избежать повторной компиляции. Как у конькобежца корпус оказывается впереди ног, так и усовершенствования родолжались, пока не вышли далеко за рамки системных принципов.
Другим примером этой тенденции является отладчик TESTRAN. Это совершенный пакетный отладчик, предоставляющий действительно элегантные средства получения мгновенных снимков и дампов памяти. В нем используется понятие управляющих разделов и искусная технология генерации, позволяющие осуществлять избирательную трассировку и получение мгновенных снимков без дополнительных расходов на интерпретацию или рекомпиляцию. Здесь пышным цветом расцвели впечатляющие концепции операционной системы Share Operating
System3 для модели 709.
Между тем устарела сама идея пакетной отладки без рекомпиляции. Главный вызов был брошен интерактивным вычислительным системам с интерпретаторами языков программирования и пошаговыми компиляторами. Но даже в системах с пакетной обработкой появление компиляторов с быстрой компиляцией и медленным выполнением сделало более предпочтительной технологию отладки на уровне исходного кода и получения мгновенных снимков. Насколько лучше оказалась бы система, если бы силы, потраченные на проект TESTRAN, были перенаправлены на ускоренное создание лучших средств для интерактивной работы и быстрой компиляции!
Еще один пример - планировщик, предоставляющий действительно отличные возможности для управления потоком фиксированных пакетов заданий. На практике этот планировщик является усовершенствованной, улучшенной и наделенной разными украшениями второй системой, которой предшествовала дисковая операционная система 1410-7010 - система пакетной обработки, не являющаяся многопрограммной, за исключением ввода-вывода, и предназначенной, главным образом, для деловых приложений. В этом качестве планировщик OS/360 хорош. Но на него почти никакого влияния не оказали потребности OS/360 в удаленном вводе заданий, многопрограммности и резидентном размещении интерактивных подсистем. И действительно, проект планировщика затрудняет решение этих задач.
Как архитектору избежать эффекта второй системы? Очевидно, пропустить свою вторую систему он не может. Но он может отдавать себе отчет в особых опасностях, которым она его подвергает, и проявить дополнительную самодисциплину, чтобы избежать функционального украшательства и сохранения функций, нужда в которых отпала ввиду изменений в принципах и целях.
Порядок, способный открыть архитектору глаза, заключается в том, чтобы присвоить численное значение каждой, пусть малой, функции: характеристика x должна обойтись не более чем в m байтов памяти и n микросекунд на один вызов. Эти величины должны служить руководством при принятии начальных решений, а также напоминанием и руководством при реализации.
Как менеджеру проекта избежать эффекта второй системы? Настаивать на том, чтобы его старший архитектор имел опыт разработки хотя бы двух систем. Кроме того, будучи осведомленным о возможных опасностях, он может предъявлять необходимые требования для того, чтобы в детальном проекте нашли полное отражение идеологических концепций и цели.
