Мифический человеко-месяц или как создаются программные системы
Шрифт:
Сегодня многие процедуры приобретения программного обеспечения основываются на предположении, что можно заранее задать технические требования для желаемой системы, рассмотреть предложения разработчиков, получить разработанную систему и установить ее. Я думаю, что такое предположение в корне неверно, и из-за этой ошибки проистекают многие проблемы при приобретении программ, поскольку эти проблемы нельзя устранить без пересмотра основ, для которого требуется интерактивная разработка и спецификации макетов и продуктов.
Пошаговая обработка: наращивать программу, а не строить сразу. Я до сих пор помню испытанный в 1958 году удар, когда
Метафора строительства пережила свое время. Пора снова вносить изменения. Если, как я считаю, создаваемые сегодня концептуальные структуры слишком сложны, чтобы их можно было точно специфицировать заранее, и слишком сложны, чтобы строить без ошибок, тогда нужен радикально иной подход.
Обратимся к природе и рассмотрим сложность живых созданий, а не безжизненных творений человека. Там мы обнаруживаем конструкции, сложность которых вселяет в нас ужас. Один только мозг настолько сложен, что невозможно составить его схему. Его мощь невозможно повторить, он богат своеобразием, способен к самосохранению и самообновлению. Секрет в том, что мозг растет, а не строится.
Так же должны создаваться наши программные системы. Несколько лет назад Харлан Миллз предложил наращивать программные системы путем пошаговой разработки. [11] Это значит, что сначала систему надо заставить выполняться, даже если при этом она не делает ничего полезного, кроме вызова некоторого числа фиктивных подпрограмм. Затем она понемногу обрастает мясом, причем подпрограммы, в свою очередь, разрабатываются сначала как вызовы пустых фиктивных подпрограмм, находящихся на уровень ниже.
Настаивая на применении этой технологии разработчиками проектов на моих лабораторных занятиях по программной инженерии, я стал свидетелем поразительных результатов. За последнее десятилетие ничто другое не оказало столь сильного влияния на мою собственную работу и ее эффективность. Этот подход предполагает нисходящее проектирование, поскольку это — нисходящее наращивание программы. Он позволяет легко отслеживать работу в обратном направлении. Он предоставляет возможность раннего создания макетов. Каждая новая функция или возможность работы с более сложными данными или условиями органически вырастают на того, что уже имеется.
Воздействие на моральный дух ошеломительное. Когда есть хотя бы простая работающая система, возрастает энтузиазм. Энергия удваивается, когда на экране появляется картинка из новой графической программной системы, даже если это всего лишь прямоугольник. И на каждой стадии процесса разработки существует работающая система. Я считаю, что за одинаковые сроки команда может нарастить значительно более сложный объект, чем построить.
В больших проектах можно ощутить такие же выгоды, как и в моих маленьких. [12]
Выдающиеся проектировщики. Главная проблема совершенствования искусства программирования заключена, как всегда, в людях.
Мы можем добиваться хороших проектов, следуя хорошим, а не плохим практическим
Тем не менее, я считаю, что мы не сможем подняться еще на одну ступеньку выше, действуя в этом направлении. Выбор правильного метода проектирования определяет различия между плохим и хорошим концептуальным проектом, но не между хорошим и выдающимся. Выдающиеся проекты создаются выдающимися проектировщиками. Создание программ является творческим процессом. Крепкая методология может придать силу и освободить творческий ум, но она не может воспламенить или вдохновить того, кто занят нудной работой.
И разница немалая — это как Сальери и Моцарт. Одно исследование за другим показывают, что лучшие проектировщики создают структуры, которые быстрее, меньше по размеру, проще, понятнее и разработаны меньшими усилиями. Различия между выдающимся и средним достигают порядка величины.
Нетрудно проследить, что ряд хороших и полезных программных систем проектировался комиссиями и создавался с помощью проектов, состоявших из многих частей. Но программные системы, вызвавшие восхищение страстных поклонников, являются продуктом одного или небольшого числа выдающихся проектировщиков. Посмотрите на Unix, APL, Pascal, интерфейс Smalltalk и даже Fortran — с одной стороны, и Cobol, PL/I, Algol, MVS/370 и MS-DOS — с другой (рис. 16.1).
Рис. 16.1 Имеются ли у этих продуктов страстные поклонники?
Поэтому, высоко ценя нынешние программы передачи технологий и развития обучения, я считаю, что наиболее важной программой, которую мы можем предпринять, является развитие способов воспитания выдающихся проектировщиков.
Ни одна занятая в программировании организация не может игнорировать эту проблему. Хороших менеджеров, как бы мало их ни было, не меньше, чем хороших проектировщиков. Как выдающиеся проектировщики, так и выдающиеся менеджеры встречаются редко. В большинстве организаций значительные усилия тратятся на поиска и выращивание подающих надежды менеджеров. Я не слышал, чтобы кто-либо тратил такие же усилия на поиски и развитие выдающихся проектировщиков, от которых, в конечном счете, зависит техническое превосходство продуктов.
Первое мое предложение состоит в том, чтобы каждая занятая в программировании организация определила для себя и провозгласила, что выдающиеся проектировщики имеют для ее успеха такое же большое значение, как и выдающиеся менеджеры, и что они могут рассчитывать на такие же заботу и вознаграждение. Не только зарплата, но и атрибуты положения — размеры офиса, мебель, техническое оборудование, командировочные фонды, обеспеченность сотрудниками — должны быть полностью равнозначны.
Как растить выдающихся проектировщиков? Место не позволяет обсуждать это пространно, но вот некоторые очевидные шаги: