Страница 1 из 28
Брукс Фредерик
Мифический человеко-месяц
Фредерик П.Брукс
Мифический человеко-месяц
ОГЛАВЛЕНИЕ
THE MYTHICAL MAN-MONTH (ESSAYS ON SOFTWARE ENGINEERING)
I. АСФАЛЬТОВАЯ ТОПЬ
Комплексный программный продукт
Радости ремесла
Горести ремесла
II. МИФИЧЕСКИЙ ЧЕЛОВЕКО-МЕСЯЦ
Оптимизм
Человеко-месяц
Комплексная отладка
Объективность оценки
Нарастающие катастрофы с графиком
III. ХИРУРГИЧЕСКАЯ БРИГАДА
Предложение Миллза
IV. АРИСТОКРАТИЯ, ДЕМОКРАТИЯ И СИСТЕМНОЕ ПРОЕКТИРОВАНИЕ
Концептуальное единство
Как добиться концептуального единства
Аристократия и демократия
Чем может заполнить разработчик период ожидания?
V. ЭФФЕКТ ВТОРОЙ СИСТЕМЫ
Принципы совместной работы
Самодисциплина. Эффект второй системы
VI. ПУТЬ СЛОВА
Письменные спецификации - руководство
Формальные описания
Прямое внесение
Конференции и разбирательства
Совместные реализации
Журнал регистрации телефонных звонков
Проверка конечного продукта
VII. ПОЧЕМУ ОБРУШИЛАСЬ ВАВИЛОНСКАЯ БАШНЯ
Анализ Вавилонского проекта с точки зрения административного управления
Связь в больших программистских проектах
Рабочий документ проекта
Организация в больших программистских проектах
VIII. ОБЪЯВЛЕНИЕ ЦЕЛИ
Данные Портмана
Данные Арона
Данные Харра
Данные по OS/360
Данные Корбато
IX. ДЕСЯТЬ ФУНТОВ В ПЯТИФУНТОВОМ МЕШКЕ
Размер программы как стоимость
Контроль за размерами программ
Методы экономии памяти
Представление данных - сущность программирования
X. ДОКУМЕНТАЦИОННАЯ ГИПОТЕЗА
Документы для разработки ЭВМ
Документы для факультета университета
Документы для проекта программного обеспечения
Зачем нужны формальные документы?
XI. ПЛАН НА ВЫБРОС
Опытные установки и увеличение масштабов
Постоянны только изменения
Планирование изменений в системе
Планирование изменений в организации
Два шага вперед, шаг назад
Шаг вперед и шаг назад
XII. ОСТРЫЙ ИНСТРУМЕНТ
Целевые машины
Инструментальные машины и служба данных
Язык высокого уровня и диалоговое программирование
XIII. ЦЕЛОЕ ИЗ ЧАСТЕЙ
Проект без ошибок
Автономная отладка
Системная отладка
XIV. ПРИБЛИЖЕНИЕ КАТАСТРОФЫ
Вехи или помехи?
Сор в избе
XV. ВТОРОЕ ЛИЦО
Какая документация нужна?
Несостоятельность блок-схем
Самодокументированные программы
ЭПИЛОГ
ПРИМЕЧАНИЯ И ССЫЛКИ
I. АСФАЛЬТОВАЯ ТОПЬ
"Корабль на мели - моряку маяк".
(Датская пословица)
Ни одна из сцеп нашей предыстории не оставляет столь яркого впечатления, как смертельная схватка огромных животных с асфальтовой топью. Перед глазами встают динозавры, мамонты, саблезубые тигры, пытающиеся выбраться из топи. Однако чем отчаяннее борьба, тем сильнее сжимаются тиски, и как ни силен, как ни хитер зверь, в конце концов он погибает.
Программирование больших систем последние десять лет и было той асфальтовой топью, в которой увязли многие огромные и сильные звери. Почти все работающие системы не соответствовали своим спецификациям, своему назначению, не укладывались в графики и бюджет. Большие и маленькие, громоздкие и гибкие коллективы разработчиков неизбежно попадали в ловушку асфальтовой топи. Ничто, казалось, не вызывало затруднений - можно вытащить любую лапу. Однако накопление одновременных и взаимодействующих факторов приводило к замедлению движения.
Неподатливость проблемы вызывает всеобщее изумление, и разобраться в ее природе непросто. Но мы должны попытаться ее понять, чтобы впоследствии решить.
Начнем поэтому с определения ремесла системного программирования и присущих ему радостей и горестей.
Комплексный программный продукт
Время от времени в газетах можно прочесть о том, как два программиста в переоборудованном гараже написали очень важную программу, превосходящую лучшие образцы, созданные большими коллективами. И каждый программист готов поверить в эти басни, поскольку знарт, что может написать любую программу с гораздо большей скоростью, чем 1000 операторов в год, составляющие официальную производительность промышленных групп.
Но почему же тогда все производственные коллективы программистов не заменить малонаселенными гаражами? Давайте посмотрим, что именно там производится.
На рисунке, слева вверху изображена программа. Она полностью завершена, автор может ее пропустить в той системе, для которой она разработана. Именно это и создается обычно в гаражах, и этот объект используется для оценки производительности отдельного программиста.
Существуют два пути преобразования программы в более полезный, но и более дорогостоящий продукт. Они представлены на диаграмме вертикальной и гори-зоптп;г)>пон стрелками.
Двигаясь через горизонтальную грагпщу, протрпм-ма превращается в программный продукт, т. е. в такую программу, которую любой может пропускать на машине, отлаживать, улучшать и расширять. Она используется во многих рабочих контекстах и для многих наборов данных. Чтобы превратиться в универсально используемый программный продукт, программа должна быть написана неким универсальным образом. В частности, ввод должен быть настолько обобщен, насколько это позволяет основной алгоритм. Далее, программу следует тщательно отладить, учитывая все влияющие на нее факторы, А это означает, что следует подготовить, пропустить па машине и зафиксировать значительный массив отладочных тестов, изучив область ввода и установив его границы. И, наконец, превращение программы в программный продукт сопровождается тщательной документацией с тем, чтобы любой мог ее использовать и расширять. По моим приближенным подсчетам, программный продукт по крайней мере в три раза дороже, чем отлаженная программа с той же самой функцией.
Пересекая вертикальную границу, программа превращается в компоненту программного комплекса. Это набор взаимодействующих программ, согласованных по функциям и по формату так, что их объединение представляет собой единое средство для решения больших задач. Чтобы стать частью программного комплекса, программа должна быть написана так, чтобы каждый вход и выход по синтаксису и семантике соответствовал точно определенным сопряжениям. Кроме того, программа должна быть организована так, чтобы она использовала только отведенные ей ресурсы: объем памяти, устройства ввода/вывода, машинное время. И, наконец, программа должна быть отлажена во всех возможных сочетаниях с другими компонентами комплекса. Эта отладка должна быть очень большой по объему, ведь число вариантов растет комбинаторно. Она требует больших затрат времени, ибо появляются очень тонкие ошибки из-за непредвиденных взаимодействий отлаживаемых частей. Компонента программного комплекса стоит, по крайней мере, в три раза больше, чем отдельная программа с . той же функцией. Ее стоимость может быть выше, если система имеет много компонент.
В правом нижнем углу рисунка находится комплексный программный продукт. Он отличается от простой программы по всем вышеперечисленным пунктами стоит в девять раз больше, но это действительно полезный объект, конечный продукт всех усилий системного программиста.
Радости ремесла
Почему программирование доставляет удовольствие? Как вознаграждаются все усилия профессионала?
Первое - это абсолютная радость творчества. Как ребенок радуется, стряпая пирожки из песка, так взрослый наслаждается процессом создания вещей, особенно если он сам их придумал. Мне кажется, что прообразом этой радости творчества должно быть то удовольствие, с которым всевышний занимался сотворением мира и которое нашло свое отражение в оригинальности и красоте каждого листика, каждой снежинки.