Если обратиться к основам, программное обеспечение очень трудно визуализировать, как я доказывал это выше. Составляем ли мы схемы управляющей логики, вложенных областей, видимости переменных, перекрестных ссылок переменных, потоков данных, иерархических структур данных или чего-то еще, они отражают лишь одно изменение взаимодействующих запутанным образом частей программной системы. Если наложить одна на другую эти схемы, отражающие взгляд с различных точек зрения, трудно извлечь из этого какую-либо общую точку зрения. Аналогия с интегральными схемами вводит, в сущности, в заблуждение: конструкция микросхемы представляет собой многослойный двумерный объект, геометрия которого отражает сущность. Программная система не является таким объектом.
Верификация программ. Много труда в современном программировании тратится на отладку и исправление ошибок. Может быть, мы найдем серебряную пулю, устранив все ошибки в самом начале, на этапе системного проектирования? Можно ли радикально повысить производительность и надежность продукта, если следовать совершенно иной стратегии — обеспечить корректность проекта, прежде чем тратить огромные усилия на его реализацию и тестирование?
Не думаю, что мы обнаружим здесь чудеса. Верификация программ является очень мощной концепцией, и она очень важна для таких вещей, как создание надежного ядра операционной системы. Эта технология не обещает, однако, экономии труда. Верификация требует столько работы, что весьма немногие значительные программы вообще были верифицированы.
Верификация программ не означает создания программ, лишенных ошибок. И здесь нет чудес. Математические доказательства тоже могут быть ошибочными. Поэтому хотя верификация может облегчить тестирование, она не может отменить его.
Более существенно, что даже самая совершенная верификация программы может лишь определить, что программа отвечает своим спецификациям. Самая сложная задача программирования — получить полную и непротиворечивую спецификацию, и сущность создания программы на практике во многом состоит в отладке спецификации.
Среды программирования и инструменты. Какого еще выигрыша можно ожидать от стремительно расширяющихся исследований по усовершенствованию сред программирования? Инстинктивно кажется, что задачи, которые сулили наибольшую отдачу, были в числе первых, за которые взялись, и их уже решили: иерархические файловые системы, единообразные форматы файлов для получения единообразных программных интерфейсов и обобщенных инструментов. Ориентированные на конкретные языки интеллектуальные редакторы пока не очень распространены, но большее, на что они способны, это устранение синтаксических ошибок и мелких семантических.
Возможно, наибольший выигрыш среда программирования сможет дать при использовании строенных систем баз данных для отслеживания мириадов деталей, которые каждый программист должен точно вспоминать, и которые должны храниться в текущем состоянии в группе работающих над одной системой.
Несомненно, что это работа заслуживает внимания и принесет некоторые плоды как для производительности, так и для надежности. Но ввиду самой ее сути отдача должна быть незначительной.
Рабочие станции. Какой выигрыш может получить искусство программирования от несомненного и быстрого роста мощности и объема памяти отдельной рабочей станции? Сколько миллионов операций в секунду можно плодотворно использовать? Составление и редактирование программ вполне обеспечиваются сегодняшними скоростями. Компиляция может быть ускорена, но десятикратное увеличение скорости машины, вне сомнения, сделает обдумывание основным занятием программиста в течение рабочего дня. Пожалуй, это так уже сейчас.
Конечно, мы приветствуем увеличение мощности рабочих станций. Но рассчитывать на связанные с этим чудеса мы не можем.
Перспективные подходы к концептуальной сущности
Хотя никакой прорыв в технологии не обещает таких волшебных результатов, какие мы видим в аппаратной части компьютеров, в настоящее время делается много полезного, и есть надежды на неуклонный, хотя и неброский прогресс.
Все технологические подходы к акциденциям процесса программирования принципиально ограничены уравнением продуктивности:
Время решения задачи = ^ (Частот)/ х (Длительность)/
Если, как я полагаю, концептуальные составляющие задачи сейчас отнимают большую часть времени, то никакая работа над составными частями задачи, являющимися просто выражением концепций, не даст большого выигрыша.
Поэтому мы должны рассмотреть те направления, которые затрагивают саму сущность проблемы программирования — формулировку этих сложных концептуальных структур. К счастью, некоторые из этих направлений весьма многообещающи.
Покупать, а не создавать. Наиболее радикальное возможное решение при создании программ — вообще не создавать их.
С каждым днем это становится все легче, поскольку все большее число поставщиков предлагает все более многочисленные и лучшие программные продукты для немыслимого разнообразия приложений. Пока мы, инженеры-программисты, трудились над совершенствованием методологии производства, революция, произведенная персональными компьютерами, создала не один, а много массовых рынков программного обеспечения. В каждом газетном киоске выставлены ежемесячные журналы, в которых, отсортированные по типам машин, рекламируются и рецензируются десятки продуктов по ценам от нескольких долларов до нескольких сотен долларов. Более специализированные издания предлагают очень мощные продукты для рабочих станций и других рынков Unix. Даже инструменты и среды программирования могут быть куплены в коробочном виде. Я где-то предложил базар для отдельных модулей.
Любой такой продукт дешевле купить, чем создавать заново. Даже при цене 100 000 долларов купленный продукт стоит примерно столько, сколько годовое содержание программиста. И поставка немедленная! Немедленная, по крайней мере, для реально существующих продуктов, проспект которых разработчик может послать счастливому пользователю. Более того, такие продукты обычно гораздо лучше документированы и несколько лучше сопровождаются, чем доморощенные программы.
Развитие массового рынка является, по моему мнению, наиболее глубокой долгосрочной тенденцией программной инженерии. Стоимость программного продукта всегда определялась стоимостью разработки, а не тиражирования. Разделив эту стоимость даже на нескольких пользователей, мы коренным образом снижаем цену на одного пользователя. Взглянув на это с другой стороны, мы видим, что использование п копий программной системы фактически умножает на п производительность его разработчиков. Это рост производительности отрасли и всей страны.
Главным вопросом, конечно, является производительность. Смогу ли я использовать имеющийся коробочный продукт для решения своих задач? Здесь случилась удивительная вещь. В 50-х и 60-х годах одно исследование за другим показывало, что пользователи не хотят использовать коробочные пакеты для расчета зарплаты, управления складом, учета дебиторов по расчетам и т.д. Требования были слишком специальными, отклонения от случая к случаю слишком большими. В 80-х годах мы обнаруживаем большой спрос на такие пакеты и широкое их использование. Что изменилось?
Только не пакеты. Они стали несколько более общими и лучше настраиваются, чем раньше, но не намного. И не область их применения. В конце концов, сегодня потребности бизнеса и науки более разнообразны и сложны, чем 20 лет назад.
Резко изменилось соотношение стоимости компьютеров и программ. Тот, кто в 1960 году покупал машину за 2 миллиона долларов, считал, что может позволить себе потратить еще 250 000 долларов на заказную программу расчета зарплаты, которая легко и без ущерба вписалась бы во враждебную компьютерам социальную среду. Те, кто сегодня покупают машину для офиса за 50 000 долларов, не могут, понятно, позволить себе заказные программы расчета зарплаты, поэтому они приспосабливают свои процедуры расчета зарплаты к имеющимся пакетам. Компьютеры сейчас столь обычны, если не столь любимы, что адаптация воспринимается как обычное дело.