 рассуждениЯх  предполагалось,  что  только  перваЯ
контрольнаЯ  точка  была   неверно   рассчитана.   …сли   1   марта  сделать
консервативное предположение, что весь график  был излишне оптимистичен, как
отражено на рисунке  2.7,  требуетсЯ добавить 6 человек  к исходной  задаче.
ђасчет   воздействиЯ  обучениЯ,   перераспределениЯ   задач   и   системного
тестированиЯ  предоставлЯетсЯ сделать читателю  в  качестве упражнениЯ.  Ќет
сомнений, что при попытке уложитьсЯ в срок в итоге получитсЯ худший продукт,
чем  при изменении  графика и сохранении первоначальных  троих  человек  без
усилениЯ.
     Љрайне упрощаЯ, сформулируем ‡акон Ѓрукса:
     <b><i>…сли  проект  не  укладываетсЯ  в  сроки</b></i><b><i>,</b></i>  <b><i>то  добавление  рабочей силы
задержит его еще больше</b></i><b><i>.</b>
     </i>   ќто   развенчивает    миф   о   человеко-месЯце.   Џродолжительность
осуществлениЯ    проекта     зависит    от     ограничений,    накладываемых
последовательностью работ. Њаксимальное  количество разработчиков зависит от
числа  независимых подзадач.  ќти  две величины  позволЯют  получить  график
работ,  в  котором  будет меньше  занЯтых  разработчиков  и  больше месЯцев.
(…динственнаЯ  опасность  заключаетсЯ  в  возможном  устаревании  продукта.)
ЌельзЯ, однако,  составить работающие графики, в которых занЯто больше людей
и  требуетсЯ  меньше времени.  Џрограммные проекты чаще проваливаютсЯ  из-за
нехватки календарного времени, чем по всем остальным причинам вместе взЯтым.

        ѓлава   3.   ЋпрационнаЯ   бригада
     <i>ќти   исследованиЯ   выЯвили   большие
индивидуальные  различиЯ  в  производительности  между   лучшими  и  худшими
работниками, часто на порЯдок величин.
     ‘ЂЉЊЂЌ, ќђ€Љ‘ЋЌ € ѓђЂЌ’1</i>
     Ќа  встречах  компьютерных  специалистов  можно   постоЯнно  слышать
утверждениЯ молодых менеджеров программных проектов, что им предпочтительней
небольшие деЯтельные  команды  первоклассных  специалистов, чем  проекты,  в
которых участвуют сотни программистов, что подразумевает их средний уровень.
€ всем нам тоже.
     ’акое  наивное  представление  альтернатив уходит  от  решениЯ  сложной
задачи  - как создавать большие  системы в  разумные сроки? ђассмотрим  этот
вопрос более подробно со всех сторон.
     Џроблема
     Њенеджеры программных  проектов давно понЯли,  что  хорошие  и  плохие
программисты  очень  сильно  различаютсЯ  между собой по производительности.
Ћднако реально  измеренные  величины поразительны.  ‚ одном  из исследований
‘акман   (Sackman),    ќриксон   (Erikson)    и   ѓрант   (Grant)   измерЯли
производительность труда в группе опытных программистов.  ‚нутри одной  лишь
этой группы  соотношение  между лучшими  и  худшими  результатами  составило
примерно 10:1 по  производительности труда и 5:1 по скорости работы программ
и требуемой длЯ  них  памЯти! Љороче,  программист, зарабатывающий  20 тысЯч
долларов  в   год,  может  быть  в  десЯть  раз  продуктивнее  программиста,
зарабатывающего  10 тысЯч долларов. Џравда, возможно и  обратное. Џолученные
данные   не   выЯвили   какой-либо   коррелЯции  между   стажем   работы   и
производительностью. (џ не уверен, что это всегда справедливо.)
     ‚ыше Я доказал, что само число разработчиков,  действиЯ  которых  нужно
согласовывать,   оказывает   влиЯние   на   стоимость   проекта,   поскольку
значительнаЯ  часть издержек вызвана  необходимостью  общениЯ  и  устранениЯ
отрицательных  последствий  разобщенности  (системнаЯ  отладка).  ќто  также
наводит  на  мысль, что желательно  разрабатывать  системы возможно  меньшим
числом людей. „ействительно, опыт разработки больших программных систем, как
правило, показывает, что подход с  позиций грубой  силы  влечет  удорожание,
замедленность,  неэффективность,  а  создаваемые  в  результате  системы  не
ЯвлЯютсЯ концептуально целостными.  ‘писок, иллюстрирующий  это, бесконечен:
OS/360, Exec 8, Scop 6600, Multics, TSS, SAGE и другие.
     ‚ывод  прост:  если  над  проектом   работают   200  человек,   включаЯ
менеджеров, ЯвлЯющихсЯ наиболее знающими и опытными программистами,  увольте
175 бойцов, и пусть менеджеры снова займутсЯ программированием.
     „авайте  рассмотрим  это  решение. ‘  одной  стороны,  ему  не  удаетсЯ
приблизитьсЯ к  идеалу  <i>небольшой</i>  активной  команды, в  которой,  по общему
признанию,  должно  быть  не  более  10  человек.  Џоэтому  размер   бригады
предполагает наличие  как  минимум  двух уровней управлениЯ, или  около пЯти
менеджеров.  ЏотребуютсЯ дополнительны финансовые расходы, сотрудники, место
длЯ работы, секретари и операторы машин.
     ‘ другой  стороны, исходнаЯ команда из 200  человек имела  численность,
