Фредерик П. Брукс
| Вид материала | Документы |
- Французский писатель, журналист и критик Фредерик Бегбедер, 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.
Глава 17. Новый выстрел "Серебряной пули нет"
У всякой пули - своепредназначение.
ВИЛЬГЕЛЬМ III ОРАНСКИЙ
Кто хочет увидеть образец совершенства,
Тот мечтает о том, чего никогда не было,
нет и не будет.
АЛЕКСАНДР ПОП, "О КРИТИКЕ"
Об оборотнях и прочих мифических ужасах
"Серебряной пули нет: сущность и акциденция в программной инженерии"(глава 16 данной книги) первоначально была заказным докладом для конференцииIFIP (Международной федерации по обработки информации) 1986 года в Дублине ибыла опубликована в ее трудах.1 Журнал "Computer" перепечатал ее подобложкой в готическом стиле, иллюстрируя кадрами из фильмов, таких как"Вервольф из Лондона",2 и снабдив боковым полем "Убить вервольфа" сизложением современной легенды о том, что справиться с ним можно только спомощью серебряной пули. До публикации я не знал об иллюстрациях, и для менябыло неожиданностью, что серьезная техническая статья была так красочноиздана.
Однако редакторы "Computer" знали свое дело и достигли желаемогорезультата: похоже, что статью прочли многие. Поэтому я подобрал для тойглавы еще одну картинку с оборотнем - старинное изображение почти забавногосоздания. Надеюсь, что эта менее яркая картинка окажет такое же полезноедействие.
Серебряная пуля все-таки есть - ВОТ ОНА!
"Серебряной пули нет" утверждает и доказывает, что в течениедесятилетия (с момента публикации статьи в 1986 году) ни одна разработка вобласти техники программного обеспечения не позволит повыситьпроизводительность труда в программировании на порядок. Из этого десятилетияпрошло уже девять лет, и можно посмотреть, насколько сбывается предсказание.
В то время как "Мифический человеко-месяц" породил частое цитирование имало споров, статья "Серебряной пули нет" вызвала статьи с опровержениями иписьма в редакции журналов, поток которых не прекратился и по сей день.3Чаще всего критикуется главное утверждение о том, что волшебного решениянет, и мое ясно выраженное мнение о том, что его и быть не может.Большинство соглашается с основной частью моих аргументов в "СПН", но затемзаявляет, что в действительности серебряная пуля для программного зверясуществует, и изобрел ее автор. Перечитывая сегодня ранние отклики, не могуне отметить, что патентованные средства, столь энергично предлагавшиеся в1986 и 1987 годах, не возымели эффекта, на который претендовали.
Я обычно покупаю компьютеры и программы, проверяя их на "счастливомобладателе", т.е. беседуя с вызывающими доверие людьми, заплатившими деньгиза продукт и пользующимися им с удовольствием. Аналогично, я с готовностьюповерю в материализацию серебряной пули, когда вызывающий довериенезависимый пользователь выступит вперед и скажет: "Я использовал этуметодологию, этот инструмент или продукт, и это позволило мне в десять разповысить производительность разработки программ".
Многие корреспонденты сделали верные поправки и разъяснения. Некоторыепроанализировали статью пункт за пунктом и привели возражения, за что я имблагодарен. В этой главе я хочу сообщить о сделанных поправках и ответить наопровержения.
Неясное изложение влечет непонимание
Судя по некоторым откликам, мне не удалось четко изложить своиаргументы.
Второстепенное свойство (accident). В резюме главы 16 я постарался совсей возможной ясностью изложить основные аргументы "СПН". Некоторые,однако, были смущены терминами второстепенное свойство (accident) инесущественный, второстепенный (accidental), которые я использовал в старомупотреблении, восходящем к Аристотелю.4 Под accidental я не имел в виду"случайный" или "относящийся к несчастному случаю", а скорее,"несущественный", "побочный" (incidental) или "принадлежащий" (appurtinent).
Я не хочу порочить роль случайности при разработке программ. Вслед заанглийским драматургом, автором детективов и теологом Дороти Сэйерс (DorothySayers) я рассматриваю всякую творческую деятельность, как состоящую из: а)формулирования концептуальных конструкций, б) воплощения в реальномматериале и в) диалога с пользователем в реальной жизни.5 Та частьпостроения программы, которую я назвал сущностью (essence), состоит изумственной работы создания концепутальной конструкции, а та, которую яназвал второстепенной (accident), есть процесс ее воплощения.
Выяснение истины. Мне кажется (хотя не все со мной согласны), чтоверность центрального аргумента сводится к выяснению ответа на вопрос: какаядоля затрат связана с точным и упорядоченным представлением концептуальнойконструкции, а какая - с умственными усилиями по изготовлению этихконструкций. Поиск и устранение ошибок попадают в тот или иной раздел взависимости от того, являются ли ошибки концептуальными (например, пропусккакого-либо особого случая) или ошибками представления (например, ошибка вуказателе или распределения памяти).
Мое личное мнение состоит в том, что второстепенная или направленная напредставление часть работы сейчас снизилась до половины или менее того отобщего объема. Поскольку эта доля является экспериментальной величиной, еезначение, в принципе, можно получить путем измерений.5 Если это не удается,мою оценку можно поправить на основе более полных и более современныхданных, но ни в публичных, ни в частных заявлениях никто не утверждал, чтонеосновная часть достигает величины 9/10.
"СПН" с несомненностью доказывает, что если доля неосновной частиработы меньше 9/10, то даже сведя ее к нулю (что было бы чудом), нельзяполучить рост продуктивности на порядок. Атаку необходимо нацелить насущественную часть.
После появления "СПН" Брюс Блум (Bruce Blum) обратил мое внимание наработу 1959 года Герцберга, Мознера и Зейдермана (Herzberg, Mausner,Sayderman).7 Они находят, что факторы мотивации могут увеличитьпроизводительность. С другой стороны, факторы окружения и второстепенныефакторы, сколь бы они ни были положительны, не могут этого сделать, но,будучи отрицательными, могут уменьшить производительность. В "СПН"доказывается, что значительная часть прогресса в программной инженериидостигнута за счет устранения влияния следующих отрицательных факторов:крайне неудобных машинных языков, пакетной обработки с долгойоборачиваемостью, слабого инструментария и строгих ограничений на размерпамяти.
Являются ли в таком случае безнадежными трудности, связанные ссущностью? Отличная работа "Серебряная пуля есть", написанная Бредом Коксом(Bred Cox) в 1990 году, красноречиво доказывает, что многократноиспользуемые и взаимозаменяемые компоненты должны послужить основой дляатаки на концептуальную сущность проблемы.8 Я охотно соглашаюсь.
Однако Кокс неправильно понимает "СПН" в двух отношениях. Во-первых, оннаходит в ней утверждение того, что трудности разработки программногообеспечения проистекают из "некоторых порогов технологий, использовавшихсяпрограммистами в то время". Я же доказывал, что трудности, связанные ссущностью, являются неотъемлемой частью концептуальной сложностиразрабатываемых программных функций во все времена и при любых методах. Во-вторых, он и многие другие прочли в "СПН" утверждение того, что нет никакихнадежд успешно справиться со сложностями разработки программ, связанными свопросами сущности. Это не то, что я имел в виду. Создание концептуальнойконструкции действительно имеет внутренне присущие трудности, такие каксложность, согласованность, изменяемость и незримость. Однако неприятности,вызываемые всеми этими трудностями, можно уменьшить.
Сложность разделения на уровни. Например, наиболее серьезной внутреннейтрудностью является сложность, но она не всегда неизбежна. Значительнаячасть (но не вся) концептуальной сложности в наших программных конструкцияхпроистекает от произвольной сложности самих применений. Действительно, ЛарсСедаль из MYSYGMA Sohdal and Partners, международной консалтинговой фирмы вобласти менеджмента, пишет:
Мой опыт показывает, что все сложности, с которыми сталкиваются приразработке систем, являются признаками организационных неполадок. Попыткамоделирования практической деятельности программами соответствующейсложности влечет сохранение неразберихи вместо решения проблем.
Стив Лукашик (Steve Lukasik) из Northrop доказывает, что дажеорганизационная сложность, возможно, не является произвольной, а можетиспытывать воздействие принципов упорядочения:
Я получил образование в облати физики и поэтому вижу, что "сложные"вещи могут быть описаны на языке более простых понятий. Вы можете бытьправы, и я не стану утверждать, что все сложные вещи поддаются принципамупорядочения... по тем же правилам доказательства нельзя утверждать, что неподдаются.
То, что вчера было сложностью, завтра будет в порядке вещей.Сложность беспорядочного движения молекул привела к возникновениюкинетической теории газов и открытию трех законов термодинамики. Сейчаспрограммное обеспечение не позволяет увидеть присущие ему принципыупорядочения, но вы как раз и должны объяснить, почему это происходит. Этоне проявление моей бестолковости или желания поспорить. Я убежден, что водин прекрасный день "сложность" программного обеспечения будет объяснена наязыке каких- нибудь понятий более высокого порядка (инвариантов, как говорятфизики).
Я не занимался более глубоким анализом, к которому справедливопризывает Лукашик. Как отрасль науки мы нуждаемся в развитии теорииинформации для количественной оценки информационного содержаниястатистических структур, подобно тому, как теория Шэннона делает это дляинформационных потоков. Это совсем не моя задача. Лукашику я просто отвечу,что сложность системы является функцией мириадов деталей, каждая из которыхдолжна быть точно задана либо с помощью какого-нибудь общего правила, либоподробным описанием, но не просто статистически. Представляется весьмасомнительным, чтобы несогласованные результаты работы многих голов оказалисьдостаточно связными, чтобы быть точно описанными общими правилами.
Значительно большая часть сложности программных конструкцийобусловлена, однако, не соответствием внешнему миру, а самой реализацией -структурами данных, алгоритмами, способами коммуникаций. Наращиваниепрограмм с помощью больших блоков высокого уровня, созданных когда-то раньшеили кем-то другим, помогает избежать целых уровней сложности. "СПН"провозглашает поход на проблему сложности в полной надежде, что можнодостичь прогресса. Она выступает за добавление к программной системенеобходимой сложности:
- иерархически, располагая модули или объекты по уровням;
- пошагово, что обеспечивает постоянную работоспособность системы.