Мифический человеко-месяц

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

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

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

Библиотеки программ и учет. При создании OS/360 инструментальная машина очень успешно и с большой пользой применялась для ведения библиотек программ. Система, разработанная под руководством У. Р. Кт"ау-ли, состояла из двух сопряженных моделей IBM 7010, совместно использующих большой банк данных на дисках. Машины имели также ассемблер Системы 360. Все'; машинные программы, как исходные, так и оттранслированные модули загрузки, уже проверенные или проходящие проверку, хранились в этой библиотеке. Библиотека делилась на подбиблиотеки с различными правилами обращения к ним.

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

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

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

Здесь необходимо выделить два понятия. Первое - это контроль, т. е. идея принадлежности программ руководителям, которые единолично могут разрешать вносить изменения. Второе - это формальное разделение и перенесение затем с "площадки для игр" для объединения в систему.

По моему мнению, это одна из наиболее хорошо сделанных вещей в проекте OS/360. Этот метод техники административного управления был независимо выра-оотан в нескольких больших программистских проектах, в том число в фирме Bell Labs, ICL и в Кембриджском Университете2). Такая техника незаменима.

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

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

Система документации. Машинная система редактирования текстов, работающая на достоверной инструментальной машине, является, может быть, самой полезной из всего инструментария н экономист больше всего труда. В нашем распоряжении была очень удобная система, разработанная Дж. Франклином. Мне кажется, что без этой системы руководства по 08/360 появились бы гораздо позже и были бы гораздо менее ясными. Говорят, что для руководств но OS/360 требуется двухметровая полка, потому что их авторы страдали недержанием речи, и что такое обилие томов придает системе своего рода непостижимость. И некоторая доля правды во всем этом есть.

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

Во-вторых, подобное изобилие гораздо предпочтительнее, чем нехватка документации, характерная для большинства систем программирования. Я охотно соглашусь, однако, с тем, что некоторые места написаны не слишком хорошо и доработка может привести к уменьшению объема. Некоторые же части напя-саны очень хорошо, например, "Concepts and Facilities".

Модель производительности. Лучше иметь, чем не иметь. Делайте модель по методу "снаружи - внутрь" (подробно мы рассмотрим этот метод в следующей главе), Используйте тот же самый нисходящий подход приразработке модели производительности, логической модели и самого программного продукта. Начинайте де-латьмодель пораньше. Прислушайтесь к тому, что она будет вам говорить.

Язык высокого уровня и диалоговое программирование

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

Язык высокого уровня. Основные доводы в пользу языка высокого уровня производительность и быстрота отладки. Вопрос о производительности мы обсудили ранее (гл. VIII). В цифрах оценить преимущества использования такового языка очень трудно.

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

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

Ну а каковы же обычные возражения против использования языка высокого уровня? Их три: я не смо-^ делать, что хочу; рабочая программа слишком велика; рабочая программа работает слишком медленно. Я думаю, что первое возражение более не справедливо. Все опыты показывают, что каждый может выполнить все, что ему требуется. Правда, иногда .нужно крепко потрудиться, чтобы отыскать способ, кату это сделать3'4)

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