недостаточную длЯ созданиЯ действительно крупных систем методом грубой силы.
ђассмотрим, к  примеру, OS/360. Ћдно времЯ в ее  создании было занЯто больше
1000  человек   -   программистов,  составителей  документации,  операторов,
клерков, секретарей, менеджеров, вспомогательных групп и т.д. ‘ 1963 по 1966
год  на   ее  проектирование,  реализацию  и   написание  документации  было
затрачено, вероЯтно, около  5000  человеко-лет.  …сли бы  строго соблюдалась
пропорциЯ  между  количеством  занЯтых  и  продолжительностью  работ,  нашей
предполагаемой  команде  из двухсот человек потребовалось бы  25  лет, чтобы
довести продукт до сегоднЯшнего уровнЯ!
     ‚  этом и состоит изъЯн идеи  маленькой активной команды: <i>длЯ  созданиЯ
по-  настоЯщему  крупных  систем  ей  потребуетсЯ  слишком   много  времени</i>.
Џосмотрим,  как  разработка  OS/360  осуществлЯлась  бы  маленькой  активной
командой,  допустим, из  10  человек.  Џоложим, что  они  в семь  раз  более
продуктивны  средних программистов  (что  <i>далеко</i>  от  истины). „опустим, что
уменьшение объема общениЯ благодарЯ  малочисленности команды позволило еще в
семь раз  повысить  производительность.  „опустим, что  на протЯжении  всего
проекта работает одна и та же команда. ’аким образом, 5000/(10*7*7)=10, т.е.
работу  в  5000  человеко-лет  они  выполнЯт  за  10  лет. Ѓудет  ли продукт
представлЯть интерес через  10  лет после  начала  разработки  или  устареет
благодарЯ стремительному развитию программных технологий?
     „илемма представлЯетсЯ  жестокой. „лЯ  эффективности  и  концептуальной
целостности   предпочтительнее,  чтобы  проектирование  и  создание  системы
осуществили несколько  светлых  голов. Ћднако длЯ больших систем  желательно
поставить под ружье значительный контингент, чтобы продукт мог увидеть  свет
вовремЯ. Љак можно примирить эти два желаниЯ?
     Џредложение Њиллза
     Џредложение •арлана Њиллза дает свежее и творческое  решение2,3. Њиллз
предложил,  чтобы  на  каждом  участке работы  была  команда  разработчиков,
организованнаЯ  наподобие  бригады хирургов, а не мЯсников. €меетсЯ в  виду,
что  не каждый  участник группы  будет  врезатьсЯ  в задачу, но резать будет
один,  а  остальные  оказывать  ему  всевозможную   поддержку,  повышаЯ  его
производительность и плодотворность.
     Џри некотором размышлении Ясно, что эта идеЯ приведет к желаемому, если
ее  удастсЯ осуществить.  ‹ишь  несколько  голов  занЯто  проектированием  и
разработкой, и в то же времЯ много  работников  находитсЯ на подхвате. Ѓудет
ли такаЯ организациЯ работать? Љто играет роль анестезиологов и операционных
сестер в  группе программистов, а как осуществлЯетсЯ разделение труда? —тобы
нарисовать картину  работы такой команды  с  включением всех  мыслимых видов
поддержки, Я позволю себе вольное обращение к метафорам.
     <b>•ирург</b>. Њиллз называет его <i>главным программистом</i>.  Ћн  лично определЯет
технические  условиЯ  на функциональность  и эксплуатационные характеристики
программы,   проектирует   ее,  пишет   код,  отлаживает  его  и  составлЯет
документацию. Ћн пишет  на  Языке структурного  программированиЯ, таком  как
PL/I, и имеет  прЯмой доступ  к  компьютерной системе, на которой не  только
производитсЯ  отладка, но  и сохранЯютсЯ  различные  версии  его  программ с
возможностью легкой модификации файлов, а также осуществлЯет  редактирование
документации.  Ћн  должен  обладать  большим  талантом,  стажем работы свыше
десЯти лет и существенными знаниЯми в системных и прикладных областЯх, будто
прикладнаЯ математика, обработка деловых данных или что-либо иное.
     <b>‚торой пилот</b>. ќто второе "Я" хирурга, может выполнЯть любую его работу,
но менее опытен. …го главнаЯ задача - участвовать в  проектировании,  где он
должен думать, обсуждать и оценивать. •ирург испытывает на нем свои идеи, но
не свЯзан  его предложениЯми. —асто второй пилот  представлЯет  свою бригаду
при обсуждении с другими группами функций и интерфейса. Ћн хорошо знает весь
код   программы.   Ћн   исследует   возможности   альтернативных   стратегий
программированиЯ. Ћн, очевидно, подстраховывает на  случай какой-либо беды с
хирургом.   Ћн  может   даже   заниматьсЯ  написанием   кода,  но  не  несет
ответственности за какую-либо его часть.
     <b>Ђдминистратор</b>. •ирург - начальник, и ему принадлежит последнее  слово в
отношении персонала, прибавок к  жалованью, помещений и т.п., но на эти дела
он  должен   тратить   как  можно  меньше  времени.  Џоэтому  ему  необходим
профессиональный   администратор,  заботой  которого  будут  деньги,   люди,
помещениЯ,  машины,  и   который  будет  контактировать  с  административным
механизмом организации в целом.  Ѓейкер считает, что на полный  рабочий день
администратор  должен  привлекатьсЯ  лишь  в  случае,  когда   отношениЯ   с
заказчиком  определЯют существенные юридические,  контрактные, отчетные  или
финансовые  требованиЯ к  проекту. ‚  остальных  случаЯх  один администратор
может обслуживать две команды.
     <b>ђедактор</b>. ЋбЯзанность разработки документации лежит  на хирурге.  —тобы
она была  максимально  понЯтна, он  должен  писать ее сам.  ќто относитсЯ  к
описаниЯм,  предназначенных  как  длЯ  внешнего,  так   и  длЯ   внутреннего
использованиЯ.  ‡адача  редактора  - взЯть созданный  хирургом  черновик или
запись   под  диктовку,  критически   переработать,  снабдить   ссылками   и
библиографией, проработать несколько версий и обеспечить публикацию.
     <b>„ва секретарЯ</b>.  Ђдминистратору и  редактору нужны секретари.  ‘екретарь
