Привет, Хаброжители! Немногие книги по управлению проектами можно назвать столь же значимыми как «Мифический человеко-месяц». Смешение примеров из реальной разработки ПО, мнений и размышлений создает яркую картину управления сложными проектами. Эти эссе основаны на пятидесятилетнем опыте работы Брукса менеджером проектов в IBM System/360, а затем в OS/360. Первое издание книги вышло 45 лет назад, второе 25 лет назад. Возникают новые методологии, появляются новые языки программирования, растет количество процессоров, но эта книга продолжает оставаться актуальной. Почему? Спустя полвека мы продолжаем повторять ошибки, которые описал Брукс. Некоторые темы, поднимаемые в книге, кажутся устаревшими, но это лишь видимость. Фундаментальные проблемы, стоящие за ними, все так же актуальны в наше время. Важно знать свое прошлое, чтобы понимать, куда развивается индустрия разработки программного обеспечения. Поэтому, спустя 45 лет мы и читаем Брукса Многое изменилось в мире, но девять женщин всё так же не могут выносить ребенка за один месяц.

Отрывок. Аристократия, демократия и системный дизайн

Эта величественная церковь является выдающимся произведением искусства. В тех догматах, которые она проявляет, нет ни сухости, ни путаницы…

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

Несомненно, замысел общего плана сооружения принадлежит Жану д'Орбе, который был уважаем, по крайней мере в его существенных элементах, его преемниками. Это одна из причин чрезвычайной согласованности и единства здания.

Путеводитель по Реймскому собору

Концептуальная целостность

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

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

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

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

— Как достичь концептуальной целостности?

— Не является ли этот аргумент оправданием для элитарности или аристократизма архитекторов перед ордой плебеев имплементаторов, чьи творческие таланты и идеи подавляются?

— Как удержать архитекторов от дрейфа в голубую даль с неимплементируемыми или дорогостоящими спецификациями?

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

Достижение концептуальной целостности

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

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

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

Однако для заданного уровня функциональности лучше всего подходит та система, в которой можно специфицировать вещи с наибольшей простотой и прямолинейностью. Одной простоты недостаточно. Языки TRAC Муерса (Mooers) и Algol 68 достигают простоты, измеряемой числом отдельных элементарных понятий. Непосредственность, однако, не характерна для них. Чтобы выразить свои намерения, часто требуется сочетать базовые средства сложным и неожиданным образом. Недостаточно изучить элементы и правила их сочетания; нужно также изучить идиоматическое употребление, усвоить целый свод знаний о том, как элементы сочетаются в реальности. Простота и прямолинейность проистекают из концептуальной целостности. Каждая часть должна отражать одну и ту же философию и одно и то же уравновешивание пожеланий. Каждая часть должна использовать даже одну и ту же методику в синтаксисе и аналогичные понятия в семантике. Таким образом, простота использования диктует единство дизайна, концептуальную целостность.

Аристократия и демократия

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

Отделение архитектурных усилий от имплементации является мощным способом получения концептуальной целостности в крупных проектах. Я сам видел, как он с большим успехом используется на продуктовой линейке компьютеров IBM Stretch и System/360. И я был свидетелем, как он не сработал при разработке Operating System/360, поскольку недостаточно применялся.

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

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

Архитектура должна четко отличаться от имплементации. Как отметил Блааув (Blaauw): «Там, где архитектура говорит о том, что происходит, имплементация говорит о том, как это сделано, чтобы оно произошло». В качестве простого примера он приводит часы, архитектура которых состоит из циферблата, стрелок и головки. Когда ребенок усвоит эту архитектуру, он с одинаковой легкостью сможет определять время как по наручным часам, так и по часам на церковной башне. Имплементация же и его реализация описывают, что происходит внутри: передача усилий и управление точностью каждым из многих механизмов.

Например, в System/360 отдельная компьютерная архитектура имплементирована совершенно по-разному в каждой из девяти моделей. В свою очередь, отдельная имплементация, поток данных, память и микрокод системы Model 30 в разное время служит для четырех разных архитектур: компьютера System/360, мультиплексного канала с 224 логически независимыми подканалами, селекторного канала и компьютера 1401.

То же самое различие в равной степени применимо и к системам программирования. В США принят стандарт Fortran IV. Он является архитектурой для многих компиляторов. В рамках этой архитектуры возможны разные реализации: текст в оперативной памяти или компилятор, быстрая или оптимизирующая, синтаксическая или ситуативная (ad hoc). Точно так же любой ассемблерный язык или язык управления заданиями допускает многие имплементации ассемблера или планировщика. Теперь мы можем заняться глубоко эмоциональным вопросом аристократии и демократии. Не являются ли архитекторы новой аристократией, интеллектуальной элитой, поставленной для того, чтобы указывать бедным безмозглым имплементаторам, что им делать? Не захватила ли эта элита всю творческую деятельность, сделав исполнителей лишь винтиками в механизме? Разве нельзя получить более качественный продукт, внедряя хорошие идеи от всей команды, следуя демократической философии, вместо того чтобы ограничивать разработку спецификаций несколькими избранными?

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

Что касается обвинения в аристократизме, то ответ должен быть и «да», и «нет». Да в том смысле, что архитекторов должно быть немного, их продукт должен выстоять дольше, чем продукт имплементатора, и архитектор находится в центре сил, которые он должен, в конечном счете, направить в интересах пользователя. Если система должна обладать концептуальной целостностью, то руководство концепциями должен взять кто-то один. Это аристократизм, который не нуждается в извинениях.

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

Существует много примеров из области искусств и ремесел, которые заставляют верить, что дисциплина совершенствует мастерство. И действительно, в афоризме художника утверждается: «форма освобождает». Худшие сооружения — это те, чей бюджет был слишком велик для обслуживаемых целей. Творческая деятельность Баха едва ли подавлялась необходимостью еженедельно выпускать ограниченную по форме кантату. Уверен, что компьютер Stretch имел бы более оптимальную архитектуру, если бы он был жестче ограничен; ограничения, налагаемые бюджетом машины System/360 Model 30, по моему мнению, были во всем благотворны для архитектуры Model 75.

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

Этот эффект, который я видел много раз, подтверждается Р. В. Конвеем (R. W. Conway), чья группа в Корнелле построила компилятор PL/C для языка PL/1. Он отмечает следующее: «В итоге мы решили реализовать язык без изменений и усовершенствований, поскольку обсуждение языка отняло бы у нас все силы».

Чем заняться имплементатору во время ожидания?

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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


» Более подробно с книгой можно ознакомиться на сайте издательства
» Оглавление
» Отрывок

Для Хаброжителей скидка 25% по купону — Брукс

По факту оплаты бумажной версии книги на e-mail высылается электронная книга.