Глава 5. Эффект второй системы

Adde parvum parvo magnus acervus erit. [Складывай малое с малым, и получишь большую кучу.]

ОВИДИЙ

Если ответственность за спецификацию функций отделить от ответственности за быстрое создание недорогого продукта, то чем сдержать изобретательский энтузиазм архитектора?

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

Дисциплина взаимодействия для архитектора

Архитектор, строящий здание, действует в рамках сметы, используя методы оценки, которые в последующем подтверждаются или корректируются заявками подрядчиков. Часто случается, что все предложения выходят за рамки сметы. Тогда архитектор пересматривает свои оценки в сторону увеличения сметы, а проект - в сторону сокращения, и цикл повторяется. Иногда он предлагает подрядчикам способы удешевления реализации его проекта в сравнении с избранными ими способами.

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

У архитектора, когда он сталкивается с неприемлемо высокой стоимостью, есть два выхода: сократить проект или воздействовать на стоимость, предлагая более дешевые способы реализации. Второй способ неизбежно вызывает эмоции, ведь архитектор оспаривает то, как строитель справляется со своим делом. Чтобы успешно справиться с этим, архитектору необходимо:

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

Обычно разработчик парирует предложением изменений в архитектуре. Часто он прав - реализация какой-нибудь малосущественной детали может оказаться неожиданно дорогостоящей.

Самодисциплина - эффект второй системы

Первый проект архитектора стремится к скромности и ясности. Архитектор понимает, что не знает, чем занимается, поэтому он занимается этим со старанием и самоограничением.

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

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

Общая тенденция заключается в перегруженности проекта второй системы идеями и украшательствами, благоразумно отложенными в сторону при работе над первым проектом. В результате получается, говоря словами Овидия, "большая куча". Рассмотрим, например, архитектуру IBM 709, воплощенную позднее в машине 7090. Это - модернизация, вторая система для очень успешной и хорошо скроенной системы 704. Набор команд был настолько богат и изобилен, что регулярно использовалась примерно лишь половина его.

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

У меня создалось впечатление, что некоторым образом Stretch являет собой окончание определенного направления разработок. Как и некоторые ранние компьютерные программы, эта система чрезвычайно изобретательна, чрезвычайно сложна и очень эффективна, но в то же время является сырой, расточительной и неизящной, оставляя ощущение, что эти вещи можно делать лучшим образом.¹

Operating System/360 была второй системой для большинства своих проектировщиков.² Группы проектировщиков пришли после работы над дисковой операционной системой 1410-7010, операционной системой Stretch, системой реального времени Project Mercury и IBSYS для 7090. Едва ли кто-то из них имел опыт работы над двумя предшествующими операционными системами. Поэтому OS/360 является ярким примером эффекта второй системы, аналогом Stretch в искусстве программирования, к которому в полной мере применимы и похвалы, и упреки приведенной критики Стрейчи.

Например, в OS/360 отводится 26 байт для резидентной процедуры преобразования даты, чтобы правильно обрабатывать 31 декабря в високосном году (когда это 366-й день). Это можно было оставить оператору.

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

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

И в то же время это последний и совершеннейший динозавр, поскольку входит в систему, в которой многопрограммность является обычным режимом, а динамическое распределение памяти - базовым принципом. Это вступает в прямой конфликт с понятием использования статических оверлеев. Несколько лучше работала бы система, если бы усилия, потраченные на управление оверлеями, были перенаправлены на то, чтобы ускорить работу средств поддержки динамического распределения памяти и перекрестных ссылок!

Более того, редактор связей требует так много памяти, и сам содержит столько оверлеев, что даже при использовании только для редактирования без управления оверлеями уступает в скорости большинству системных компиляторов. Ирония состоит в том, что назначение редактора связей - избежать повторной компиляции. Как у конькобежца корпус оказывается впереди ног, так и усовершенствования продолжались, пока не вышли далеко за рамки системных принципов.

Другим примером этой тенденции является отладчик TESTRAN. Это совершенный пакетный отладчик, предоставляющий действительно элегантные средства получения мгновенных снимков и дампов памяти. В нем используется понятие управляющих разделов и искусная технология генерации, позволяющие осуществлять избирательную трассировку и получение мгновенных снимков без дополнительных расходов на интерпретацию или рекомпиляцию. Здесь пышным цветом расцвели впечатляющие концепции операционной системы Share Operating System³ для модели 709.

Между тем устарела сама идея пакетной отладки без рекомпиляции. Главный вызов был брошен интерактивным вычислительным системам с интерпретаторами языков программирования и пошаговыми компиляторами. Но даже в системах с пакетной обработкой появление компиляторов с быстрой компиляцией и медленным выполнением сделало более предпочтительной технологию отладки на уровне исходного кода и получения мгновенных снимков. Насколько лучше оказалась бы система, если бы силы, потраченные на проект TESTRAN, были перенаправлены на ускоренное создание лучших средств для интерактивной работы и быстрой компиляции!

Еще один пример - планировщик, предоставляющий действительно отличные возможности для управления потоком фиксированных пакетов заданий. На практике этот планировщик является усовершенствованной, улучшенной и наделенной разными украшениями второй системой, которой предшествовала дисковая операционная система 1410-7010 - система пакетной обработки, не являющаяся многопрограммной, за исключением ввода-вывода, и предназначенной, главным образом, для деловых приложений. В этом качестве планировщик OS/360 хорош. Но на него почти никакого влияния не оказали потребности OS/360 в удаленном вводе заданий, многопрограммности и резидентном размещении интерактивных подсистем. И действительно, проект планировщика затрудняет решение этих задач.

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

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

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

1 Strachey C. Review of Planning a Computer System // Comp.J. 1962. Vol.5, N 2. July. P.152-153.

2 Это относится только к управляющим программам. Некоторые бригады, разрабатывающие компиляторы для проекта OS/360, создавали уже свой третий или четвертый продукт, и отличное качество их продуктов это подтверждает.

3 Shell D.L. The Share 709 system: a cooperative effort; Greenwald I.D., Kane M. The Share 709 system: programming and modification; Boehm E.M., Steel T.B.,Jr. The Share 709 system: machine implementation of symbolic programming. Все статьи // JACM. 1959. Vol.6, N 2. Apr. P.123-140.

микротоковая терапия

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