администратора  обрабатывает  переписку,   свЯзанную  с  проектом,  а  также
документы, не относЯщиесЯ к продукту.
     <b>„елопроизводитель</b>. Ћн отвечает за регистрацию  всех технических  данных
бригады в библиотеке программного продукта. Ћн имеет секретарскую подготовку
и несет ответственность за все файлы, предназначенные как длЯ машины, так  и
длЯ чтениЯ.
     ‚се  данные длЯ ввода  в компьютер поступают делопроизводителю, который
регистрирует их или вводит  при необходимости  с клавиатуры. ‹истинги вывода
также поступают к нему длЯ регистрации и  хранениЯ. ђезультаты  самых свежих
прогонов всех моделей заносЯтсЯ в журнал  результатов, а предыдущие хранЯтсЯ
в хронологическом порЯдке в архиве.
     †изненно   важным    длЯ   концепции   Њиллза   ЯвлЯетсЯ    превращение
программированиЯ  "из  личного  искусства в общественную деЯтельность" путем
предоставлениЯ  результатов <i>всех</i> прогонов  всем членам команды и определениЯ
всех  программ  и данных, как  общей  собственности  команды, а  не  чьей-то
личной.
     Ћсобые  обЯзанности,  возлагаемые   на  делопроизводителЯ,  освобождают
активных программистов  от  рутинных работ,  систематизируют  и обеспечивают
надлежащее выполнение тех рутинных операций,  которыми часто пренебрегают, и
приближают главное,  длЯ  чего  работает команда  -  ее программный продукт.
џсно, что предложеннаЯ концепциЯ предполагает прогон пакетных  заданий. …сли
используютсЯ интерактивные  терминалы, в особенности без возможности печати,
функции делопроизводителЯ не сокращаютсЯ,  но претерпевают изменениЯ. ‚ этом
случае он ведет учет всех изменений, вносимых в общий экземплЯр программы из
личных  копий,  осуществлЯет  прогон  всех  пакетных  заданий  и  со  своего
терминала    осуществлЯет    контроль    целостности   и   работоспособности
увеличивающегосЯ в размерах продукта.
     <b>€нструментальщик</b>.  ЃлагодарЯ  возможности в  любое  времЯ редактировать
файлы  и тексты и пользоватьсЯ службой  интерактивной отладки команде  редко
требуетсЯ  своЯ вычислительнаЯ машина и группа обслуживающего персонала.  Ќо
доступ к  этим  службам  должен  осуществлЯтьсЯ  с  безусловной  быстротой и
надежностью.  ’олько  хирург  может  решать,  удовлетворЯет  ли  его  работа
имеющихсЯ   служб.   …му  необходим   инструментальщик,   ответственный   за
обеспечение доступа  к основным службам, а также  за  создание,  поддержку и
обновление  специальных  инструментов  -  в основном,  интерактивных  служб,
которые   требуютсЯ  его   команде.  “  каждой  команды   должен  быть  свой
инструментальщик,   независимо   от   качества   и   надежности    имеющихсЯ
централизованных  служб,  и  его   дело  обеспечить  всем   необходимым  или
желательным   инструментом   <i>своего</i>   хирурга,   а   не    другие   команды.
€нструментальщик обычно пишет специализированные утилиты, каталогизированные
процедуры, макробиблиотеки.
     <b>Ћтладчик</b>. •ирургу потребуетсЯ набор подходЯщих контрольных примеров длЯ
отладки написанных  им фрагментов кода,  а затем  и всей программы. Ћтладчик
ЯвлЯетсЯ,  таким   образом,  как  противником,  разрабатывающим  контрольные
примеры длЯ системного тестированиЯ,  исходЯ из функциональных спецификаций,
так и  помощником, готовЯщим  данные длЯ ежедневной отладки. Ћн также обычно
планирует последовательность тестированиЯ и создание среды  длЯ тестированиЯ
компонентов.
     <b>џзыковед</b>. ‚скоре после поЯвлениЯ Algol обнаружилось, что в  большинстве
вычислительных центров есть  один-два  человека, поражающих своим  владением
тонкостЯми Языка программированиЯ. ќти эксперты оказываютсЯ очень полезными,
и с ними  часто советуютсЯ. ‡десь  требуетсЯ  иной талант,  чем  у  хирурга,
который   ЯвлЯетсЯ  преимущественно  системным  проектировщиком   и   мыслит
представлениЯми.  џзыковед  может  найти  эффективные  способы использованиЯ
Языка длЯ решениЯ сложных, неЯсных  и хитроумных задач. €ногда ему требуетсЯ
провести  небольшое  исследование  (два-три  днЯ)  длЯ   нахождениЯ  удачной
технологии. Ћдин Языковед может работать с двумЯ или тремЯ хирургами.
     ‚от таким образом 10 человек могут выполнЯть хорошо  дифференцированные
и специализированные роли в команде программистов, организованной по образцу
операционной бригады.
     Љак это работает
     ‘озданнаЯ  нами  бригада  может  достичь  желаемой  цели  несколькими
способами.   Ќад  задачей   трудЯтсЯ   десЯть   человек,  семь   из  которых
профессионалы,  но  система ЯвлЯетсЯ продуктом одного ума,  по крайней  мере
двух, действующих <i>uno animo</i> (как одно целое).
     Ћбратите   особое  внимание  на   различие   между   группой   из  двух
программистов с обычной организацией и группой типа "хирург - второй пилот".
‚о-первых, в обычной бригаде работники делЯт задачу между собой, и каждый из
них отвечает за замысел и воплощение некоторой части. ‚ операционной бригаде
и хирург,  и  второй  пилот  находЯтсЯ  в  ведении  всего  проекта  и  всего
программного кода. ќто сберигает затраты  на  распределение памЯти, доступ к
дискам и т.п., а также обеспечивает концептуальную целостность продукта.
     ‚о-вторых,  в обычной бригаде партнеры  равны, и неизбежные разногласиЯ
