Читать онлайн «Мифический человеко-месяц или как создаются программные системы». Страница 10

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

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

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

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

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

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

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

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

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

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

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

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

Как менеджеру, имея опытных дисциплинированных архитекторов и достаточное число исполнителей, добиться того, чтобы все услышали, поняли и выполнили решения архитектора? Как группе из 10 архитекторов поддерживать концептуальную целостность системы, над которой трудится 1000 человек? Для достижения этого при осуществлении программы проектирования аппаратной части System/360 была разработана целая технология, которая в равной степени применима для проектов создания программного обеспечения.

Письменные спецификации — руководство

Руководство, или письменная документация, является необходимым, хотя и не достаточным, инструментом. Руководство является внешней спецификацией продукта. В нем расписаны все подробности того, что видит пользователь, и потому оно является главным продуктом, который создает архитектор.

Его подготовка идет кругами, собирая замечания пользователей и разработчиков о недостатках проекта, затрудняющих использование или реализацию. Для удобства разработчиков необходимо квантовать изменения: согласно определенным в графике датам выпускать очередные версии.

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

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

Единство «Принципов работы System/360» проистекает из того, что у них было лишь два автора: Джерри Блау и Андрис Падега. Авторами идей являются порядка десяти человек, но если требуется соблюсти согласованность описания и продукта, отливку решений в прозаические спецификации должны осуществлять не более двух человек. Для написания определения требуется принять массу мини-решений, которые не столь важны, чтобы выносить их на всеобщее обсуждение. Для System/360 примером служат подробности того, как после каждой операции устанавливается код условия. Однако задача всеобщей согласованности таких мини-решений не является тривиальной.

Думаю, что лучший виденный мной образец руководства — это написанное Блау приложение к «Принципам работы System/360». В нем тщательно и точно описаны границы совместимости System/360. Дано определение совместимости, предписывается, к чему нужно стремиться, и перечислены те области внешних проявлений, где архитектура намеренно молчит, и где результаты, полученные на разных моделях, могут отличаться между собой, где разные экземпляры одной модели могут дать различные результаты и даже один и тот же экземпляр может давать различия после конструктивных изменений. Это уровень точности, к которому стремятся составители руководств. Они должны одинаково описывать как то, что можно делать, так и то, что делать нельзя.