Фредерик П. Брукс
| Вид материала | Документы |
- Французский писатель, журналист и критик Фредерик Бегбедер, 1495.8kb.
- Фредерик Коплстон История философии. XX век Номер страницы указан в конце страницы, 2537.19kb.
- Gold Circle Films представляют фильм компании Integrated Films. О фильме история США, 1307.29kb.
- Брукс Кубик "Тренинг Динозавров. Забытые секреты силы и развития тела", 3174.72kb.
- 2. Во всем мире родоначальником научных основ организации производства признан: ◙ Фредерик, 992.99kb.
- Фредерик Бегбедер, 2049.29kb.
- Фредерик Бегбедер. 99 франков, 2045.96kb.
- Фредерик К. Хэтфилд всестороннее руководство по развитию силы , 4595.97kb.
- Фредерик Бегбедер. 99 Франков, 2399.26kb.
- Практикум по гештальттерапии петербург, 5899.47kb.
Глава 19 "Мифический человеко-месяц" двадцать лет спустя
Я не знаюдругого способа судить о будущем, как с помощью прошлого.
ПАТРИК ГЕНРИ
Опираясь на прошлое, невозможно планировать будущее.
ЭДМУНД БЕРК
Для чего понадобилось юбилейное двадцатое издание?
Самолет гудел в ночи, направляясь к Лагардии. Облака и сумрак скрыливсе интересное для глаза. Документ, который я читал, был неинтересным.Однако мне не было скучно. Сидящий рядом попутчик читал "Мифическийчеловеко-месяц", и я ожидал, когда словом или жестом он выдаст своевпечатление. В конце концов, когда мы уже выруливали к выходу, я невыдержал:
- Как вам эта книга? Советуете прочесть?
- Хм, в ней нет ничего, чего я не знал бы раньше.
Я решил не представляться.
Почему "Мифический человеко-месяц" выжил? Почему с ним до сих порсчитаются в современной практике программирования? Почему его читательскаяаудитория выходит за пределы сообщества программистов-разработчиков, а книгапорождает статьи, цитаты и письма не только разработчиков программ, но июристов, врачей, психологов, социологов? Каким образом книга, написанная 20лет назад об опыте разработки программ, имевшем место 30 лет назад, может досих пор быть актуальной и даже полезной?
Согласно одному из объяснений, которые можно услышать, разработкапрограммного обеспечения как дисциплина не получила нормального иправильного развития. В поддержку этой точки зрения часто указывают нанесоответствие роста производительности труда программистов и эффективностипроизводства компьютеров, выросшей в тысячи раз за последние двадесятилетия. Как объясняется в главе 16, аномалия состоит не в замедленномразвитии программирования, а в беспрецедентном в истории человечества взрывекомпьютерных технологий. В целом, причина этого в постепенном переходепроизводства компьютеров из сборочного производства в обрабатывающее, изтрудоемкого производства в капиталоемкое. Разработка же аппаратного ипрограммного обеспечения, в отличие от производства, остается по своей сутитрудоемкой.
Второе часто выдвигаемое объяснение гласит, что "Мифическийчеловеко-месяц" лишь случайно касается разработки программного обеспечения,а в основном он написан о групповой разработке чего бы то ни было. Доляправды в этом есть. В предисловии к изданию 1975 года сказано, чтоуправление программным проектом имеет больше сходства с любым другимуправлением, чем изначально считается большинством программистов. Я до сихпор так считаю. История человечества - это пьеса, в которой сюжетыпостоянны, сценарии медленно меняются с развитием культуры, а декорациименяются непрерывно. Поэтому в ХХ веке мы узнаем себя в Шекспире, Гомере иБиблии. Поэтому в той мере, в какой "МЧ-М" написан о людях, он устареваетмедленно.
Каковы бы ни были причины, книгу продолжают покупать и присылают мнезамечания, которые я ценю. Меня часто спрашивают: "Как вы считаете, в чем вытогда ошиблись? Что устарело в наши дни? Что действительно новое появилось вмире разработки программ?" Эти четкие вопросы вполне законны, и я постараюсьответить на них. Не в таком, правда, порядке, но по группам тем. Преждевсего, посмотрим, что было верным в момент написания и осталось таковым досих пор.
Центральный аргумент: концептуальная целостность и архитектор
Концептуальная целостность. Чистый и элегантный программный продуктдолжен представить своим пользователям согласованную идеальную модельприложения, стратегий осуществления приложения и тактики пользовательскихинтерфейсов, используемой при задании действий и параметров. Концептуальнаяцелостность продукта в восприятии пользователя является важнейшим фактором,влияющим на простоту использования. (Есть, конечно, и другие факторы. Важнымпримером является единообразие пользовательского интерфейса в приложенияхдля Macintosh. Более того, можно создать согласованные интерфейсы,являющиеся тем не менее, совершенно неуклюжими. Например MS-DOS.)
Есть многочисленные примеры элегантных программных продуктов, созданныходним или двумя людьми. Так делается большая часть чисто интеллектуальныхпродуктов, таких как книги или музыкальные произведения. Однако во многихпромышленных областях процессы разработки продукта не могут осуществлятьсяна основе столь простого подхода к концептуальной целостности. Конкуренциявынуждает к спешке. Во многих современных технологиях конечный продуктобладает большой сложностью, и проектирование неизбежно требует многихчеловеко-месяцев труда. Для программных продуктов характерны как сложность,так и напряженность графика, обусловленная конкуренцией.
Таким образом, всякий достаточно большой или срочный продукт, требующийусилий многих людей, сталкивается со специфической трудностью: результатдолжен концептуально согласовываться с разумом одиночного пользователя и вто же время проектироваться усилиями нескольких разумов. Как организоватьпроектирование, чтобы достичь такой концептуальной целостности? Этоцентральный вопрос "МЧ-М". Один из его тезисов гласит, что существуюткачественные различия между управлением большими и маленькими программнымипроектами - лишь в силу числа работающих над ними голов. Для достижениясогласованности необходимы обдуманные и даже героические действия.
Архитектор. С четвертой по шестую главу я доказываю, что самое важное -назначить одного человека архитектором продукта, ответственным за все егостороны, воспринимаемые пользователем. Архитектор формирует и имеет в своемвладении общедоступную идеальную модель продукта, с помощью которойпользователю будет объяснено его применение. В ее состав входит подробноеуказание всех его функций и средств вызова и управления. Архитектор такжедействует в интересах пользователя при поиске компромисса между функциями,техническим характеристиками, размером, стоимостью и выполнением графикаработ. Выполнение этой задачи требует полной занятости, и только в оченьмаленьких группах может быть совмещено с должностью руководителя.Архитектора можно сравнивать с режиссером, а менеджера - с продюсеромкинокартины.
Отделение архитектуры от разработки и реализации. Чтобы сделатьвозможным осуществление архитектором своей главной задачи, необходимоотделить архитектуру, т.е. определение продукта в восприятии пользователя,от его разработки. Архитектура и разработка определяют четкую грань междуразными частями задачи проектирования, и по каждую сторону этой грани лежитбольшая работа.
Рекурсивность архитектуры. В очень больших проектах одному человеку несправиться со всей архитектурой, даже если он избавлен от всех забот,связанных с разработкой. Поэтому главный архитектор системы должен разбитьцелое на подсистемы. Границы подсистем должны быть проведены так, чтобыинтерфейсы между ними были минимальны и легче всего строго определяемы.Тогда у каждой части может быть свой архитектор, подчиняющийся главномуархитектору системы в отношении архитектуры. Очевидно, при необходимостиэтот процесс может быть продолжен рекурсивно.
Сегодня я убежден более чем когда-либо. Концептуальная целостностьявляется важнейшим условием качества продукта. Наличие системногоархитектора есть важнейший шаг в направлении концептуальной целостности. Этипринципы ни в коей мере не ограничиваются разработкой программногообеспечения, а справедливы при проектировании любой сложной конструкции,будь то компьютер, самолет, стратегическая оборонная инициатива или системаглобальной навигации. После преподавания в более чем 20 лабораторияхразработки программного обеспечения я стал настаивать, чтобы группыучащихся, даже из четырех человек, выбирали менеджера и отдельно -архитектора. Разделение функций в таких маленьких группах может показатьсянесколько чрезмерным требованием, но, по моим наблюдениям, это оправдано испособствует достижению успеха.