должны разрешатьсЯ путем  переговоров или  компромиссов.  Џоскольку задача и
ресурсы разделены, разногласиЯ относЯтсЯ к общей стратегии и интерфейсам, но
к  ним  примешиваетсЯ  и противоположность интересов,  например,  чью памЯть
использовать длЯ  буфера. ‚ хирургической бригаде различий  интересов нет, а
разногласиЯ  единолично решаютсЯ  хирургом. ќти два  различиЯ  -  отсутствие
разбиениЯ задачи и отношение подчиненности - позволЯют хирургической бригаде
действовать <i>uno animo</i>.
     Љроме того,  решающее влиЯние на эффективность  оказывает специализациЯ
функций  остальных   членов  бригады,  так   как  в  результате  осуществима
значительно  более  простаЯ  схема  контактов  между  сотрудниками,  котораЯ
показана на рисунке 3.1.
     ‚ статье Ѓейкера3 сообщаетсЯ об одной проверке такой концепции бригады,
проведенной в  ограниченном  масштабе.  Љак  и  предсказывалось,  результаты
оказались великолепными.
     Њасштабирование
     „о сих  пор  все было  хорошо. Џроблема, однако, состоит  в  том,  как
создавать  продукты,  на  которые  сейчас  уходит  не  20  или  30,  а  5000
человеко-лет. Ѓригада из 10 человек может быть эффективна вне зависимости от
своей  организации,  если задача  <i>целиком</i> находитсЯ в ее компетенции. Ќо как
использовать  идею операционной  бригады в  задачах, длЯ  выполнениЯ которых
привлекаютсЯ сотни людей?
     “спех   при   масштабировании   обусловливаетсЯ   коренным   улучшением
концептуального единства  каждого  участка, ведь  количество проектировщиков
уменьшилось  в  семь раз.  Џоэтому  можно привлечь к работе над задачей  200
человек, и необходимость координации умственных усилий потребуетсЯ всего длЯ
20 из них - хирургов.

     <img src=mithsoftware_pic3_1.png>

     <b>ђис. 3.1</b> ‘хема контактов между сотрудниками в бригаде из 10 человек
     Ћднако  задача  координации   требует   использованиЯ  особых  методов,
обсуждаемых в последующих главах. Џока достаточно сказать, что всЯ система в
целом  должна  обладать  концептуальным  единством,  и  необходим  системный
архитектор, чтобы  проектировать  ее целиком, в нисходЯщем  направлении. „лЯ
того чтобы  этой  работой можно было управлЯть, необходимо провести  строгое
разграничение  архитектуры  и  воплощениЯ,  и  системный  архитектор  должен
добросовестно  посвЯтить себЯ разработке архитектуры.  Ћпыт показывает,  что
такое  распределение ролей и такие  методы осуществимы и  оказываютсЯ весьма
результативными.

        ѓлава   4.  ЂристократиЯ,  демократиЯ   и  системное  проектирование
     <i>ќтот
величественный   храм  ЯвлЯетсЯ   выдающимсЯ   произведением   искусства.  ‚
принципах, которые он излагает, нет ни сухости, ни беспорЯдка...
     ќто  вершина  стилЯ, труд художников,  которые  понЯли и воспринЯли все
достижениЯ  своих  предшественников, в совершенстве  владеЯ  техникой своего
века, но пользовались  ей,  избегаЯ  нескромного  показа  или необоснованной
демонстрации мастерства.
     Ќесомненно, замысел  общего  плана зданиЯ принадлежит дЋрбе, и те,  кто
его  сменил,  придерживались этого плана,  по крайней  мере,  в существенных
чертах. ќто одна из причин удивительной гармоничности и единства зданиЯ.
     Џ“’…‚Ћ„€’…‹њ ЏЋ ђ…‰Њ‘ЉЋЊ“ ‘ЋЃЋђ“ 1</i>
     <b>Љонцептуальное единство</b>
     “  большинства  европейских  соборов  части,   построенные   разными
поколениЯми строителей, имеют различиЯ  в  планировке и архитектурном стиле.
Ѓолее   поздние  строители  испытывали   соблазн  "улучшить"  проект   своих
предшественников, чтобы  отразить новые веЯниЯ  моды и свои личные вкусы.  ‚
итоге мирный норманнский  трансепт  создает конфликт  с примыкающим  к  нему
возносЯщимсЯ  в  высь  готическим   нефом,   и  результат  столь  же  служит
восхвалению славы ѓосподней, сколь и гордыни строителей.
     Ђрхитектурное   единство   ђеймского   собора   находитсЯ    в   прЯмой
противоположности с  таким смешением стилей. €сточником  наполнЯющей зрителЯ
радости  служат  как   цельность  конструкции,  так  и   отдельные   образцы
совершенства.  Љак  сказано   в  путеводителе,   цельность  была  достигнута
благодарЯ  самоотречению  восьми поколений строителей собора, пожертвовавших
своими идеЯми ради чистоты общего замысла. ’о что получилось  в  результате,
служит  восхвалению   не  только  славы  ѓосподней,  но  и  …го  могущества,
способного спасти грешных людей от их гордыни.
     •отЯ на создание программных систем не уходЯт века, в большинстве своем
они демонстрируют  меньшую  согласованность концепций,  чем  в любом соборе.
Ћбычно это  происходит  не оттого, что  главные  проектировщики сменЯют друг
друга,  а потому, что проект  расщеплЯетсЯ на рЯд задач, выполнЯемых разными
разработчиками.
     џ   убежден,   что   концептуальнаЯ   целостность   ЯвлЯетсЯ  <i>важнейшей</i>
характеристикой  системного  проекта.  ‹учше  убрать  из  системы  отдельные
необычные  возможности  и  усовершенствованиЯ  и  реализовать  единый  набор
конструктивных   идей,    чем    оснастить   ее    многими    хорошими,   но
невзаимосвЯзанными и  несогласованными идеЯми. ‚  этой  и  двух  последующих
главах  мы изучим следствиЯ этой  концепции  длЯ проектированиЯ  программных
систем:
     - Љак достичь концептуальной целостности?
     -   Ќе   будет  ли   это   требование  причиной   раскола   на   элиту,
аристократический  класс   архитекторов   -   с   одной   стороны,  и  толпы
плебеев-исполнителей, чьи творческие таланты и идеи подавлЯютсЯ, - с другой?
     -  Љак  удержать  архитекторов  от  витаниЯ   в  облаках  и  разработки
несущественных или чрезмерно дорогих спецификаций?
     -  Љак добитьсЯ  того,  чтобы  любаЯ  мелочь из созданной  архитектором
спецификации дошла до исполнителЯ, была им правильно понЯта и точно внедрена
в продукт?
     „остижение концептуальной целостности
     Ќазначение  системы   программированиЯ  -   облегчить  использование
компьютера. „лЯ  этого  поставлЯютсЯ Языки и различные средства, ЯвлЯющиесЯ,
по сути, программами, вызываемыми и управлЯемыми возможностЯми Языка. Ќо эти
средства  стоЯт денег:  объем внешнего описаниЯ системы  программированиЯ  в
десЯть-  двадцать  раз  больше описаниЯ собственно  вычислительной  системы.
Џользователю  оказываетсЯ значительно проще задать любую  выбранную функцию,
но  выбор  очень  велик, и  нужно  помнить  значительно больше  вариантов  и
форматов.
     €спользование облегчаетсЯ,  только  если  выигрыш  времени  при задании
функции  превышает  времЯ, потраченное  на  обучение,  запоминание  и  поиск
руководств.  ‘овременные системы  программированиЯ  дают такой  выигрыш,  но
похоже,  что в последние годы  отношение  выигрыша к затратам  уменьшилось в
результате добавлениЯ все более и  более сложных функций. џ часто вспоминаю,
как  легко  было использовать  IBM  650,  даже  без  ассемблера  или  вообще
каких-либо программ.
     Џоскольку   целью  проектированиЯ   ЯвлЯетсЯ   простота  использованиЯ,
окончательную    оценку   проекта   системы   дает   достигнутое   отношение
функциональности к сложности концепций.  Ќи функциональность, ни  простота в
отдельности не ЯвлЯютсЯ признаками хорошего проекта.
     ќто  обстоЯтельство часто неправильно понимаетсЯ. Operating  System/360
превозноситсЯ  своими  создателЯми,  как  лучшаЯ  из  когда-либо  созданных,
поскольку  неоспоримо,  что  в ней  больше  функций.  ”ункции, а не простота
всегда  служили критерием  превосходства  ее  создателей. ‘ другой  стороны,
создатели   системы   с   разделением  времени  длЯ  PDP-10  превозносЯт  ее
превосходство ввиду простоты и немногочисленности положенных  в основу идей.
Ћднако по всем меркам ее функциональность ниже по классу, чем OS/360. …сли в
качестве критериЯ  определена простота  использованиЯ, становитсЯ  очевидной
несбалансированность этих систем, достигающих цели лишь наполовину.
     Ћднако  длЯ   некоторого   заданного  уровнЯ   функциональности  лучшей
оказываетсЯ та система, в  которой  можно  работать с наибольшей простотой и
непосредственностью. <i>Џростота</i> - это еще не все. џзык TRAC, созданный Њуером,
и  Algol  68  достигают  простоты, если  количественно  измерЯть  ее  числом
отдельных элементарных  понЯтий. <i>Ќепосредственность</i>,  однако,  не характерна
длЯ них. —тобы выразить свои  намерениЯ, часто  требуетсЯ  сочетать  базовые
средства   сложным  и  неожиданным  образом.  Ќедостаточно  изучить  базовые
элементы и  правила их  комбинированиЯ,  нужно  изучить  еще  идиоматическое
использование,  целую  область знаний о  том, как на практике  комбинировать
элементы.  Џростота  и  непосредственность   проистекают  из  концептуальной
целостности.  ‚о  всех  частЯх  должны  найти  отражение единаЯ философиЯ  и
единообразные пропорции  между желаемыми целЯми. ‚ каждой части должны также
использоватьсЯ  одинаковый  синтаксис и  сходные  семантические обозначениЯ.
’аким   образом,   простота   использованиЯ    требует   единства   проекта,
концептуальной целостности.
     ЂристократиЯ и демократиЯ
     ЉонцептуальнаЯ целостность, в  свою  очередь,  требует, чтобы  проект
исходил  от  одного  разработчика,  или  небольшого  числа  их,  действующих
согласованно и в унисон.
     ‘  другой стороны, напрЯженность графика требует  привлечениЯ  большого
числа работников.  …сть два метода разрешениЯ этой дилеммы. Џервый состоит в
тщательном разделении труда между архитектурой и исполнением. ‚торой - новый
способ  организации   бригад  программистов-исполнителей,   обсуждавшийсЯ  в
предыдущей главе. 31 Ћтделение разработки архитектуры от реализации ЯвлЯетсЯ
эффективным  способом  достижениЯ  концептуальной целостности при работе над
очень большими проектами.  џ лично  был свидетелем  успешного его применениЯ
при создании IBM компьютера Stretch  и серии  продуктов System/360. Ќо он не
сработал  при   разработке  Operating   System/360,  поскольку  недостаточно
применЯлсЯ.
     Џод  <i>архитектурой</i>  системы  Я  понимаю полную и подробную  спецификацию
интерфейса пользователЯ. „лЯ компьютера это руководство по программированию.
„лЯ  компилЯтора  это  руководство  по  Языку. „лЯ управлЯющей программы это
руководство  по  одному  или нескольким  Языкам, используемым длЯ  вызова ее
функций. „лЯ  системы в целом - это набор всех  руководств, к которым должен
обращатьсЯ пользователь при работе.
     Ђрхитектор системы,  как  и архитектор  зданиЯ, ЯвлЯетсЯ представителем
