Фредерик П. Брукс
| Вид материала | Документы |
- Французский писатель, журналист и критик Фредерик Бегбедер, 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.
Перспективные подходы к концептуальной сущности
Хотя никакой прорыв в технологии не обещает таких волшебныхрезультатов, какие мы видим в аппаратной части компьютеров, в настоящеевремя делается много полезного, и есть надежды на неуклонный, хотя инеброский прогресс.
Все технологические подходы к акциденциям процесса программированияпринципиально ограничены уравнением продуктивности:
Если, как я полагаю, концептуальные составляющие задачи сейчас отнимаютбольшую часть времени, то никакая работа над составными частями задачи,являющимися просто выражением концепций, не даст большого выигрыша.
Поэтому мы должны рассмотреть те направления, которые затрагивают самусущность проблемы программирования - формулировку этих сложныхконцептуальных структур. К счастью, некоторые из этих направлений весьмамногообещающи.
Покупать, а не создавать. Наиболее радикальное возможное решение присоздании программ - вообще не создавать их.
С каждым днем это становится все легче, поскольку все большее числопоставщиков предлагает все более многочисленные и лучшие программныепродукты для немыслимого разнообразия приложений. Пока мы,инженеры-программисты, трудились над совершенствованием методологиипроизводства, революция, произведенная персональными компьютерами, создалане один, а много массовых рынков программного обеспечения. В каждом газетномкиоске выставлены ежемесячные журналы, в которых, отсортированные по типаммашин, рекламируются и рецензируются десятки продуктов по ценам отнескольких долларов до нескольких сотен долларов. Более специализированныеиздания предлагают очень мощные продукты для рабочих станций и других рынковUnix. Даже инструменты и среды программирования могут быть куплены вкоробочном виде. Я где-то предложил базар для отдельных модулей.
Любой такой продукт дешевле купить, чем создавать заново. Даже при цене100 000 долларов купленный продукт стоит примерно столько, сколько годовоесодержание программиста. И поставка немедленная! Немедленная, по крайнеймере, для реально существующих продуктов, проспект которых разработчик можетпослать счастливому пользователю. Более того, такие продукты обычно гораздолучше документированы и несколько лучше сопровождаются, чем доморощенныепрограммы.
Развитие массового рынка является, по моему мнению, наиболее глубокойдолгосрочной тенденцией программной инженерии. Стоимость программногопродукта всегда определялась стоимостью разработки, а не тиражирования.Разделив эту стоимость даже на нескольких пользователей, мы коренным образомснижаем цену на одного пользователя. Взглянув на это с другой стороны, мывидим, что использование n копий программной системы фактически умножает наn производительность его разработчиков. Это рост производительности отраслии всей страны.
Главным вопросом, конечно, является производительность. Смогу ли яиспользовать имеющийся коробочный продукт для решения своих задач? Здесьслучилась удивительная вещь. В 50-х и 60-х годах одно исследование за другимпоказывало, что пользователи не хотят использовать коробочные пакеты длярасчета зарплаты, управления складом, учета дебиторов по расчетам и т.д.Требования были слишком специальными, отклонения от случая к случаю слишкомбольшими. В 80-х годах мы обнаруживаем большой спрос на такие пакеты иширокое их использование. Что изменилось?
Только не пакеты. Они стали несколько более общими и лучшенастраиваются, чем раньше, но не намного. И не область их применения. Вконце концов, сегодня потребности бизнеса и науки более разнообразны исложны, чем 20 лет назад.
Резко изменилось соотношение стоимости компьютеров и программ. Тот, ктов 1960 году покупал машину за 2 миллиона долларов, считал, что можетпозволить себе потратить еще 250 000 долларов на заказную программу расчетазарплаты, которая легко и без ущерба вписалась бы во враждебную компьютерамсоциальную среду. Те, кто сегодня покупают машину для офиса за 50 000долларов, не могут, понятно, позволить себе заказные программы расчетазарплаты, поэтому они приспосабливают свои процедуры расчета зарплаты кимеющимся пакетам. Компьютеры сейчас столь обычны, если не столь любимы, чтоадаптация воспринимается как обычное дело.
Есть яркие исключения из моего утверждения о том, что обобщенностьпрограммных пакетов за последние годы мало изменилась: электронные таблицы ипростые системы баз данных. Эти мощные инструменты, столь очевидные заднимумом и так поздно появившиеся, имеют бесчисленное множество применений, втом числе, весьма необычные. Есть масса статей и даже книг о том, как спомощью электронной таблицы решать неожиданные задачи. Большое число задач,для которых раньше были бы написаны заказные программы на Cobol или ReportProgram Generator, теперь шаблонно решается с помощью этих инструментов.
Многие пользователи изо дня в день применяют свои компьютеры для разныхприложений, никогда не написав ни одной программы. На практике многие изэтих пользователей и не могут писать для своих машин новые программы, но темне менее приверженцы решению возникающих задач с их помощью.
Я считаю, что сегодня для многих организаций самая правильная политикадля повышения производительности разработки программного обеспечения - этоустановить своим не имеющим компьютерных знаний работникам умственного трудакомпьютеры и хорошие общие программы для обработки текстов, рисования,работы с файлами и электронными таблицами и отпустить их в вольное плавание.Такая же политика в отношении распространенных математических истатистических пакетов, а также некоторых навыков программирования подойдетсотням ученых, работающих в лабораториях.
Уточнение требований и быстрое макетирование. Самая трудная отдельная задача в разработке программной системы - это точно решить, что разрабатывать. Ни одна другая задача работы над концепциями не является столь трудной, как разработка подробных технических требований, включая всеинтерфейсы пользователей, машинные интерфейсы и интерфейсы к другимпрограммным системам. Ни одна другая часть работы не наносит такого ущербаготовой системе, если сделана неправильно. Ни одна другая часть неисправляется позднее с бoльшим трудом.
Поэтому наиболее важной функцией, осуществляемой разработчиками длясвоих клиентов, является повторяющееся получение и уточнение требований кпродукту. Правда заключается в том, что клиенты не знают, чего хотят. Обычноони не знают, на какие вопросы нужно дать ответ, и почти никогда незадумывались над задачей настолько детально, как это нужно указать вспецификации. Даже простой ответ - "сделайте так, чтобы новая программнаясистема работала так, как наша старая ручная система обработки информации" -оказывается в действительности слишком упрощенным. Клиенты никогда не хотятэтого в точности. Более того, сложные программные системы действуют,движутся, работают. Динамику этого действия трудно себе представить. Поэтомупри планировании любых действий необходимо оставить резерв для многократноговзаимодействия между клиентом и проектировщиком при описании системы.
Я пойду дальше и стану утверждать, что на практике клиенты, даже вместес инженерами-программистами, не в состоянии указать полно, строго икорректно точные требования к современному программному продукту, прежде чембудут созданы и опробованы какие-либо версии продукта, спецификации ккоторому они составляют.
Поэтому одним из наиболее многообещающих современных направлений втехнологии, причем обращенных к сущности, а не к акциденциям проблемпрограммирования, является разработка подходов и инструментов для быстрогосоздания макетов систем как части итеративного процесса разработкиспецификаций.
Макет программной системы моделирует главные интерфейсы и выполняетосновные функции предполагаемой системы, при этом не обязательно будучисвязан теми же ограничениями быстродействия компьютера, размера илистоимости. Обычно макеты выполняют основные задачи системы, но не пытаютсяобрабатывать исключительные ситуации, правильно реагировать на вводнедопустимых данных, корректно прерывать работу и т.д. Назначение макета -показать, как воплощается выбранная концептуальная структура, чтобы клиентмог проверить ее пригодность к использованию и непротиворечивость.
Сегодня многие процедуры приобретения программного обеспеченияосновываются на предположении, что можно заранее задать техническиетребования для желаемой системы, рассмотреть предложения разработчиков,получить разработанную систему и установить ее. Я думаю, что такоепредположение в корне неверно, и из-за этой ошибки проистекают многиепроблемы при приобретении программ, поскольку эти проблемы нельзя устранитьбез пересмотра основ, для которого требуется интерактивная разработка испецификации макетов и продуктов.
Пошаговая обработка: наращивать программу, а не строить сразу. Я до сих пор помню испытанный в 1958 году удар, когда впервые услышал, как мой друг говорил о строительстве (building) программ в противоположность написанию(writing). В мгновение он расширил все мое представление о процессе программирования. Применение метафоры было сильным и точным. Сегодня мыпонимаем, что сходство существует между созданием программы и другимистроительными процессами, и свободно используем другие элементы метафоры,такие как спецификации (specifications), сборка компонентов (assembly ofcomponents), леса (scaffolding).
Метафора строительства пережила свое время. Пора снова вноситьизменения. Если, как я считаю, создаваемые сегодня концептуальные структурыслишком сложны, чтобы их можно было точно специфицировать заранее, и слишкомсложны, чтобы строить без ошибок, тогда нужен радикально иной подход.
Обратимся к природе и рассмотрим сложность живых созданий, а небезжизненных творений человека. Там мы обнаруживаем конструкции, сложностькоторых вселяет в нас ужас. Один только мозг настолько сложен, чтоневозможно составить его схему. Его мощь невозможно повторить, он богатсвоеобразием, способен к самосохранению и самообновлению. Секрет в том, чтомозг растет, а не строится.
Так же должны создаваться наши программные системы. Несколько лет назадХарлан Миллз предложил наращивать программные системы путем пошаговойразработки.11 Это значит, что сначала систему надо заставить выполняться,даже если при этом она не делает ничего полезного, кроме вызова некоторогочисла фиктивных подпрограмм. Затем она понемногу обрастает мясом, причемподпрограммы, в свою очередь, разрабатываются сначала как вызовы пустыхфиктивных подпрограмм, находящихся на уровень ниже.
Настаивая на применении этой технологии разработчиками проектов на моихлабораторных занятиях по программной инженерии, я стал свидетелемпоразительных результатов. За последнее десятилетие ничто другое не оказалостоль сильного влияния на мою собственную работу и ее эффективность. Этотподход предполагает нисходящее проектирование, поскольку это - нисходящеенаращивание программы. Он позволяет легко отслеживать работу в обратномнаправлении. Он предоставляет возможность раннего создания макетов. Каждаяновая функция или возможность работы с более сложными данными или условиямиорганически вырастают на того, что уже имеется.
Воздействие на моральный дух ошеломительное. Когда есть хотя бы простаяработающая система, возрастает энтузиазм. Энергия удваивается, когда наэкране появляется картинка из новой графической программной системы, дажеесли это всего лишь прямоугольник. И на каждой стадии процесса разработкисуществует работающая система. Я считаю, что за одинаковые сроки командаможет нарастить значительно более сложный объект, чем построить.
В больших проектах можно ощутить такие же выгоды, как и в моихмаленьких.12
Выдающиеся проектировщики. Главная проблема совершенствования искусствапрограммирования заключена, как всегда, в людях.
Мы можем добиваться хороших проектов, следуя хорошим, а не плохимпрактическим приемам. Хорошим приемам можно обучать. Программистыпринадлежат к наиболее интеллектуальной части общества, следовательно, они всостоянии изучать хорошие приемы. Поэтому важнейшим направлением вСоединенных Штатах является распространение хороших современных приемов.Новые курсы, новые издания, новые организации, такие как Институт инженеров-программистов (Software Engineering Institute) - все это вызвано к жизнистремлением повысить уровень наших практических приемов. Это совершенноправильно.
Тем не менее, я считаю, что мы не сможем подняться еще на однуступеньку выше, действуя в этом направлении. Выбор правильного методапроектирования определяет различия между плохим и хорошим концептуальнымпроектом, но не между хорошим и выдающимся. Выдающиеся проекты создаютсявыдающимися проектировщиками. Создание программ является творческимпроцессом. Крепкая методология может придать силу и освободить творческийум, но она не может воспламенить или вдохновить того, кто занят нуднойработой.
И разница немалая - это как Сальери и Моцарт. Одно исследование задругим показывают, что лучшие проектировщики создают структуры, которыебыстрее, меньше по размеру, проще, понятнее и разработаны меньшими усилиями.Различия между выдающимся и средним достигают порядка величины.
Нетрудно проследить, что ряд хороших и полезных программных системпроектировался комиссиями и создавался с помощью проектов, состоявших измногих частей. Но программные системы, вызвавшие восхищение страстныхпоклонников, являются продуктом одного или небольшого числа выдающихсяпроектировщиков. Посмотрите на Unix, APL, Pascal, интерфейс Smalltalk и дажеFortran - с одной стороны, и Cobol, PL/I, Algol, MVS/370 и MS-DOS - с другой(рис. 16.1).
Рис. 16.1 Имеются ли у этих продуктов страстные поклонники?
Поэтому, высоко ценя нынешние программы передачи технологий и развитияобучения, я считаю, что наиболее важной программой, которую мы можемпредпринять, является развитие способов воспитания выдающихсяпроектировщиков.
Ни одна занятая в программировании организация не может игнорироватьэту проблему. Хороших менеджеров, как бы мало их ни было, не меньше, чемхороших проектировщиков. Как выдающиеся проектировщики, так и выдающиесяменеджеры встречаются редко. В большинстве организаций значительные усилиятратятся на поиска и выращивание подающих надежды менеджеров. Я не слышал,чтобы кто- либо тратил такие же усилия на поиски и развитие выдающихсяпроектировщиков, от которых, в конечном счете, зависит техническоепревосходство продуктов.
Первое мое предложение состоит в том, чтобы каждая занятая впрограммировании организация определила для себя и провозгласила, чтовыдающиеся проектировщики имеют для ее успеха такое же большое значение, каки выдающиеся менеджеры, и что они могут рассчитывать на такие же заботу ивознаграждение. Не только зарплата, но и атрибуты положения - размеры офиса,мебель, техническое оборудование, командировочные фонды, обеспеченностьсотрудниками - должны быть полностью равнозначны.
Как растить выдающихся проектировщиков? Место не позволяет обсуждатьэто пространно, но вот некоторые очевидные шаги:
- Систематически и как можно раньше выявлять первоклассныхпроектировщиков. Лучшие - не всегда самые опытные.
- Назначить наставника, ответственного за рост перспективногопроектировщика и тщательно следить за его карьерой.
- Разработать и осуществлять план служебного роста для каждогоперспективного проектировщика, включающий тщательно продуманное обучение упередовых проектировщиков, периоды дополнительного формального обучения,краткосрочные курсы, перемежающиеся с самостоятельным проектированием иназначением на руководящие технические должности.
- Обеспечить возможности для взаимодействия и взаимного стимулированиярастущих проектировщиков.