Frederick P. Brooks, Jr. The Mythical Man Month
THE MYTHICAL MAN-MONTH
(Essays on Software Engineering)
ADDISON-WESLEY PUBLISHING
COMPANY
READING
i 97 5
Copyright © 1975 by Acldison-Wesley Publishing Company, Inc. Philippines; Copyright 1975 by Addison-Wesley Publishing Company, Inc. Copvrisht © 1972 by Frederick P. Brooks, Jr.
ОГЛАВЛЕНИЕ
THE MYTHICAL MAN-MONTH
(Essays on Software Engineering) 1
I. АСФАЛЬТОВАЯ ТОПЬ 4
Комплексный программный продукт 4
Радости ремесла 5
Горести ремесла 5
II. МИФИЧЕСКИЙ ЧЕЛОВЕКО-МЕСЯЦ 7
Оптимизм 7
Человеко-месяц 8
Комплексная отладка 9
Объективность оценки 9
Нарастающие катастрофы с графиком 10
III. ХИРУРГИЧЕСКАЯ БРИГАДА 12
Предложение Миллза 13
IV. АРИСТОКРАТИЯ, ДЕМОКРАТИЯ И СИСТЕМНОЕ ПРОЕКТИРОВАНИЕ 16
Концептуальное единство 16
Как добиться концептуального единства 16
Аристократия и демократия 17
Чем может заполнить разработчик период ожидания? 18
V. ЭФФЕКТ ВТОРОЙ СИСТЕМЫ 20
Принципы совместной работы 20
Самодисциплина. Эффект второй системы 20
VI. ПУТЬ СЛОВА 23
Письменные спецификации — руководство 23
Формальные описания 23
Прямое внесение 24
Конференции и разбирательства 25
Совместные реализации 25
Журнал регистрации телефонных звонков 26
Проверка конечного продукта 26
VII. ПОЧЕМУ ОБРУШИЛАСЬ ВАВИЛОНСКАЯ БАШНЯ 27
Анализ Вавилонского проекта с точки зрения административного управления 27
Связь в больших программистских проектах 27
Рабочий документ проекта 28
Организация в больших программистских проектах 29
VIII. ОБЪЯВЛЕНИЕ ЦЕЛИ 32
Данные Портмана 32
Данные Арона 33
Данные Харра 33
Данные по OS/360 34
Данные Корбато 34
IX. ДЕСЯТЬ ФУНТОВ В ПЯТИФУНТОВОМ МЕШКЕ 36
Размер программы как стоимость 36
Контроль за размерами программ 36
Методы экономии памяти 37
Представление данных — сущность программирования 38
X. ДОКУМЕНТАЦИОННАЯ ГИПОТЕЗА 39
Документы для разработки ЭВМ 39
Документы для факультета университета 40
Документы для проекта программного обеспечения 40
Зачем нужны формальные документы? 40
XI. ПЛАН НА ВЫБРОС 42
Опытные установки и увеличение масштабов 42
Постоянны только изменения 42
Планирование изменений в системе 42
Планирование изменений в организации 43
Два шага вперед, шаг назад 44
Шаг вперед и шаг назад 45
XII. ОСТРЫЙ ИНСТРУМЕНТ 46
Целевые машины 46
Инструментальные машины и служба данных 47
Язык высокого уровня и диалоговое программирование 48
XIII. ЦЕЛОЕ ИЗ ЧАСТЕЙ 51
Проект без ошибок 51
Автономная отладка 52
Системная отладка 53
XIV. ПРИБЛИЖЕНИЕ КАТАСТРОФЫ 57
Вехи или помехи? 57
Сор в избе 58
XV. ВТОРОЕ ЛИЦО 62
Какая документация нужна? 62
Несостоятельность блок-схем 63
Самодокументированные программы 65
ЭПИЛОГ 69
ПРИМЕЧАНИЯ И ССЫЛКИ 70
I. АСФАЛЬТОВАЯ ТОПЬ
«Корабль на мели — моряку маяк».
(Датская пословица)
Ни одна из сцеп нашей предыстории не оставляет столь яркого впечатления, как смертельная схватка огромных животных с асфальтовой топью. Перед глазами встают динозавры, мамонты, саблезубые тигры, пытающиеся выбраться из топи. Однако чем отчаяннее борьба, тем сильнее сжимаются тиски, и как ни силен, как ни хитер зверь, в конце концов он погибает.
Программирование больших систем последние десять лет и было той асфальтовой топью, в которой увязли многие огромные и сильные звери. Почти все работающие системы не соответствовали своим спецификациям, своему назначению, не укладывались в графики и бюджет. Большие и маленькие, громоздкие и гибкие коллективы разработчиков неизбежно попадали в ловушку асфальтовой топи. Ничто, казалось, не вызывало затруднений — можно вытащить любую лапу. Однако накопление одновременных и взаимодействующих факторов приводило к замедлению движения.
Неподатливость проблемы вызывает всеобщее изумление, и разобраться в ее природе непросто. Но мы должны попытаться ее понять, чтобы впоследствии решить.
Начнем поэтому с определения ремесла системного программирования и присущих ему радостей и горестей.
Комплексный программный продукт
Время от времени в газетах можно прочесть о том, как два программиста в переоборудованном гараже написали очень важную программу, превосходящую лучшие образцы, созданные большими коллективами. И каждый программист готов поверить в эти басни, поскольку знарт, что может написать любую программу с гораздо большей скоростью, чем 1000 операторов в год, составляющие официальную производительность промышленных групп.
Но почему же тогда все производственные коллективы программистов не заменить малонаселенными гаражами? Давайте посмотрим, что именно там производится.
Н а рисунке, слева вверху изображена программа. Она полностью завершена, автор может ее пропустить в той системе, для которой она разработана. Именно это и создается обычно в гаражах, и этот объект используется для оценки производительности отдельного программиста.
Существуют два пути преобразования программы в более полезный, но и более дорогостоящий продукт. Они представлены на диаграмме вертикальной и гори-зоптп;г)>пон стрелками.
Двигаясь через горизонтальную грагпщу, протрпм-ма превращается в программный продукт, т. е. в такую программу, которую любой может пропускать на машине, отлаживать, улучшать и расширять. Она используется во многих рабочих контекстах и для многих наборов данных. Чтобы превратиться в универсально используемый программный продукт, программа должна быть написана неким универсальным образом. В частности, ввод должен быть настолько обобщен, насколько это позволяет основной алгоритм. Далее, программу следует тщательно отладить, учитывая все влияющие на нее факторы, А это означает, что следует подготовить, пропустить па машине и зафиксировать значительный массив отладочных тестов, изучив область ввода и установив его границы. И, наконец, превращение программы в программный продукт сопровождается тщательной документацией с тем, чтобы любой мог ее использовать и расширять. По моим приближенным подсчетам, программный продукт по крайней мере в три раза дороже, чем отлаженная программа с той же самой функцией.
Пересекая вертикальную границу, программа превращается в компоненту программного комплекса. Это набор взаимодействующих программ, согласованных по функциям и по формату так, что их объединение представляет собой единое средство для решения больших задач. Чтобы стать частью программного комплекса, программа должна быть написана так, чтобы каждый вход и выход по синтаксису и семантике соответствовал точно определенным сопряжениям. Кроме того, программа должна быть организована так, чтобы она использовала только отведенные ей ресурсы: объем памяти, устройства ввода/вывода, машинное время. И, наконец, программа должна быть отлажена во всех возможных сочетаниях с другими компонентами комплекса. Эта отладка должна быть очень большой по объему, ведь число вариантов растет комбинаторно. Она требует больших затрат времени, ибо появляются очень тонкие ошибки из-за непредвиденных взаимодействий отлаживаемых частей. Компонента программного комплекса стоит, по крайней мере, в три раза больше, чем отдельная программа с . той же функцией. Ее стоимость может быть выше, если система имеет много компонент.
В правом нижнем углу рисунка находится комплексный программный продукт. Он отличается от простой программы по всем вышеперечисленным пунктами стоит в девять раз больше, но это действительно полезный объект, конечный продукт всех усилий системного программиста.
Радости ремесла
Почему программирование доставляет удовольствие? Как вознаграждаются все усилия профессионала?
Первое — это абсолютная радость творчества. Как ребенок радуется, стряпая пирожки из песка, так взрослый наслаждается процессом создания вещей, особенно если он сам их придумал. Мне кажется, что прообразом этой радости творчества должно быть то удовольствие, с которым всевышний занимался сотворением мира и которое нашло свое отражение в оригинальности и красоте каждого листика, каждой снежинки.
Второе — это радость создания вещей, полезных другим людям. Где-то в глубине души мы хотим, чтобы другие использовали нашу работу и находили ее полезной. В, этом смысле продукт программирования не слишком отличается от первой детской подставки для карандашей «в подарок папе».
Третье — это очарование, заключенное в самом процессе создания сложных, загадочных объектов, состоящих из взаимосвязанных, непостоянных частей, и наблюдения за тем, как они работают в запутанных циклах, сохраняя верность принципам, заложенным в них с самого начала. Вычислительная машина обладает притягательной силой биллиарда или музыкального автомата, доведенных до логической завершенности.
Четвертое — это возможность постоянно учиться, вытекающая из непрерывно меняющегося характера задачи. В том или ином отношении проблема оказывается новой, и человек, ее решающий, приобретает новые знания, иногда теоретические, иногда практические, а иногда и те, и другие вместе.
И последнее — это удовольствие работать с очень гибким материалом. Программист, как поэт, работает почти исключительно головой. Он строит свои замки в воздухе и из воздуха только силой своего воображения. Очень редко материал для творчества допускает такую гибкость, такую возможность столь частых улучшений и переделок и такими простыми средствами позволяет осуществлять громадные замыслы. (Но, как мы увидим позднее, эта же самая гибкость порождает свои проблемы)
Материал поэта — слова, и результат — те же слова; в отличие от стихотворца, программист создает программный продукт, реальный в том смысле, что сам программист движется и работает, производя видимый результат, отличный от него самого. Он печатает результаты, чертит рисунки, производит звуки, управляет движением руки. Волшебство мифов и легенд стало явью в наши дни. Вы печатаете на клавиатуре заклинание, и вот экран дисплея оживает, показывая объекты, которых не было и могло не быть никогда.
Программирование доставляет нам радость, потому что позволяет удовлетворить стремление к творчеству, глубоко заложенное в каждом из нас, и разделить это чувство радости с другими.
Горести ремесла
Не все, однако, радует программиста, и знакомство с горестями, присущими нашему ремеслу, позволяет легче перенести их появление.
Во-первых, надо работать очень тщательно. В этом смысле ЭВМ тоже напоминает волшебство из сказок. Если хоть один символ, один пробел в магической формуле не находится строго на своем месте, волшебство не работает. Люди не привыкли к совершенству, и лишь немногие области человеческой деятельности требуют его. Привыкание к требованиям совершенной точности является, по моему мнению, наиболее трудным в процессе обучения программированию)1).
Во-вторькх, задачи, стоящие перед программистом, определяют другие люди, они же отводят ему ресурсы v. снабжают информацией. Один человек крайне редко слм определяет обстоятельства своей работы, не говоря уже о ее целях. В административных терминах это означает, что'степень ответственности превышает объем прав., Однако, по-видимому, во всех областях созидательной деятельности формальный объем прав никогда не согласуется с ответственностью. В действительности же фактический объем прав достигается как только работа завершена.
Зависимость от других проявляется здесь особо, весьма болезненно для системного программиста. Он зависит от чужих программ. В то же время эти программы зачастую неверно спроектированы, плохо .реализованы, не полностью укомплектованы (например, нет программы на входном языке пли нет тестов) п слабо документированы. Поэтому программисту приходится часами разбираться в таких вещах, которые в идеальном случае должны быть вполне завершены, доступны и легко используемы.
Следующее обстоятельство сводится к тому, что приятно выдавать большие идеи, но какой же поистине «адский труд» — иногда поиск самой крошечной ошибки! Любая творческая деятельность подразумевает долгие часы кропотливого и скучного труда, и программирование в этом смысле — отнюдь не исключение.
П, далее, могло бы показаться, что чем меньше ошибок в программе, тем легче их найти, т. е. скорость отладки как бы обладает квадратичной сходимостью. Совсем наоборот — сходимость оказывается линешюп или хуже, т.- е. в ходе отладки обнаружение последних ошибок требует гораздо больше времени, чем первых.
Последняя неприятность, а иногда и последнее разочарование заключается в том, что продукт, над которым вы трудились так долго, к моменту завершения (или даже раньше) уже устарел. Всегда коллеги и соперники гоняются за новыми и лучшими идеями. И вот уже'замена выношенной вами идеи не только задумана, но и внесена в план.
Действительность, как правило, не так страшна. Новый и более совершенный продукт обычно еще не доступен к тому моменту, когда вы уже завершили свой собственный; о нем пока только говорят. И на его создание тоже потребуются долгие месяцы. Бумажный тигр не соперник реальному, если речь идет о действительном его использовании. Преимущества реальности всегда получают признание.
Конечно, техническая база, на которой все строится, постепенно идет вперед. Как только проект окончательно принят, он становится устаревшим в смысле своих концепций. По осуществление проекта, направленного на получение реального продукта, требует времени и труда. Степень отсталости реализованного проекта нужно измерять по сравнению с другими существующими реализациями, а не с еще нереализованными концепциями. Цель и задача состоят в том, чтобы йайти реальные решения реальных проблем в соответствии с существующими планами и наличными ресурсами.
Таково программирование — одновременно и асфальтовая топь, поглощающая многие начинания, и творческая деятельность с присущими только ей радостями и горестями. В глазах многих ее радости значительно перевешивают все горести, и именно для них эта книга попытается проложить отдельные тропки через топь.
|