пользователЯ.  …го  задача  -   использовать  все  свои  профессиональные  и
технические знаниЯ  исключительно в интересах  пользователЯ,  а не продавца,
изготовителЯ и т.п.2
     Ђрхитектура и разработка  должны быть тщательно  разделены. Љак  сказал
Ѓлау (Blaauw),  "архитектура говорит, <i>что</i> должно произойти,  а разработка  -
<i>как</i> сделать, чтобы  это произошло".3 ‚ качестве простого примера он приводит
часы, архитектура которых состоит из циферблата, стрелок и заводной головки.
ђебенок,  освоивший  это  архитектуру,  с одинаковой  легкостью может узнать
времЯ  и по  ручным часам,  и  по часам  на колокольне. €сполнение же и  его
реализациЯ описывают,  что  происходит  внутри: передача усилий и управление
точностью каждым из многих механизмов.
     Љ  примеру, в System/360 одна и та же архитектура компьютера совершенно
по-  разному реализована примерно в девЯти моделЯх. Ћбратным образом, одна и
та  же  реализациЯ  потока  данных,  памЯти  и  микропрограмм  из  Model  30
использовалась в разное времЯ в  четырех различных архитектурах: System/360,
мультиплексном   канале  с   подключением   до  224   логически  независимых
подканалов, селекторном канале и компьютере 1401.4
     ’акие же  различиЯ можно проводить в отношении систем программированиЯ.
‘уществует стандарт  длЯ Fortran IV. ќто архитектура, используемаЯ во многих
компилЯторах. ‚ рамках этой архитектуры возможны разные  реализации: текст в
оперативной    памЯти    или   компилЯтор,   быстраЯ   или   оптимизирующаЯ,
синтаксическаЯ  или  <i>ad  hoc</i>. Ђналогично,  любой  Язык ассемблера  или  Язык
управлениЯ   заданиЯми   допускает    многие   реализации   ассемблера   или
планировщика.
     ’еперь  мы   можем   занЯтьсЯ  весьма  чувствительным  вопросом  борьбы
аристократии  и демократии. Ќе  стали ли  архитекторы  новой  аристократией,
интеллектуальной    элитой,   призванной   разъЯснить   бедным    безгласным
исполнителЯм,  что  они  должны  делать?  Ќе  захватила  ли  эта  элита  всю
творческую деЯтельность, сделав  исполнителей лишь зубчиками в механизме? Ќе
окажетсЯ ли, что более  совершенный  продукт можно получить,  используЯ идеи
всей  бригады  и  исповедуЯ  философию демократии,  а  не  ограничиваЯ  круг
разработчиков несколькими лицами?
     Џроще  всего  ответить на  последний  вопрос. џ, разумеетсЯ,  не  стану
утверждать,  что  хорошие  архитектурные  идеи  могут  возникать  только   у
архитекторов.  —асто свежаЯ идеЯ исходит  от  исполнителЯ  или пользователЯ.
Ћднако  весь  личный  опыт  убеждает  менЯ,  и Я пыталсЯ  это  показать, что
простоту  пользованиЯ  системой определЯет  ее  концептуальнаЯ  целостность.
„остойные вниманиЯ  функции  и  идеи,  которые  не объединЯютсЯ с  основными
концепциЯми  системы, лучше  оставить  в  стороне.  …сли  таких  важных,  но
несовместимых  идей  поЯвлЯетсЯ  слишком  много,  выкидывают всю  система  и
начинают  разработку   целостной  системы  сначала,  основываЯ  ее  на  иных
основополагающих концепциЯх.
     —то  касаетсЯ обвинений  в  аристократизме, то ответ и положительный, и
отрицательный. Џоложительный, потому что действительно должно быть несколько
архитекторов,  чьи  результаты  живут  дольше, чем  отдельные реализации,  и
архитектор  находитсЯ  в фокусе  сил, которые  он  в  конечном итоге  должен
использовать  в  интересах  пользователЯ.  …сли  вы  хотите,  чтобы  система
обладала  концептуальной  целостностью,  то  руководство концепциЯми  должен
взЯть кто-то один. ќто аристократизм, который не нуждаетсЯ в извинениЯх.
     Ћтвет отрицательный,  поскольку  разработка  проекта требует  не меньше
творчества, чем задание внешних спецификаций. ќто тоже творческаЯ работа, но
другого характера.  ђазработка  проекта  длЯ заданной архитектуры требует  и
допускает столько же творческой деЯтельности, новых идей, изобретательности,
как   и    проект    внешних    спецификаций.    Џрактически,    коэффициент
стоимость/эффективность созданного продукта больше зависит от исполнителЯ, а
простота его использованиЯ - от архитектора.
     …сть  масса  примеров,  подсказанных  другими искусствами и  ремеслами,
которые  подводЯт к мнению,  что дисциплина  идет на  пользу. „ействительно,
афоризм художника  гласит, что "форма освобождает".  ‘амые ужасны строениЯ -
это те, бюджет которых был  слишком велик длЯ поставленных целей. ’ворческую
активность  Ѓаха  едва   ли  могла  подавлЯть   необходимость   еженедельнаЯ
необходимость  изготавливать  кантату  определенного  вида.  џ  уверен,  что
архитектура компьютера Stretch стала бы лучше, если бы на нее наложили более
жесткие  ограничениЯ;  так,  ограничениЯ, наложенные бюджетом на  System/360
Model 30, по моему мнению, принесли лишь пользу архитектуре Model 75.
     Ђналогично, Я  считаю, что получение  архитектуры извне усиливает, а не
