Есть яркие исключения из моего утверждения о том, что обобщенность программных пакетов за последние годы мало изменилась: электронные таблицы и простые системы баз данных. Эти мощные инструменты, столь очевидные задним умом и так поздно появившиеся, имеют бесчисленное множество применений, в том числе, весьма необычные. Есть масса статей и даже книг о том, как с помощью электронной таблицы решать неожиданные задачи. Большое число задач, для которых раньше были бы написаны заказные программы на Cobol или Report Program Generator, теперь шаблонно решается с помощью этих инструментов.
Многие пользователи изо дня в день применяют свои компьютеры для разных приложений, никогда не написав ни одной программы. На практике многие из этих пользователей и не могут писать для своих машин новые программы, но тем не менее приверженцы решению возникающих задач с их помощью.
Я считаю, что сегодня для многих организаций самая правильная политика для повышения производительности разработки программного обеспечения — это установить своим не имеющим компьютерных знаний работникам умственного труда компьютеры и хорошие общие программы для обработки текстов, рисования, работы с файлами и электронными таблицами и отпустить их в вольное плавание. Такая же политика в отношении распространенных математических и статистических пакетов, а также некоторых навыков программирования подойдет сотням ученых, работающих в лабораториях.
Уточнение требований и быстрое макетирование. Самая трудная отдельная задача в разработке программной системы — это точно решить, что разрабатывать. Ни одна другая задача работы над концепциями не является столь трудной, как разработка подробных технических требований, включая все интерфейсы пользователей, машинные интерфейсы и интерфейсы к другим программным системам. Ни одна другая часть работы не наносит такого ущерба готовой системе, если сделана неправильно. Ни одна другая часть не исправляется позднее с бульшим трудом.
Поэтому наиболее важной функцией, осуществляемой разработчиками для своих клиентов, является повторяющееся получение и уточнение требований к продукту. Правда заключается в том, что клиенты не знают, чего хотят. Обычно они не знают, на какие вопросы нужно дать ответ, и почти никогда не задумывались над задачей настолько детально, как это нужно указать в спецификации. Даже простой ответ — «сделайте так, чтобы новая программная система работала так, как наша старая ручная система обработки информации» — оказывается в действительности слишком упрощенным. Клиенты никогда не хотят этого в точности. Более того, сложные программные системы действуют, движутся, работают. Динамику этого действия трудно себе представить. Поэтому при планировании любых действий необходимо оставить резерв для многократного взаимодействия между клиентом и проектировщиком при описании системы.
Я пойду дальше и стану утверждать, что на практике клиенты, даже вместе с инженерами-программистами, не в состоянии указать полно, строго и корректно точные требования к современному программному продукту, прежде чем будут созданы и опробованы какие-либо версии продукта, спецификации к которому они составляют.
Поэтому одним из наиболее многообещающих современных направлений в технологии, причем обращенных к сущности, а не к акциденциям проблем программирования, является разработка подходов и инструментов для быстрого создания макетов систем как части итеративного процесса разработки спецификаций.
Макет программной системы моделирует главные интерфейсы и выполняет основные функции предполагаемой системы, при этом не обязательно будучи связан теми же ограничениями быстродействия компьютера, размера или стоимости. Обычно макеты выполняют основные задачи системы, но не пытаются обрабатывать исключительные ситуации, правильно реагировать на ввод недопустимых данных, корректно прерывать работу и т.д. Назначение макета — показать, как воплощается выбранная концептуальная структура, чтобы клиент мог проверить ее пригодность к использованию и непротиворечивость.
Сегодня многие процедуры приобретения программного обеспечения основываются на предположении, что можно заранее задать технические требования для желаемой системы, рассмотреть предложения разработчиков, получить разработанную систему и установить ее. Я думаю, что такое предположение в корне неверно, и из-за этой ошибки проистекают многие проблемы при приобретении программ, поскольку эти проблемы нельзя устранить без пересмотра основ, для которого требуется интерактивная разработка и спецификации макетов и продуктов.
Пошаговая обработка: наращивать программу, а не строить сразу. Я до сих пор помню испытанный в 1958 году удар, когда впервые услышал, как мой друг говорил о строительстве (building) программ в противоположность написанию (writing). В мгновение он расширил все мое представление о процессе программирования. Применение метафоры было сильным и точным. Сегодня мы понимаем, что сходство существует между созданием программы и другими строительными процессами, и свободно используем другие элементы метафоры, такие как спецификации (specifications), сборка компонентов (assembly of components), леса (scaffolding).
Метафора строительства пережила свое время. Пора снова вносить изменения. Если, как я считаю, создаваемые сегодня концептуальные структуры слишком сложны, чтобы их можно было точно специфицировать заранее, и слишком сложны, чтобы строить без ошибок, тогда нужен радикально иной подход.
Обратимся к природе и рассмотрим сложность живых созданий, а не безжизненных творений человека. Там мы обнаруживаем конструкции, сложность которых вселяет в нас ужас. Один только мозг настолько сложен, что невозможно составить его схему. Его мощь невозможно повторить, он богат своеобразием, способен к самосохранению и самообновлению. Секрет в том, что мозг растет, а не строится.
Так же должны создаваться наши программные системы. Несколько лет назад Харлан Миллз предложил наращивать программные системы путем пошаговой разработки. [11] Это значит, что сначала систему надо заставить выполняться, даже если при этом она не делает ничего полезного, кроме вызова некоторого числа фиктивных подпрограмм. Затем она понемногу обрастает мясом, причем подпрограммы, в свою очередь, разрабатываются сначала как вызовы пустых фиктивных подпрограмм, находящихся на уровень ниже.
Настаивая на применении этой технологии разработчиками проектов на моих лабораторных занятиях по программной инженерии, я стал свидетелем поразительных результатов. За последнее десятилетие ничто другое не оказало столь сильного влияния на мою собственную работу и ее эффективность. Этот подход предполагает нисходящее проектирование, поскольку это — нисходящее наращивание программы. Он позволяет легко отслеживать работу в обратном направлении. Он предоставляет возможность раннего создания макетов. Каждая новая функция или возможность работы с более сложными данными или условиями органически вырастают на того, что уже имеется.
Воздействие на моральный дух ошеломительное. Когда есть хотя бы простая работающая система, возрастает энтузиазм. Энергия удваивается, когда на экране появляется картинка из новой графической программной системы, даже если это всего лишь прямоугольник. И на каждой стадии процесса разработки существует работающая система. Я считаю, что за одинаковые сроки команда может нарастить значительно более сложный объект, чем построить.
В больших проектах можно ощутить такие же выгоды, как и в моих маленьких. [12]
Выдающиеся проектировщики. Главная проблема совершенствования искусства программирования заключена, как всегда, в людях.
Мы можем добиваться хороших проектов, следуя хорошим, а не плохим практическим приемам. Хорошим приемам можно обучать. Программисты принадлежат к наиболее интеллектуальной части общества, следовательно, они в состоянии изучать хорошие приемы. Поэтому важнейшим направлением в Соединенных Штатах является распространение хороших современных приемов. Новые курсы, новые издания, новые организации, такие как Институт инженеров-программистов (Software Engineering Institute) — все это вызвано к жизни стремлением повысить уровень наших практических приемов. Это совершенно правильно.
