Фредерик П. Брукс

Вид материалаДокументы
Достижение концептуальной целостности
Аристократия и демократия
Подобный материал:
1   ...   5   6   7   8   9   10   11   12   ...   48

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


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

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

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

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

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

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


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

С другой стороны, напряженность графика требует привлечения большого числа работников. Есть два метода разрешения этой дилеммы. Первый состоит в тщательном разделении труда между архитектурой и исполнением. Второй – новый способ организации бригад программистов-исполнителей, обсуждавшийся в предыдущей главе. 31 Отделение разработки архитектуры от реализации является эффективным способом достижения концептуальной целостности при работе над очень большими проектами. Я лично был свидетелем успешного его применения при создании IBM компьютера Stretch и серии продуктов System/360. Но он несработал при разработке Operating System/360, поскольку недостаточно применялся.

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

Архитектор системы, как и архитектор здания, является представителем пользователя. Его задача - использовать все свои профессиональные и технические знания исключительно в интересах пользователя, а не продавца, изготовителя и т.п.2

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

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

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

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

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

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

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

Есть масса примеров, подсказанных другими искусствами и ремеслами, которые подводят к мнению, что дисциплина идет на пользу. Действительно, афоризм художника гласит, что "форма освобождает". Самые ужасные строения - это те, бюджет которых был слишком велик для поставленных целей. Творческую активность Баха едва ли могла подавлять необходимость еженедельная необходимость изготавливать кантату определенного вида. Я уверен, что архитектура компьютера Stretch стала бы лучше, если бы на нее наложили более жесткие ограничения; так, ограничения, наложенные бюджетом на System/360 Model 30, по моему мнению, принесли лишь пользу архитектуре Model 75.

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

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