подавлЯет   творческую   активность   группы    исполнителей.   Ћни    сразу
сосредоточиваютсЯ на  той части  задачи, которой  никто  не  занималсЯ, и  в
результате изобретательность бьет ключом. ‚ не ограничиваемой группе большаЯ
часть  обдумываниЯ  и обсуждениЯ посвЯщена  архитектурным решениЯм  в  ущерб
реализации.5
     ќтот многократно наблюдавшийсЯ мной эффект подтвердил ђ. “. Љонвей  (R.
W.  Conway), чьЯ группа  разработала  в  Љорнельском университете компилЯтор
PL/C длЯ Языка  PL/I.  Ћн говорит: "‚ конечном  итоге мы решили  реализовать
Язык без изменений и усовершенствований,  поскольку обсуждение Языка  отнЯло
бы у нас все силы."6
     —ем занЯтьсЯ разработчику, пока он вынужден ждать?
     Ћчень  неприЯтно совершить  ошибку стоимостью в  миллион долларов, но
зато  она надолго запоминаетсЯ. џ отчетливо помню тот день, когда мы принЯли
решение о том, как практически организовать составление внешних спецификаций
длЯ  OS/360. Њенеджер  по  архитектуре, менеджер по  реализации  управлЯющей
программы и Я прорабатывали план, график и разделение обЯзанностей.
     “ менеджера  по архитектуре было 10 хороших специалистов. Ћн утверждал,
что они в состоЯнии написать спецификации и сделать это должным образом. ќто
должно было занЯть 10 месЯцев - на три больше, чем отводилось по графику.
     “  менеджера по реализации управлЯющей программы было  150 человек.  Ћн
заЯвлЯл,  что   они  могут   подготовить   спецификации,   при  этом  группа
архитекторов  выполнЯла бы координирующие функции. Ћбещалось, что это  будет
сделано хорошо и практично, с соблюдением сроков. Ѓолее того,  если оставить
спецификации  группе архитекторов, его  150 человек в течение десЯти месЯцев
будут бить баклуши.
     Ќа   это   менеджер  по  архитектуре   возразил,  что  если  Я   сделаю
ответственной  за  написание  спецификаций группу управлЯющей  программы, то
результата в  срок  не будет: он  все равно задержитсЯ на  три месЯца, но по
качеству будет  много  хуже.  ’ак  оно  и  оказалось в действительности.  Ћн
оказалсЯ прав в обоих пунктах. Љроме  того, из-за отсутствиЯ  концептуальной
целостности создание и внесение  изменений в  систему  оказались значительно
более дорогостоЯщими, и, по моим оценкам, отладка удлинилась на год.
     Љонечно, многие факторы повлиЯли  на принЯтие этого ошибочного решениЯ,
но определЯющими были желание уложитьсЯ в график и стремление занЯть работой
этих 150 человек. Џение этих сирен таит  смертельные опасности, которые  Я и
хочу сейчас показать.
     Љогда предлагаетсЯ, чтобы все внешние спецификации длЯ компьютерной или
программной  системы   были   составлены  небольшой  командой  архитекторов,
исполнители выдвигают три возражениЯ:
     -  ‘пецификации  будут  перегружены  функциЯми  и  не  будут  учитывать
практических затрат на реализацию.
     -   Ђрхитекторы   получат   все  радости   творчества   и   заблокируют
изобретательность исполнителей.
     -  Њногочисленным  исполнителЯм  придетсЯ ожидать  в  праздности,  пока
спецификации пройдут через узкое горлышко команды архитекторов.
     Џервое  возражение отражает реальную опасность  и  будет рассмотрено  в
следующей главе. Ћстальные два ЯвлЯютсЯ чистым заблуждением.  Љак  мы видели
выше,  разработка также ЯвлЯетсЯ в высшей степени творческой  деЯтельностью.
‚озможность   проЯвить  творчество   и  изобретательность   при   разработке
незначительно  ограничиваетсЯ  необходимостью  работать  в  рамках  заданных
внешних  спецификаций,  и  такаЯ  дисциплина  может  даже   усилить  степень
творчества. ќто, несомненно, верно длЯ проекта в целом.
     Џоследнее  возражение касаетсЯ планированиЯ  временных  рамок и этапов.
Џроще всего воздержатьсЯ  от  найма  исполнителей до  завершениЯ работы  над
спецификациЯми. Љогда воздвигаетсЯ здание, так и поступают.
     Ћднако  при  создании  компьютерных систем  темпы  выше,  и  желательно
уплотнить график работ.  ‚ какой мере разработка  спецификаций  и разработка
могут перекрыватьсЯ?
     Љак  отмечает  Ѓлау, всю программу  созданиЯ  составлЯют три  отдельные
стадии: архитектура, разработка и реализациЯ.  ЋказываетсЯ, что на  практике
их  можно  начинать  параллельно и продолжать  одновременно.  Ќапример,  при
проектировании  компьютеров проектировщик  может приступать  к работе,  имеЯ
относительно общие допущениЯ в отношении руководства пользователЯ, несколько
более Ясные  идеи относительно технологии  и вполне  определенные  задачи по
стоимости и рабочим характеристикам. Ћн может начать  проектирование потоков
данных,  управлЯющих последовательностей, общих идей  компоновки и  т.д.  Ћн
разрабатывает или адаптирует необходимый  инструментарий,  особенно  систему
ведениЯ учета, в том числе систему автоматизации проектированиЯ.
     ‚   то   же   времЯ  на   уровне   реализации   нужно   спроектировать,
усовершенствовать  и  описать  микросхемы,  платы,  кабели,  каркасы,  блоки
питаниЯ и устройства памЯти. ќта работа протекает параллельно с архитектурой
и разработкой.
     ’о же самое справедливо  при  создании программных  систем. ‡адолго  до
завершениЯ внешних спецификаций  проектировщик может  найти  себе достаточно
работы.  Ћн  может  приступить к  делу,  основываЯсь  на грубом  приближении
функциональности  системы,  котораЯ  в  конечном  итоге будет  воплощена  во
внешних спецификациЯх. “ него должны быть Ясно определенные цели в отношении
памЯти и временных  параметров. Ћн  должен изучить конфигурацию системы,  на
которой  будет  выполнЯтьсЯ его продукт.  ‡атем он может начать  определение
границ   модулей,  структур  таблиц,  расчленениЯ  на  проходы   или  стадии
алгоритмов и  всевозможных  инструментальных  средств.  Ќекоторое  времЯ  он
должен также посвЯтить общению с архитектором.
     ‚   то  же  времЯ   достаточно   работы  и  на  уровне   реализации.  “
