Последний вопрос самый легкий. Я, естественно, не собираюсь настаивать на том, что только у архитекторов могут быть хорошие архитектурные идеи. Довольно часто свежая мысль исходит от разработчика пли от пользователя. Однако весь мой опыт убеждает меня в том, что именно концептуальное единство системы определяет легкость ео использования, и я попытаюсь это показать. Предлагаемые средства и идеи сами по себе могут быть очень хороши, но если они не составляют единого целого с основными концепциями системы, от них лучше отказаться. Если же таких отличных, но несовместимых идей оказалось много, остается только выбросить в мусорную корзинку всю систему и заняться созданием новой, обладающей единством и построенной на других основных идеях.
Что касается вопроса о появлении новой аристократии, то следует ответить и да, и нет.
Да - в том смысле, что архитекторов всегда немного, а конечный продукт их деятельности живет дольше, чем результаты труда разработчиков, и архитектор находится в центре всех усилий по проектированию системы, защищая интересы пользователей. Если система должна обладать концептуальным единством, то необходим кто-то, следящий за этими концепциями. Это и есть та аристократия, которая не нуждается в извинениях.
Нет - потому что разработка внешних спецификаций - ничуть не более творческая работа, чем разработка проектов. Просто это другая работа. Разработка проекта, если архитектура уже имеется, требует от исполнителей и позволяет им в той же мере проявлять творческие способности и выдавать новые идеи, как и создание внешних спецификаций. По существу отношение стоимости продукта к его производительности в основном зависит от разработчика, в то время как простота пользования зависит от архитектора.
Существует множество примеров из других областей искусства и ремесла, заставляющих поверить в то, что дисциплина полезна. Как утверждает афоризм, распространенный среди художников, "форма освобождает". Хуже всего получаются сооружения, бюджет которых -больше, чем это нужно для достижения поставленной цели. Вряд ли необходимость каждую неделю писать по кантате отрицательно сказывалась на творческих возможностях Баха. Я уверен, что архитектура вычислительной машины Stretch много выиграла бы от введения более строгих ограничений; так, ограничения, накладываемые бюджетом модели 30 Системы 360, по моему мнению, положительно сказались на архитектуре модели 75. Аналогично я подметил, что заданная архитектура повышает, а не подавляет творческие возможности группы разработчиков. Они сразу же сосредоточиваются на той части проблемы, которой еще не занимались, и в результате появляются творческие находки. Если же на работу группы не накладывается никаких ограничений, то много времени и усилий, размышлений и обсуждений уйдет на архитектурные решения, а с самой реализацией они справятся очень быстро5).
Существование этого эффекта, который я наблюдал неоднократно, подтверждает Р. Конвей - руководитель группы, создавшей транслятор PL/G с языка PL/I в Корнелльском университете. Он говорит: "В конце концов, мы решили реализовать язык без всяких изменений и улучшений, потому что дебаты по этому вопросу отняли бы у нас все силы"6).
Чем может заполнить разработчик период ожидания?
Ошибка, стоимостью в несколько миллионов долларов, служит очень горестным уроком, но запоминается надолго. Я живо помню тот вечер, когда мы принимали решение о написании внешних спецификации для OS/360. Руководитель группы архитекторов ЭВМ, руководитель отдела разработки управляющих программ и я бились над планом, графиком и распределением обязанностей.
В группе архитекторов было 10 отличных специалистов. Ее руководитель утверждал, что они могут написать спецификации, и сделают это хорошо. Но на это потребуется 10 месяцев, на три месяца больше, чем допускал график.
В отделе управляющих программ было 150 человек. Ее руководитель говорил, что, взаимодействуя с архитекторами, они смогут подготовить практичные спецификации высокого качества и при этом уложиться в график. Если же этим займутся архитекторы, то его 150 человек будут десять месяцев бить баклуши.
На это архитектор отвечал, что если я поручу написание спецификаций отделу управляющих программ, то мы не только не дождемся результатов вовремя, но получим их на три месяца позже и они окажутся гораздо хуже. Так ц получилось. Архитектор был прав во всех отношениях. Кроме того, отсутствие концептуального единства увеличило стоимость создания и модификации системы п, по моим оценкам, удлинило срок отладки по меньшей мере па год.
Много факторов, конечно, повлияло на принятие этого ошибочного решения, но главными были график п желание дать работу 150 разработчикам. Сирены пели мне именно эту песню, ц теперь-то я вижу всю ее смертельную опасность.
Когда речь заходит о том, чтобы поручить маленькой группе архитекторов создание всех внешних спецификаций для вычислительной машины или системы программирования, разработчики выдвигают три возражения:
* спецификации будут слишком разнообразны по функциям, но не учтут практическую стоимость реализации;
* архитекторы сделают всю творческую часть работы, лишив разработчиков возможности что-либо придумать самим;
* большому числу разработчиков придется простаивать, в то время как спецификации будут проходить через игольное ушко, называемое группой архитекторов.
Первое представляет реальную опасность и подробнее будет рассматриваться в следующей главе. Два других возражения - не более, чем мираж. Как мы уже убедились, разработка - тоже творческая деятельность. Возможности для творчества и проявления изобретательности при разработке не уменьшаются сколько-нибудь значительно из-за необходимости работать с заданными внешними спецификациями, а степень проявления творческой активности может даже возрасти благодаря дисциплине. Конечный же продукт, вне всякого сомнения, от этого только выиграет.
Последнее возражение касается распределения времени и этапов работы. Первый ответ, приходящий на ум, заключается в том, что не нужно нанимать разработчиков до тех пор, пока не будут готовы спецификации. Именно так поступают при строительстве здания.
Однако в системном программировании темпы выше и график очень уплотнен. Насколько можно совместить этапы создания спецификаций и самого строительства?
Как подчеркивает Блау, в творческой деятельности выделяются три различные этапа: архитектура, разработка и реализация. На практике оказывается, что все этапы могут начинаться одновременно и проходить параллельно.
При проектировании вычислительной машины, например, разработчик уже может начинать работу, даже если он имеет довольно смутные представления о принципах действия, несколько более ясные технологические идеи и четко определенные понятия о стоимости и производительности. Он может начать проектировать информационные связи, управляющие последовательности, принципы компоновки п т. д. Он придумывает пли совершенствует средства, которые ему потребуются, особенно систему документирования, включая систему автоматизации проектирования.
Одновременно может проходить разработка и устранение недостатков у интегральных схем, плат, кабелей, стоек, источников питания, запоминающих устройств и т. д., и составляться документация для них.
Эта работа выполняется параллельно с созданием архитектуры и ее реализацией.
Аналогично обстоит дело и при проектировании систем программирования. Задолго до того, как завершены спецификации, у разработчика уже много дел. Обладая некоторыми приблизительными сведениями о функциях системы, которые получат свое отражение во внешних спецификациях, он уже может действовать. Он должен точно знать поставленные ему сроки и отведенные средства. Он должен знать машину, на которой будут пропускаться его программы. Далее он может приступить к разработке сопряжения модулей, структуры таблиц, алгоритмов, распределению работы по фазам. Некоторое время следует затратить на установление контактов с архитекторами.
Кроме того, и здесь на уровне реализации также много параллельной работы. В программировании тоже есть технология. Если машина новая, то предстоит большая работа с подпрограммами, супервизором, алгоритмами поиска и сортировки7).
Концептуальное единство действительно требует, чтобы система отражала единую философию и чтобы спецификации в том виде, в каком они доходят до пользователя, исходили от нескольких человек. Реалъное разделение труда на архитектуру, разработку и реализацию вовсе не означает, чуб на создание системы в целом, спроектированной таким образом, потребуется больше времени. Опыт показывает обратное, а именно, отдельные модули быстрее объединяются в систему, и на се отладку требуется меньше времени. Таким образом, широко распространенное горизонтальное разделение труда сокращается за счет вертикального разделения труда, при этом существенно упрощается обеспечение связи и повышается концептуальное единство проекта.
V. ЭФФЕКТ ВТОРОЙ СИСТЕМЫ
Если ответственность за функциональные спецификации отделить от ответственности за быстрое создание дешевого конечного продукта, то как поставить пределы творческому энтузиазму архитектора?
Фундаментальное решение этой проблемы заключается в установлении тесной, последовательной и основанной на симпатиях связи между архитектором и разработчиком. Но есть и более тонкий ее аспект, обычно ускользающий от нашего внимания.
Принципы совместной работы
Архитектор сооружения занимается финансовой сметой, используя собственные методы оценки, которые позже утверждаются подрядчиком, или же последний вносит в них свои коррективы. Часто оказывается, что величина затрат, определяемая подрядчиком, не укладывается в смету. Архитектору приходится тогда пересматривать свои методы оценки с точки зрения увеличения сметы и свой проект с точки зрения его удешевления. Однако он может предложить подрядчикам способы более дешевой реализации проекта, чем разработанные ими.
В аналогичной ситуации находится архитектор вычислительной системы или системы программирования. Он обладает, однако, тем преимуществом, что подрядчики сообщают ему свои цены на гораздо более ранних этапах проекта: ахитектор может практически в любой момент потребовать от них сведения о затратах. Но он обычно испытывает неудобства из-за необходимости работать только с одним подрядчиком, который может повышать или понижать свои цены в зависимости от степени удовлетворенности проектом. На практике ранняя и постоянная связь помогает архитектору иметь нужные данные о затратах, а разработчику - осуществлять непосредственное знакомство с проектом, при этом/различия в обязанностях не стираются.
Если архитектор оказался перед проблемой завышенных оценок, у него два выхода: урезать проект пли оспорить оценки, предложив более дешевую реализацию. Последний путь эмоционально очень опасен. Архитектор оспаривает метод выполнения работы строителя, предложенный самим строителем. Чтобы он привел к успеху, архитектор должен:
* помнить, что строитель несет творческую ответственность за реализацию, поэтому архитектор предлагает, но не приказывает;
* быть готовым к тому, чтобы предложить свой способ реализации продукта, спецификацию которого он написал, \i к тому, чтобы принять любой другой способ, если последний отвечает поставленным задачам;
* выдвигать такие предложения спокойно, в узком кругу;
* уметь отказываться от предлагаемых улучшенхщ. Обычно строитель начинает противиться предлагаемым изменениям в архитектуре. И зачастую он прав - какая-нибудь незначительная деталь может оказаться неожиданно дорогой в процессе реализации.
Самодисциплина. Эффект второй системы
В своей первой работе архитектор обычно проявляет умеренность и аккуратность. Он знает, что он не знает того, что делает, а потому делает это тщательно и держит себя "в рамках".
В процессе работы над своим первым проектом ему приходят па ум всякого рода находки и украшательства. Все они откладываются "до следующего раза". Рано или поздно работа над первой системой приходит к концу, и архитектор, преисполненный уверенности и продемонстрировавший свое мастерство на системах этого класса, готов заняться второй системой.
Эта вторая система - самая опасная из всех, которые когда-либо проектирует человек. Когда он будет делать следующие, опыт прежних разработок позволит ему установить общие характеристики таких систем, а различия между ними укажут на конкретные детали, не обобщаемые и не распространяющиеся на все системы.
Общая тенденция Заключается в создании сверхпроекта второй системы, путем использования всех идей и находок, от которых предусмотрительно отказались в первой. В результате, как сказал Овидии, получается "большая куча". Рассмотрим в качестве примера архитектуру ЭВМ IBM-709, позже воплотившуюся в модели IBM-7090. Это - вторая система по отношению к очень удачной IBM-704. Набор операций в модели IBM-709 настолько велик и разнообразен, что едва ли половина из них регулярно используется.
Еще более убедительный пример являет собой архитектура, разработка и даже реализация вычислительной машины Stretch, в которых нашли выход ранее сдерживаемые стремления многих людей к изобретательству, и которая была второй системой для большинства из них. Как говорит Стрейчив своем обзоре, "у меня создалось впечатление, что в известном смысле проект Stretch последнее звено в цепи развития. Как и некоторые предыдущие разработки, он в высшей степени хитроумен, в высшей степени усложнен, крайне эффективен, но в то же самое время он в чем-то не продуман, расточителен и неэлегантен, и чувствуется, что существуют гораздо лучшие способы создания таких вещей))1).
Операционная система OS/360 была второй системой для большинства ее разработчиков. В этот коллектив вошли создатели таких разных проектов, как операционная система DOS/1410-7010, операционная система Stretch, система реального времени в проекте Mercury и IBSYS для IBM-7090. Но почти никто из них не имел опыта создания двух операционных систем 2). Таким образом, OS/360 - это чистый пример эффекта второй системы, своего рода stretch*) в искусстве системного программирования, и к ней равно относятся и похвалы, и порицания Стрейчи.
Например, в OS/360 отводится 26 байтов оперативной памяти для постоянно хранящейся в ней программы, предназначенной для обработки даты "31 декабря" в високосном году (когда 366 дней). А это можно было бы оставить оператору.
Эффект второй системы имеет и другое проявление, отличное от чисто функциональных украшательств. Это - тенденция к усовершенствованию методов, само существование /которых становится ненужным из-за изменений /в исходных посылках системы. OS/360 может /^ать много примеров такого рода. //
Рассмотрим редактор связей, предназначенный для загрузки отдельно оттранслированных программ и обработки перекрестных ссылок. Кроме своих основных функций, он осуществляет также статистическую сегментацию программы. Это - одно из самых лучших средств сегментации, когда-либо придуманных. Оно позволяет осуществлять внешнюю сегментацию во время работы редактора связей, а не вводить ее в исходную машинную программу, что дает возможность менять структуру сегментов от прогона к прогону без повторной трансляции. Тем самым обеспечивается богатый набор полезных вариантов и возможностей. В определенном смысле это - кульминация развития метода статистической сегментации.
Но одовременно это и последний из динозавров. Дело в том, что это средство принадлежит системе, в которой мультипрограммирование является нормальным режимом работы, а динамическое распределение памяти - исходной посылкой, что находится в прямом противоречии с идеей использования статистической сегментации. Насколько лучше работала бы система, если усилия, затраченные на управление сегментацией, были бы направлены на то, чтобы осуществлять динамическое распределение памяти и динамические перекрестные ссылки по-настоящему быстро.
Далее, сам редактор связей требует такого большого объема памяти и содержит так много своих собственных сегментов, что если даже использовать его только для связи без управления сегментацией, то он работает медленнее большинства трансляторов. По иронии судьбы, сам редактор связей создавался для того, чтобы избежать ретрансляции. Как у конькобежца туловище опережает ноги, так и усовершенствования продолжаются до тех пор, пока исходные посылки системы не останутся позади.