Страница:
или кем-то другим, помогает избежать целых уровней сложности. "СПН"
провозглашает поход на проблему сложности в полной надежде, что можно
достичь прогресса. Она выступает за добавление к программной системе
необходимой сложности:
- иерархически, располагая модули или объекты по уровням;
- пошагово, что обеспечивает постоянную работоспособность системы.
Анализ Харела
Дэвид Харел (David Harel) в статье 1992 года "Кусая серебрянную пулю"
предпринимает самый тщательный анализ "СПН" из всех опубликованных.9
Пессимизм против оптимизма и реализма. Харел рассматривает как "СПН",
так и статью Парнаса 1984 года "Программные аспекты стратегических
оборонительных систем"10 как "слишком унылые". Он намеревается высветить
более яркую сторону проблемы, предпосылая статье подзаголовок "К светлому
будущему порграммных разработок". Так же, как и Кокс, Харел считает "СПН"
пессимистической, говоря: "Если взглянуть на те же факты с другой точки
зрения, возникают более оптимистические выводы". Оба они неправильно
воприняли тональность статьи.
Прежде всего, моя жена, коллеги и редакторы считают, что я гораздо чаще
впадаю в неоправданный оптимизм, чем в пессимизм. В конце концов я по
происхождению программист, а оптимизм - это профессиональная болезнь данного
ремесла.
В "СПН" прямо сказано: "Вглядываясь в предстоящее десятилетие, мы не
видим серебряной пули... Однако скептицизм не есть пессимизм... Нет царского
пути, но путь есть". Она предсказывает, что нововведения, происходящие в
1986 году, будучи разработаны и использованы, в совокупности действительно
позволят достичь роста производительности на порядок. Десятилетие 1986-1996
подходит к концу, и это предсказание оказывается, скорее, слишком
оптимистичным, а не мрачным.
Даже если бы все без исключения считали "СПН" пессимистической, что в
этом худого? Является ли утверждение Эйнштейна о том, что ничего не может
перемещаться со скоростью, большей скорости света, "унылым" и "мрачным"? А
как насчет результатов Геделя о том, что некоторые вещи невычислимы? "СПН"
пытается утверждать, что "сама сущность программного обеспечения делает
маловероятным открытие "серебряных пуль" когда-либо в будущем". Турский в
своем отличном ответном докладе на конференции IFIP красноречиво заявил:
Из всех попыток науки продвинуться в ложном направлении наиболее
возвышенны те, которые были направлены на поиск философского камня -
вещества, с помощью которого предполагалось обращать простые металлы в
золото. Высшая цель алхимии, к которой с рвением стремились поколения
исследователей, щедро финансировавшиеся светскими и духовными правителями, -
это в чистом виде стремление принимать желаемое за действительное и
общепринятое мнение, что вещи таковы, какими мы хотели бы их видеть. Это
очень по-человечески. Нужно сделать над собой большое усилие, чтобы
смириться с существованием неразрешимых проблем. Стремление вопреки всему
найти выход, даже когда доказано, что его не существует, очень и очень
сильно. И в большинстве своем мы с большим сочувствием относимся к этим
храбрецам, которые пытаются достичь невозможного. Это продолжается и по сей
день. Пишутся сочинения о квадратуре круга. Стряпаются лосьоны для
восстановления утраченных волос - и неплохо продаются. Рождаются методы
повышения производительности программирования - и хорошо расходятся.
Мы слишком часто склонны доверять своему оптимизму (или эксплуатировать
оптимистические надежды своих спонсоров). Мы слишком часто не хотим
прислушиваться к голосу рассудка и обращаем много внимания на продавцов
панацей, поющих голосами сирен.11
Турский, как и я, предупреждает, что мечтательность тормозит движение
вперед и ведет к пустой трате сил.
"Мрачные" темы. Харел считает, что мрачность "СПН" придают три темы:
- Резкое разделение между сущностью и второстепенным.
- Изолированное рассмотрение каждого кандидата в "серебряные пули".
- Прогноз лишь на ближайшие 10 лет, а не на срок, в течение которого
можно ожидать "существенных улучшений".
Что касается первого, то в это вся соль статьи. Я по-прежнему считаю,
что такое разделение необходимо для понимания того, почему трудно создавать
программное обеспечение. И это верное указание, куда должен быть направлен
удар.
Что касается изолированного рассмотрения кандидатов в "серебряные
пули", то это правда. Разные кандидаты предлагались поочередно и непомерными
претензиями на собственное всесилие. Правомерно и рассматривать их
поочередно. Я возражаю не против самих технологий, но против ожидания от них
чуда. Гласс, Весси и Конджер (Glass, Vessey, Conger) в своей статье 1992
года представили многочисленные свидетельства того, что бесполезные поиски
серебряной пули все еще продолжаются.12
Что касается выбора в качестве периода предсказаний 10, а не 40 лет, то
частично это признание того, что наши предсказания на больший срок никогда
не были удачными. Кто из нас в 1975 году предсказал микрокомпьютерную
революцию 80-х?
Есть и другие причины ограничиться десятилетием: все кандидаты
претендовали на получение результатов немедленно. Я не помню ни одного,
который бы сказал: "Если сегодня вы сделаете инвестиции в предлагаемое мной
средство, то по прошествии 10 лет начнете пожинать плоды". Более того, за
десятилетие соотношение производительность/цена для компьютеров выросло,
наверное, в сотни раз, и неизбежно подсознательно производится сравнение,
которое совершенно недопустимо. Мы наверняка достигнем большего прогресса за
предстоящие 40 лет. Рост за 40 лет на порядок едва ли покажется чудом.
Мысленный эксперимент Харела. Харел предлагает мысленный эксперимент, в
котором "СПН" была написана в 1952 году, а не в 1986, но содержала бы те же
утверждения. Он хочет использовать это в качестве доказательства от
противного в борьбе против попыток отделить сущность от акциденции.
Это доказательство неверно. Во-первых, "СПН" начинается с утверждения,
что для программирования в 1950-х характерно значительное преобладание
трудностей в акциденциях над трудностями в сущности. Этого преобладания
больше не существует, что привело к росту производительности на порядки
величин. Переносить это доказательство на 40 лет назад бессмысленно: никто
не стал бы в 1952 году утверждать, что не трудности акциденций ответственны
за большую часть затрачиваемых усилий.
Во-вторых, Харел неточно представляет положение дел в 1950-х:
Это было время, когда вместо того, чтобы разрабатывать большие сложные
системы, программисты писали обычные однопользовтельские программы, которые
на современных языках программирования заняли бы 100-200 строк, и которые
должны были выполнять скромные алгоритмические задачи. При существовавших
тогда технологиях и методологиях такие задачи тоже были очень трудными.
Сплошь и рядом были неудачи, ошибки, нарушение сроков.
Затем он описывает, как за последние 25 лет упомянутые неудачи,
ошибки, нарушенные сроки в обычных маленьких одновользовательских программах
были улучшены на порядок.
Но в действительности в 1950-х годах вершиной технологии были не
маленькие однопользовательские программы. В 1952 году Univac был занят
обработкой данных переписи 1950 года с помощью сложной программы, которую
разрабатывали примерно восемь программистов.13 Другие машины применялись в
химической динамике, расчетах рассеяния нейтронов, расчетах полета ракет и
т.д.14 Повседневно использовались ассемблеры, перемещающие компоновщики и
загрузчики, системы интерпретации с плавающей точкой и т.п.15
К 1955 году уже создавались программы для бизнеса объемом от 50 до 100
человеко-лет.16 В 1956 году на заводе Дженерал Электрик в Льюисвилле
работала программа размером более 80 000 слов. В 1957 году в течение уже
двух лет в системе противовоздушной обороны работал компьютер SAGE ANFSQ/7,
и на 30 площадках действовала система реального времени, использовавшая
телекоммуникации и дублирование в целях отказоустойчивости, объемом 75 000
команд.17 Едва ли можно придерживаться мнения, что развитие технологий для
однопользовательских программ - главная характеристика усилий в технике
программного обеспечения после 1952 года.
ВОТ ОНА. Харел продолжает, предлагая собственную серебряную пулю,
технологию моделирования под названием "Vanilla Framework" ("ванильная
структура"). Сам подход описан недостаточно подробно, чтобы его можно было
оченить, но есть ссылка на статью и технический отчет, который в свое время
должен быть опубликован в виде книги.18 Моделирование касается сущности,
правильной разработки и отладки понятий, поэтому технология может оказаться
революционной. Надеюсь, что это так. Кен Брукс сообщает, что эта методология
оказалась полезной, когда он попытался применить ее к реальной задаче.
Незримость. Харел энергично доказывает, что значительная часть
концептуальной конструкции программного обеспечения является по своей
природе топологической задачей, и эти взаимосвязи находят соответствие в
пространственно-графических представлениях:
Использование подходящего визуального формализма может оказать заметное
воздействие на инженеров и программистов. Более того, это воздействие не
ограничивается областью акциденций, было обнаружено положительное влияние на
качество и быстроту самого их мышления. В будущем успехи в разработке систем
будут связаны с визуальными представлениями. Сначала мы будем создавать
концепции с помощью "правильных" объектов и взаимосвязей, затем
формулировать наши концепции как последовательный ряд все более
обстоятельных моделей с использованием подходящей комбинации визуальных
языков. Именно комбинации, поскольку модели систем имеют несколько граней,
каждая из которых вызывает в воображении различные виды образов.
...Некоторые грани процесса моделирования не столь легко поддаются
хорошей визуализации. Например, алгоритмические операции над переменными и
структурами данных, возможно, останутся текстуальными.
Здесь наши позиции близки. Я доказывал, что структура программного
обеспечения не является трехмерной, поэтому не существует естественного
отображения концептуального проекта в диаграмму в пространстве как двух, так
и большего числа измерений. Харел допускает, и я согласен, что требуется
много диаграмм, каждая из которых охватывает какую-то одну сторону, а
некоторые аспекты вообще плохо отображаются на диаграммах.
Я вполне разделяю его энтузиазм по поводу использования диаграмм как
вспомогательного средства при обдумывании и проектировании. Долгое время я
любил задавать кандидатам на работу программистом вопрос: "Где находится
следующий ноябрь?". Если вопрос кажется загадочным, то в другом виде:
"Какова ваша мысленная мысленная модель календаря?" У действительно хороших
программистов хорошее чувство пространства, у них обычно есть геометрическая
модель времени, и они часто без труда понимают первый вопрос. Их модели
очень индивидуальны.
Точка зрения Джонса: происзводительность приходит вслед за Качеством
Каперс Джонс (Capers Jones) сначала в серии служебных записок, а затем
в отдельной книге демонстрирует глубокую интуицию, отмеченную несколькими
моими корреспондентами. "Статья "СПН", как и многие в то время,
сосредоточилась на производительности - выходе программной продукции на
единицу входных затрат", - говорит Джонс. - "Нет, сосредоточьтесь на
качестве, а производительность придет следом."19 Он утверждает, что
дорогостоящие и нарушившие сроки проекты требуют больше всего дополнительных
усилий и времени для поиска и устранения ошибок в спецификациях, в проекте,
в разработке. Он приводит данные, свидетельствующие о сильной корреляции
между отсутствием систематического контроля качества и срывом графика работ.
Я им вполне верю. Бем (Boehm) указывает, что производительность снова
падает, когда преследуется исключительно высокое качество, как было в
программах IBM для космического челнока.
Аналогичным образом, Коки (Coqui) утверждает, что принципы
систематической разработки программного обеспечения явились ответом на
озабоченность не столько производительностью, сколько качеством (в
особенности, стремлением избежать крупных катастроф).
Но обратите внимание: целью применения инженерных принципов к
разработке программного обеспечения в 1970-х годах было поднять качество,
тестируемость, устойчивость и предсказуемость программных продуктов, а не
обязательно производительность труда программистов.
Движущей силой использования при разработке программ принципов
программной инженерии было опасение крупных аварий, к которым могла привести
разработка все более сложных систем неуправляемыми художниками.20
Так что же случилось с производительностью?
Производительность в цифах. Цифры, характеризующие производительность,
очень тяжело определить, калибровать и найти. Каперс Джонс считает, что для
двух одинаковых программ на Cobol, написанных с интервалом в 10 лет - с
применением структурного программирования и без него - разница в
производительности троекратная.
Эд Йордон (Ed Yourdin) утверждает: "По моим наблюдениям, благодаря
рабочим станциям и программным инструментам производительность увеличилась в
пять раз." Том Демарко (Tom DeMarco) считает, что "ваше ожидание
десятикратного роста производительности за 10 лет благодаря целому набору
технологий было оптимистичным: мне неизвестны организации, добившиеся роста
производительности на порядок."
Программа в упаковке: покупайте, не надо разрабатывать. Одна из оценок
"СПН" оказалась, я думаю, правильной: "Возникновение массового рынка
является... наиболее глубокой долгосрочной тенденцией в разработке
программного обеспечения". С точки зрения науки, программное обеспечение для
массового рынка образует практически новую отрасль в сравнении с разработкой
заказных программ как внутри фирмы, так и сторонними организациями. Когда
счет проданных пакетов идет на миллионы или хотя бы на тысячи, главными
проблемами становятся качество, своевременность, технические характеристики
и стоимость поддержки, а не стоимость разработки, которая имеет такое
большое значение при разработке заказных систем.
Электроинструмент для ума. Лучший способ повысить производительность
труда программистов информационно-управляющих систем - это пойти в ближайший
компьютерный магазин и купить уже готовым то, что они собираются
разработать. Это не шутка: доступность дешевых и мощных коробочных программ
удовлетворила многие из потребностей, ранее удовлетворявшихся заказными
программами. Эти электроинструменты для ума больше похожи на электрическте
дрели, пилы и шлифовальные машины, чем на большие и сложные производственные
станки. Интеграция их в совместимые и перекрестно-связанные наборы, такие
как Microsoft Works или лучше интегрированный ClarisWorks, обеспечивает
огромную гибкость. И подобно домашней коллекции инструмента, в результате
частого использования набольшого набора для разных задач вырабатываются
привычные навыки. Такой инструмент подчеркивает простоту использования
обычным пользователем, даже не профессионалом.
Иван Селин (Ivan Selin), глава American Management Systems писал мне в
1987 году:
Я хочу придраться к вашему утверждению, что в действительности пакеты
не настолько изменились... Я думаю, что вы слишком легко отбросили главные
следствия вашего замечания, что (программные пакеты) "могут быть немного
более общими и немного лучше настраиваемыми, чем раньше, но не намного".
Даже принимая это заявление за чистую монету, я полагаю, что пользователи
расценивают пакеты, как обладающие более широкими возможностями и легче
настраиваемые, и что такое восприятие делает пользователей более податливыми
перед пакетами. В большинстве случаев, известных моей компании, не
программисты, а (конечные) пользователи неохотно пользуются пакетами,
покскольку думают, что лишатся важных возможностей и функций, а потому
возможность легкой настройки весьма повышает для них привлекательность
продукта.
Я думаю, что Селин совершенно прав: я недооценил как степень
настраиваемости пакета, так и важность этого фактора.
Объектно-ориентированное программирование: а медна пуля не подойдет?
Разработка из больших частей. Если осуществлять сборку из частей,
которые достаточно сложны и имеют однородные интерфейсы, можно быстро
образовывать довольно богатые структуры.
Согласно одному из взглядов на объектно-ориентированное
программирование эта дисциплина осуществляет модульность и чистые
интерфейсы. Другая точка зрения подчеркивает инкапсуляцию - невозможность
увидеть и еще менее изменить внутреннюю структуру детали. Еще одна точка
зрения отмечает наследование и сопутствующую ему иерархическую структуру
классов с виртуальными функциями. И еще один взгляд: важнейшей является
сильная абстрактная типизация данных вместе с гарантиями, что конкретный тип
данных будет обрабатываться только применимыми к нему операциями.
В настоящее время не нужен весь пакет Smalltalk или C++, чтобы
использовать любой из этих дисциплин - многие из них поглотили
объектно-ориентированные технологии. Объектно-ориентированный подход
привлекателен, как поливитамины: одним махом (т.е. переподготовкой
программиста) получаешь все. Очень многообещающая концепция.
Почему объектно-ориентированная технология медленно развивалась? В
течение девяти лет после выхода "СПН" надежды неуклонно росли. Почему
развитие было таким медленным? Теорий много. Джеймс Коггинс, в течение
четырех лет ведущий колонку в The C++ Report, дает такое объяснение:
Проблема в том, что программисты, работающие в ООП, экспериментировали
с кровосмесительными приложениями и были нацелены на низкий уровень
абстракции. Например, они строили такие классы, как "связанный список"
вместо "интерфейс пользователя", или "луч радиации", или "модель из конечных
элементов". К несчастью, строгая проверка типов, которая помогает
программистам C++ избегать ошибок, одновременно затрудняет построение
больших объектов из маленьких.21
Он возвращается к фундаментальной проблеме программирования и
доказывает, что один из способов удовлетворить потребность в программном
обеспечении - увеличить численность образованной рабочей силы путем
подготовки и привлечения наших клиентов. В пользу нисходящего проектирования
приводятся такие аргументы:
Если мы проектируем крупные классы, представляющие концепции, с
которыми наши клиенты уже работают, то они в состоянии понимать и
критиковать проект по мере его развития, а также вместе с нами разрабатывать
контрольные примеры. Офтальмологов, с которыми я работаю, не волнует
организация стека; их волнует описание формы роговицы с помощью полиномов
Лежандра. Маленькая инкапсуляция дает и маленькую выгоду.
Дэвид Парнас, чья статья была одним из источников идей объектно-
ориентированного программирования, смотрят на вещи по иному. Он писал мне:
Ответ прост. Это из-за привязанности ООП к сложным языкам. Вместо
объяснения людям, что ООП является видом проектирования, и вооружения их
принципами проектирования, их учили, что ООП - это использование
определенного инструмента. Любыми срадствами можно писать и плохие, и
хорошие программы. Если не учить людей проектированию, то языки не имеют
большого значения. Результатом будут плохие разработки с помощью этих языков
и малая выгода. А если выгода невелика, то ООП не войдет в моду.
Расходы сейчас, прибыль потом. По моему мнению, у
объектно-ориентированных методологий особенно тяжелый случай болезни,
характерной для многих усовершенствований в методологии. Весьма существенны
предварительные издержки - в основном, чтобы научить программистов мыслить
совершенно по новому, а также на преобразование функций в обобщенные классы.
Выгоды, которые я считаю реальными, а не чисто предположительными,
достигаются во время всего цикла разработки, но настоящая окупаемость
происходит при разработке последующих программ, расширении и сопровождении.
Коггинс коворит: "Объектно-ориентированное программирование не ускорит
разработку первого проекта, так же как и второго. А вот пятый проект из того
же семейства будет сделан очень быстро."22
Рисковать реальными начальными деньгами ради предполагаемых, но
неопределенных прибылей в будущем - это то, чем инвесторы занимаются изо дня
в день. Однако во многих программирующих организациях менеджерам требуется
для этого смелость - качество более редкое, чем компетенция в технических
вопросах или административное мастерство. Я полагаю, что крайняя степень
авансироания расходов и откладывания прибыли является самым существенным
фактором, замедляющим принятие О-О технологий. Но даже в таких условиях C++,
похоже, уверенно вытесняет C во многих организациях. Что с повторным
использованием? Лучший способ справиться с разработкой части программной
системы, относящейся к ее сущности - это вообще ее не разрабатывать. Пакеты
программ - один из способов сделать это. Другой способ - повторное
использование. Действительно, одной из наиболее привлекательных черт
объектно-ориентированного программирования является обещание простоты
повторного использования классов в сочетании с легкостью настройки благодаря
наследованию.
Как часто бывает, после получения некоторого опыта работы по новой
технологии обнаруживается, что она не так проста, как казалось на первый
взгляд.
Конечно, программисты всегда повторно использовали собственные
разработки. Джонс пишет:
У наиболее опытных программистов есть свои личные библиотеки,
позволяющие им при разработке новых программ повторно использовать до 30%
кода по объему. На корпоративном уровне повторное использование приближается
к 75% по объему и требует специальных библиотек и администрирования.
Повторное использование кода в корпоративных масштабах требует изменений в
бухгалтерии проекта и методах измерения работы.23
У. Хуан (W. Huang) предложил организацию программного производства с
матричной структурой управления функциональными специалистами, чтобы держать
под контролем их естественную склонность к повторному использованию
собственного кода.24
Ван Шнайдер (Van Snyder) из JPL напоминает мне, что в кругах
разработчиков математического программного обеспечения существует давняя
традиция повторного использования программ:
Мы полагаем, что препятствия к повторному использованию возникают не со
стороны производителя, а со стороны потребителя. Если разработчик
программного обеспечения - потенциальный потребитель стандартных программных
компонентов - считает, что найти и проверить нужный компонент дороже, чем
написать его заново, значит, будет написан новый компонент, дублирующий
прежний. Обратите внимание, мы сказали "считает" - реальная стоимость
повторной разработки не имеет значения.
Повторное использование кода имеет успех при разработке математических
программ. Причин этому две: 1) это магия, требующая огромного
интеллектуального вклада в каждую строчку кода, и 2) существует богатая и
стандартная терминология, а именно - математика, для описания
функциональности любых компонентов. Поэтому повторно разработать
математический компонент стоит дорого, а разобраться в функциональности
стоит дешево. Давняя традиция публикации и сбора алгоритмов
профессиональными журналами и предложения их по умеренной цене, а также
коммерческое предложение высококачественных алгоритмов по несколько более
высокой, но все же скромной цене, делают поиск требуемых компонентов проще,
чем в других областях, где часто невозможно точно и сжато описать требуемое.
Благодаря совместному действию этих факторов повторное использование
математических программ более привлекательно, чем повторное их изобретение.
Такое же явление повторного использования обнаруживается и в других
сообществах, например, в разработке программ для атомных реакторов,
моделирования климата, моделирования океанов - по тем же самым причинам.
Каждое из этих сообществ выросло на одних и тех же учебниках, с одной и той
же системой обозначений.
Как сегодня обстоят дела с повторным использованием на корпоративном
уровне? Проведено множество исследований, а вот практикуется в США
относительно мало. Что же касается повторного использования за рубежом, то
тут имеют место неправдоподобные отчеты.25
Джонс сообщает, что все клиенты его фирмы, у которых более 5000
программистов, проводят формальные исследования повторной используемости, в
то время как из числа клиентов с 500 и менее программстами это делает менее
10 процентов.26 По его сообщению, в отраслях с высоким потенциалом
повторного использования исследования (не реализация) "ведутся активно и
энергично, даже если не вполне успешно". Эд Йордон сообщает о программной
провозглашает поход на проблему сложности в полной надежде, что можно
достичь прогресса. Она выступает за добавление к программной системе
необходимой сложности:
- иерархически, располагая модули или объекты по уровням;
- пошагово, что обеспечивает постоянную работоспособность системы.
Анализ Харела
Дэвид Харел (David Harel) в статье 1992 года "Кусая серебрянную пулю"
предпринимает самый тщательный анализ "СПН" из всех опубликованных.9
Пессимизм против оптимизма и реализма. Харел рассматривает как "СПН",
так и статью Парнаса 1984 года "Программные аспекты стратегических
оборонительных систем"10 как "слишком унылые". Он намеревается высветить
более яркую сторону проблемы, предпосылая статье подзаголовок "К светлому
будущему порграммных разработок". Так же, как и Кокс, Харел считает "СПН"
пессимистической, говоря: "Если взглянуть на те же факты с другой точки
зрения, возникают более оптимистические выводы". Оба они неправильно
воприняли тональность статьи.
Прежде всего, моя жена, коллеги и редакторы считают, что я гораздо чаще
впадаю в неоправданный оптимизм, чем в пессимизм. В конце концов я по
происхождению программист, а оптимизм - это профессиональная болезнь данного
ремесла.
В "СПН" прямо сказано: "Вглядываясь в предстоящее десятилетие, мы не
видим серебряной пули... Однако скептицизм не есть пессимизм... Нет царского
пути, но путь есть". Она предсказывает, что нововведения, происходящие в
1986 году, будучи разработаны и использованы, в совокупности действительно
позволят достичь роста производительности на порядок. Десятилетие 1986-1996
подходит к концу, и это предсказание оказывается, скорее, слишком
оптимистичным, а не мрачным.
Даже если бы все без исключения считали "СПН" пессимистической, что в
этом худого? Является ли утверждение Эйнштейна о том, что ничего не может
перемещаться со скоростью, большей скорости света, "унылым" и "мрачным"? А
как насчет результатов Геделя о том, что некоторые вещи невычислимы? "СПН"
пытается утверждать, что "сама сущность программного обеспечения делает
маловероятным открытие "серебряных пуль" когда-либо в будущем". Турский в
своем отличном ответном докладе на конференции IFIP красноречиво заявил:
Из всех попыток науки продвинуться в ложном направлении наиболее
возвышенны те, которые были направлены на поиск философского камня -
вещества, с помощью которого предполагалось обращать простые металлы в
золото. Высшая цель алхимии, к которой с рвением стремились поколения
исследователей, щедро финансировавшиеся светскими и духовными правителями, -
это в чистом виде стремление принимать желаемое за действительное и
общепринятое мнение, что вещи таковы, какими мы хотели бы их видеть. Это
очень по-человечески. Нужно сделать над собой большое усилие, чтобы
смириться с существованием неразрешимых проблем. Стремление вопреки всему
найти выход, даже когда доказано, что его не существует, очень и очень
сильно. И в большинстве своем мы с большим сочувствием относимся к этим
храбрецам, которые пытаются достичь невозможного. Это продолжается и по сей
день. Пишутся сочинения о квадратуре круга. Стряпаются лосьоны для
восстановления утраченных волос - и неплохо продаются. Рождаются методы
повышения производительности программирования - и хорошо расходятся.
Мы слишком часто склонны доверять своему оптимизму (или эксплуатировать
оптимистические надежды своих спонсоров). Мы слишком часто не хотим
прислушиваться к голосу рассудка и обращаем много внимания на продавцов
панацей, поющих голосами сирен.11
Турский, как и я, предупреждает, что мечтательность тормозит движение
вперед и ведет к пустой трате сил.
"Мрачные" темы. Харел считает, что мрачность "СПН" придают три темы:
- Резкое разделение между сущностью и второстепенным.
- Изолированное рассмотрение каждого кандидата в "серебряные пули".
- Прогноз лишь на ближайшие 10 лет, а не на срок, в течение которого
можно ожидать "существенных улучшений".
Что касается первого, то в это вся соль статьи. Я по-прежнему считаю,
что такое разделение необходимо для понимания того, почему трудно создавать
программное обеспечение. И это верное указание, куда должен быть направлен
удар.
Что касается изолированного рассмотрения кандидатов в "серебряные
пули", то это правда. Разные кандидаты предлагались поочередно и непомерными
претензиями на собственное всесилие. Правомерно и рассматривать их
поочередно. Я возражаю не против самих технологий, но против ожидания от них
чуда. Гласс, Весси и Конджер (Glass, Vessey, Conger) в своей статье 1992
года представили многочисленные свидетельства того, что бесполезные поиски
серебряной пули все еще продолжаются.12
Что касается выбора в качестве периода предсказаний 10, а не 40 лет, то
частично это признание того, что наши предсказания на больший срок никогда
не были удачными. Кто из нас в 1975 году предсказал микрокомпьютерную
революцию 80-х?
Есть и другие причины ограничиться десятилетием: все кандидаты
претендовали на получение результатов немедленно. Я не помню ни одного,
который бы сказал: "Если сегодня вы сделаете инвестиции в предлагаемое мной
средство, то по прошествии 10 лет начнете пожинать плоды". Более того, за
десятилетие соотношение производительность/цена для компьютеров выросло,
наверное, в сотни раз, и неизбежно подсознательно производится сравнение,
которое совершенно недопустимо. Мы наверняка достигнем большего прогресса за
предстоящие 40 лет. Рост за 40 лет на порядок едва ли покажется чудом.
Мысленный эксперимент Харела. Харел предлагает мысленный эксперимент, в
котором "СПН" была написана в 1952 году, а не в 1986, но содержала бы те же
утверждения. Он хочет использовать это в качестве доказательства от
противного в борьбе против попыток отделить сущность от акциденции.
Это доказательство неверно. Во-первых, "СПН" начинается с утверждения,
что для программирования в 1950-х характерно значительное преобладание
трудностей в акциденциях над трудностями в сущности. Этого преобладания
больше не существует, что привело к росту производительности на порядки
величин. Переносить это доказательство на 40 лет назад бессмысленно: никто
не стал бы в 1952 году утверждать, что не трудности акциденций ответственны
за большую часть затрачиваемых усилий.
Во-вторых, Харел неточно представляет положение дел в 1950-х:
Это было время, когда вместо того, чтобы разрабатывать большие сложные
системы, программисты писали обычные однопользовтельские программы, которые
на современных языках программирования заняли бы 100-200 строк, и которые
должны были выполнять скромные алгоритмические задачи. При существовавших
тогда технологиях и методологиях такие задачи тоже были очень трудными.
Сплошь и рядом были неудачи, ошибки, нарушение сроков.
Затем он описывает, как за последние 25 лет упомянутые неудачи,
ошибки, нарушенные сроки в обычных маленьких одновользовательских программах
были улучшены на порядок.
Но в действительности в 1950-х годах вершиной технологии были не
маленькие однопользовательские программы. В 1952 году Univac был занят
обработкой данных переписи 1950 года с помощью сложной программы, которую
разрабатывали примерно восемь программистов.13 Другие машины применялись в
химической динамике, расчетах рассеяния нейтронов, расчетах полета ракет и
т.д.14 Повседневно использовались ассемблеры, перемещающие компоновщики и
загрузчики, системы интерпретации с плавающей точкой и т.п.15
К 1955 году уже создавались программы для бизнеса объемом от 50 до 100
человеко-лет.16 В 1956 году на заводе Дженерал Электрик в Льюисвилле
работала программа размером более 80 000 слов. В 1957 году в течение уже
двух лет в системе противовоздушной обороны работал компьютер SAGE ANFSQ/7,
и на 30 площадках действовала система реального времени, использовавшая
телекоммуникации и дублирование в целях отказоустойчивости, объемом 75 000
команд.17 Едва ли можно придерживаться мнения, что развитие технологий для
однопользовательских программ - главная характеристика усилий в технике
программного обеспечения после 1952 года.
ВОТ ОНА. Харел продолжает, предлагая собственную серебряную пулю,
технологию моделирования под названием "Vanilla Framework" ("ванильная
структура"). Сам подход описан недостаточно подробно, чтобы его можно было
оченить, но есть ссылка на статью и технический отчет, который в свое время
должен быть опубликован в виде книги.18 Моделирование касается сущности,
правильной разработки и отладки понятий, поэтому технология может оказаться
революционной. Надеюсь, что это так. Кен Брукс сообщает, что эта методология
оказалась полезной, когда он попытался применить ее к реальной задаче.
Незримость. Харел энергично доказывает, что значительная часть
концептуальной конструкции программного обеспечения является по своей
природе топологической задачей, и эти взаимосвязи находят соответствие в
пространственно-графических представлениях:
Использование подходящего визуального формализма может оказать заметное
воздействие на инженеров и программистов. Более того, это воздействие не
ограничивается областью акциденций, было обнаружено положительное влияние на
качество и быстроту самого их мышления. В будущем успехи в разработке систем
будут связаны с визуальными представлениями. Сначала мы будем создавать
концепции с помощью "правильных" объектов и взаимосвязей, затем
формулировать наши концепции как последовательный ряд все более
обстоятельных моделей с использованием подходящей комбинации визуальных
языков. Именно комбинации, поскольку модели систем имеют несколько граней,
каждая из которых вызывает в воображении различные виды образов.
...Некоторые грани процесса моделирования не столь легко поддаются
хорошей визуализации. Например, алгоритмические операции над переменными и
структурами данных, возможно, останутся текстуальными.
Здесь наши позиции близки. Я доказывал, что структура программного
обеспечения не является трехмерной, поэтому не существует естественного
отображения концептуального проекта в диаграмму в пространстве как двух, так
и большего числа измерений. Харел допускает, и я согласен, что требуется
много диаграмм, каждая из которых охватывает какую-то одну сторону, а
некоторые аспекты вообще плохо отображаются на диаграммах.
Я вполне разделяю его энтузиазм по поводу использования диаграмм как
вспомогательного средства при обдумывании и проектировании. Долгое время я
любил задавать кандидатам на работу программистом вопрос: "Где находится
следующий ноябрь?". Если вопрос кажется загадочным, то в другом виде:
"Какова ваша мысленная мысленная модель календаря?" У действительно хороших
программистов хорошее чувство пространства, у них обычно есть геометрическая
модель времени, и они часто без труда понимают первый вопрос. Их модели
очень индивидуальны.
Точка зрения Джонса: происзводительность приходит вслед за Качеством
Каперс Джонс (Capers Jones) сначала в серии служебных записок, а затем
в отдельной книге демонстрирует глубокую интуицию, отмеченную несколькими
моими корреспондентами. "Статья "СПН", как и многие в то время,
сосредоточилась на производительности - выходе программной продукции на
единицу входных затрат", - говорит Джонс. - "Нет, сосредоточьтесь на
качестве, а производительность придет следом."19 Он утверждает, что
дорогостоящие и нарушившие сроки проекты требуют больше всего дополнительных
усилий и времени для поиска и устранения ошибок в спецификациях, в проекте,
в разработке. Он приводит данные, свидетельствующие о сильной корреляции
между отсутствием систематического контроля качества и срывом графика работ.
Я им вполне верю. Бем (Boehm) указывает, что производительность снова
падает, когда преследуется исключительно высокое качество, как было в
программах IBM для космического челнока.
Аналогичным образом, Коки (Coqui) утверждает, что принципы
систематической разработки программного обеспечения явились ответом на
озабоченность не столько производительностью, сколько качеством (в
особенности, стремлением избежать крупных катастроф).
Но обратите внимание: целью применения инженерных принципов к
разработке программного обеспечения в 1970-х годах было поднять качество,
тестируемость, устойчивость и предсказуемость программных продуктов, а не
обязательно производительность труда программистов.
Движущей силой использования при разработке программ принципов
программной инженерии было опасение крупных аварий, к которым могла привести
разработка все более сложных систем неуправляемыми художниками.20
Так что же случилось с производительностью?
Производительность в цифах. Цифры, характеризующие производительность,
очень тяжело определить, калибровать и найти. Каперс Джонс считает, что для
двух одинаковых программ на Cobol, написанных с интервалом в 10 лет - с
применением структурного программирования и без него - разница в
производительности троекратная.
Эд Йордон (Ed Yourdin) утверждает: "По моим наблюдениям, благодаря
рабочим станциям и программным инструментам производительность увеличилась в
пять раз." Том Демарко (Tom DeMarco) считает, что "ваше ожидание
десятикратного роста производительности за 10 лет благодаря целому набору
технологий было оптимистичным: мне неизвестны организации, добившиеся роста
производительности на порядок."
Программа в упаковке: покупайте, не надо разрабатывать. Одна из оценок
"СПН" оказалась, я думаю, правильной: "Возникновение массового рынка
является... наиболее глубокой долгосрочной тенденцией в разработке
программного обеспечения". С точки зрения науки, программное обеспечение для
массового рынка образует практически новую отрасль в сравнении с разработкой
заказных программ как внутри фирмы, так и сторонними организациями. Когда
счет проданных пакетов идет на миллионы или хотя бы на тысячи, главными
проблемами становятся качество, своевременность, технические характеристики
и стоимость поддержки, а не стоимость разработки, которая имеет такое
большое значение при разработке заказных систем.
Электроинструмент для ума. Лучший способ повысить производительность
труда программистов информационно-управляющих систем - это пойти в ближайший
компьютерный магазин и купить уже готовым то, что они собираются
разработать. Это не шутка: доступность дешевых и мощных коробочных программ
удовлетворила многие из потребностей, ранее удовлетворявшихся заказными
программами. Эти электроинструменты для ума больше похожи на электрическте
дрели, пилы и шлифовальные машины, чем на большие и сложные производственные
станки. Интеграция их в совместимые и перекрестно-связанные наборы, такие
как Microsoft Works или лучше интегрированный ClarisWorks, обеспечивает
огромную гибкость. И подобно домашней коллекции инструмента, в результате
частого использования набольшого набора для разных задач вырабатываются
привычные навыки. Такой инструмент подчеркивает простоту использования
обычным пользователем, даже не профессионалом.
Иван Селин (Ivan Selin), глава American Management Systems писал мне в
1987 году:
Я хочу придраться к вашему утверждению, что в действительности пакеты
не настолько изменились... Я думаю, что вы слишком легко отбросили главные
следствия вашего замечания, что (программные пакеты) "могут быть немного
более общими и немного лучше настраиваемыми, чем раньше, но не намного".
Даже принимая это заявление за чистую монету, я полагаю, что пользователи
расценивают пакеты, как обладающие более широкими возможностями и легче
настраиваемые, и что такое восприятие делает пользователей более податливыми
перед пакетами. В большинстве случаев, известных моей компании, не
программисты, а (конечные) пользователи неохотно пользуются пакетами,
покскольку думают, что лишатся важных возможностей и функций, а потому
возможность легкой настройки весьма повышает для них привлекательность
продукта.
Я думаю, что Селин совершенно прав: я недооценил как степень
настраиваемости пакета, так и важность этого фактора.
Объектно-ориентированное программирование: а медна пуля не подойдет?
Разработка из больших частей. Если осуществлять сборку из частей,
которые достаточно сложны и имеют однородные интерфейсы, можно быстро
образовывать довольно богатые структуры.
Согласно одному из взглядов на объектно-ориентированное
программирование эта дисциплина осуществляет модульность и чистые
интерфейсы. Другая точка зрения подчеркивает инкапсуляцию - невозможность
увидеть и еще менее изменить внутреннюю структуру детали. Еще одна точка
зрения отмечает наследование и сопутствующую ему иерархическую структуру
классов с виртуальными функциями. И еще один взгляд: важнейшей является
сильная абстрактная типизация данных вместе с гарантиями, что конкретный тип
данных будет обрабатываться только применимыми к нему операциями.
В настоящее время не нужен весь пакет Smalltalk или C++, чтобы
использовать любой из этих дисциплин - многие из них поглотили
объектно-ориентированные технологии. Объектно-ориентированный подход
привлекателен, как поливитамины: одним махом (т.е. переподготовкой
программиста) получаешь все. Очень многообещающая концепция.
Почему объектно-ориентированная технология медленно развивалась? В
течение девяти лет после выхода "СПН" надежды неуклонно росли. Почему
развитие было таким медленным? Теорий много. Джеймс Коггинс, в течение
четырех лет ведущий колонку в The C++ Report, дает такое объяснение:
Проблема в том, что программисты, работающие в ООП, экспериментировали
с кровосмесительными приложениями и были нацелены на низкий уровень
абстракции. Например, они строили такие классы, как "связанный список"
вместо "интерфейс пользователя", или "луч радиации", или "модель из конечных
элементов". К несчастью, строгая проверка типов, которая помогает
программистам C++ избегать ошибок, одновременно затрудняет построение
больших объектов из маленьких.21
Он возвращается к фундаментальной проблеме программирования и
доказывает, что один из способов удовлетворить потребность в программном
обеспечении - увеличить численность образованной рабочей силы путем
подготовки и привлечения наших клиентов. В пользу нисходящего проектирования
приводятся такие аргументы:
Если мы проектируем крупные классы, представляющие концепции, с
которыми наши клиенты уже работают, то они в состоянии понимать и
критиковать проект по мере его развития, а также вместе с нами разрабатывать
контрольные примеры. Офтальмологов, с которыми я работаю, не волнует
организация стека; их волнует описание формы роговицы с помощью полиномов
Лежандра. Маленькая инкапсуляция дает и маленькую выгоду.
Дэвид Парнас, чья статья была одним из источников идей объектно-
ориентированного программирования, смотрят на вещи по иному. Он писал мне:
Ответ прост. Это из-за привязанности ООП к сложным языкам. Вместо
объяснения людям, что ООП является видом проектирования, и вооружения их
принципами проектирования, их учили, что ООП - это использование
определенного инструмента. Любыми срадствами можно писать и плохие, и
хорошие программы. Если не учить людей проектированию, то языки не имеют
большого значения. Результатом будут плохие разработки с помощью этих языков
и малая выгода. А если выгода невелика, то ООП не войдет в моду.
Расходы сейчас, прибыль потом. По моему мнению, у
объектно-ориентированных методологий особенно тяжелый случай болезни,
характерной для многих усовершенствований в методологии. Весьма существенны
предварительные издержки - в основном, чтобы научить программистов мыслить
совершенно по новому, а также на преобразование функций в обобщенные классы.
Выгоды, которые я считаю реальными, а не чисто предположительными,
достигаются во время всего цикла разработки, но настоящая окупаемость
происходит при разработке последующих программ, расширении и сопровождении.
Коггинс коворит: "Объектно-ориентированное программирование не ускорит
разработку первого проекта, так же как и второго. А вот пятый проект из того
же семейства будет сделан очень быстро."22
Рисковать реальными начальными деньгами ради предполагаемых, но
неопределенных прибылей в будущем - это то, чем инвесторы занимаются изо дня
в день. Однако во многих программирующих организациях менеджерам требуется
для этого смелость - качество более редкое, чем компетенция в технических
вопросах или административное мастерство. Я полагаю, что крайняя степень
авансироания расходов и откладывания прибыли является самым существенным
фактором, замедляющим принятие О-О технологий. Но даже в таких условиях C++,
похоже, уверенно вытесняет C во многих организациях. Что с повторным
использованием? Лучший способ справиться с разработкой части программной
системы, относящейся к ее сущности - это вообще ее не разрабатывать. Пакеты
программ - один из способов сделать это. Другой способ - повторное
использование. Действительно, одной из наиболее привлекательных черт
объектно-ориентированного программирования является обещание простоты
повторного использования классов в сочетании с легкостью настройки благодаря
наследованию.
Как часто бывает, после получения некоторого опыта работы по новой
технологии обнаруживается, что она не так проста, как казалось на первый
взгляд.
Конечно, программисты всегда повторно использовали собственные
разработки. Джонс пишет:
У наиболее опытных программистов есть свои личные библиотеки,
позволяющие им при разработке новых программ повторно использовать до 30%
кода по объему. На корпоративном уровне повторное использование приближается
к 75% по объему и требует специальных библиотек и администрирования.
Повторное использование кода в корпоративных масштабах требует изменений в
бухгалтерии проекта и методах измерения работы.23
У. Хуан (W. Huang) предложил организацию программного производства с
матричной структурой управления функциональными специалистами, чтобы держать
под контролем их естественную склонность к повторному использованию
собственного кода.24
Ван Шнайдер (Van Snyder) из JPL напоминает мне, что в кругах
разработчиков математического программного обеспечения существует давняя
традиция повторного использования программ:
Мы полагаем, что препятствия к повторному использованию возникают не со
стороны производителя, а со стороны потребителя. Если разработчик
программного обеспечения - потенциальный потребитель стандартных программных
компонентов - считает, что найти и проверить нужный компонент дороже, чем
написать его заново, значит, будет написан новый компонент, дублирующий
прежний. Обратите внимание, мы сказали "считает" - реальная стоимость
повторной разработки не имеет значения.
Повторное использование кода имеет успех при разработке математических
программ. Причин этому две: 1) это магия, требующая огромного
интеллектуального вклада в каждую строчку кода, и 2) существует богатая и
стандартная терминология, а именно - математика, для описания
функциональности любых компонентов. Поэтому повторно разработать
математический компонент стоит дорого, а разобраться в функциональности
стоит дешево. Давняя традиция публикации и сбора алгоритмов
профессиональными журналами и предложения их по умеренной цене, а также
коммерческое предложение высококачественных алгоритмов по несколько более
высокой, но все же скромной цене, делают поиск требуемых компонентов проще,
чем в других областях, где часто невозможно точно и сжато описать требуемое.
Благодаря совместному действию этих факторов повторное использование
математических программ более привлекательно, чем повторное их изобретение.
Такое же явление повторного использования обнаруживается и в других
сообществах, например, в разработке программ для атомных реакторов,
моделирования климата, моделирования океанов - по тем же самым причинам.
Каждое из этих сообществ выросло на одних и тех же учебниках, с одной и той
же системой обозначений.
Как сегодня обстоят дела с повторным использованием на корпоративном
уровне? Проведено множество исследований, а вот практикуется в США
относительно мало. Что же касается повторного использования за рубежом, то
тут имеют место неправдоподобные отчеты.25
Джонс сообщает, что все клиенты его фирмы, у которых более 5000
программистов, проводят формальные исследования повторной используемости, в
то время как из числа клиентов с 500 и менее программстами это делает менее
10 процентов.26 По его сообщению, в отраслях с высоким потенциалом
повторного использования исследования (не реализация) "ведутся активно и
энергично, даже если не вполне успешно". Эд Йордон сообщает о программной