программированиЯ  своЯ технологиЯ. …сли  машина  новаЯ, много  труда требуют
соглашениЯ  по  подпрограммам, технологиЯ  работы с супервизором,  алгоритмы
поиска и сортировки.7
     ЉонцептуальнаЯ  целостность  требует,  чтобы  система  отражала  единую
философию,  и технические  условиЯ, в том  виде, в котором  они  будут видны
пользователю,  проистекали от малого  числа авторов.  ќто  не означает,  что
спроектированнаЯ   таким   образом  система   создаетсЯ   дольше,  поскольку
используетсЯ  действительное разделение труда  на архитектуру,  разработку и
реализацию. Ћпыт показывает обратное: цельнаЯ система продвигаетсЯ быстрее и
требует  меньше времени  длЯ отладки. ‚  результате  широко распространенное
горизонтальное   разделение   труда   значительно   сокращаетсЯ   за    счет
вертикального разделениЯ, что влечет  резкое уменьшение обмена информацией и
улучшение концептуальной целостности.

        ѓлава 5. ќффект второй системы
     <i>Adde parvum parvo magnus acervus erit.
     [‘кладывай малое с малым, и получишь большую кучу.]
     Ћ‚€„€‰</i>
     …сли   ответственность   за   спецификацию   функций   отделить   от
ответственности  за  быстрое создание  недорогого продукта, то чем  сдержать
изобретательский энтузиазм архитектора?
     Џринципиальное  решение  -  обеспечение  всестороннего,  тщательного  и
доброжелательно  обмена  информацией  между  архитектором  и  разработчиком.
Ћднако имеютсЯ и более тонкие решениЯ, которые заслуживают вниманиЯ.
     „исциплина взаимодействиЯ длЯ архитектора
     Ђрхитектор,  строЯщий  здание,  действует  в рамках сметы,  используЯ
методы  оценки,  которые  в  последующем  подтверждаютсЯ  или корректируютсЯ
заЯвками подрЯдчиков. —асто случаетсЯ, что все предложениЯ выходЯт  за рамки
сметы. ’огда  архитектор  пересматривает  свои оценки  в сторону  увеличениЯ
сметы,  а  проект  -  в  сторону  сокращениЯ, и цикл повторЯетсЯ. €ногда  он
предлагает  подрЯдчикам  способы  удешевлениЯ  реализации   его  проекта   в
сравнении с избранными ими способами.
     ‘ходные процессы происходЯт с архитектором компьютерных или программных
систем. Ћднако у него есть то преимущество, что предложениЯ подрЯдчика можно
получить  на  ранних   стадиЯх  проектированиЯ,  часто  -  в  любой  момент.
Ќедостатком обычно  ЯвлЯетсЯ то, что работа идет с единственным подрЯдчиком,
который может менЯть цену  в  зависимости от степени своей удовлетворенности
проектом.  Ќа  практике,  процесс  общениЯ,  начатый  на   ранних  этапах  и
продолжающийсЯ непрерывно, может дать архитектору верную оценку стоимости, а
разработчику   -   уверенность  в  проекте,  не   снимаЯ  при  этом  четкого
разграничениЯ сфер ответственности.
     “  архитектора, когда он сталкиваетсЯ с неприемлемо высокой стоимостью,
есть два выхода: сократить проект или воздействовать на стоимость, предлагаЯ
более дешевые  способы реализации. ‚торой способ  неизбежно вызывает эмоции,
ведь  архитектор оспаривает  то,  как строитель справлЯетсЯ со  своим делом.
—тобы успешно справитьсЯ с этим, архитектору необходимо:
     -  помнить,  что  ответственность  за  изобретательность и  творчество,
проЯвлЯемые при реализации, несет  строитель, поэтому архитектор предлагает,
а не требует;
     -  всегда  быть  готовым предложить  <i>некоторый</i> способ  реализации своих
замыслов и  быть готовым согласитьсЯ с  любым  другим  способом, позволЯющим
решить задачу не хуже;
     - выдвигаЯ такие предложениЯ, действовать без шума и огласки;
     - не рассчитывать на признательность за сделанные предложениЯ.
     Ћбычно разработчик парирует предложением изменений в архитектуре. —асто
он прав  -  реализациЯ какой-нибудь малосущественной детали  может оказатьсЯ
неожиданно дорогостоЯщей.
     ‘амодисциплина - эффект второй системы
     Џервый проект архитектора стремитсЯ к скромности и Ясности. Ђрхитектор
понимает,  что  не знает,  чем занимаетсЯ,  поэтому  он  занимаетсЯ этим  со
старанием и самоограничением.
     Џри работе над первым проектом ему постоЯнно приходЯт в голову то одни,
то  другие  "украшениЯ".  Ћни  откладываютсЯ в сторону длЯ использованиЯ  "в
следующий раз". ‚ конце концов,  перваЯ система закончена,  и  архитектор, с
твердой уверенностью в  себе  и продемонстрированным освоением этого  класса
систем, готов к созданию нового проекта.
     ќта втораЯ система таит  наибольшие  опасности длЯ проектировщика.  Џри
работе над третьей и последующими  системами  закреплЯетсЯ  полученный ранее
опыт в  отношении  общих  характеристик таких систем, а  различиЯ между ними
выЯвлЯют те  части  опыта,  которые носЯт частный характер и  не могут  быть
обобщены.
     ЋбщаЯ тенденциЯ  заключаетсЯ в перегруженности проекта  второй  системы
идеЯми и украшательствами, благоразумно отложенными в сто