Это была эпоха, когда программисты стали выдавать ошибки за особенности программ. Наивные пользователи 70-х с готовностью соглашались на сложные ухищрения для того, чтобы обойти ошибку, если верили в то, что это была "единственная возможность реализовать требуемую функцию". Программисты дошли до того, что стали выдавать ошибки за проблемы конфигурации и операционной среды, спровоцированные самими пользователи. Пользователи же слишком мало понимали, что же на самом деле происходит.
Тестирование стало еще одной потерей этого десятилетия хаоса. В 60-х годах компетентные разработчики сами выполняли весь анализ и тестирование. Но в 70-е, когда начался бум в создании автоматизированных решений для новых задач (и в добавлении новых возможностей к существующим системам), появился большой спрос на программистов. Поэтому каждый, кто хоть что-то знал о программах, стал заниматься программированием, и в этом ажиотаже о тестировании попросту забыли.
Конечно, организации, занимающиеся разработкой программного обеспечения не намеривались вовсе отказываться от тестирования, но многие из них отдали его на откуп неспециалистам, по существу превратив в тестировщиков подсобный персонал.
Код, написанный в 70-х годах, - самое худшее, что есть в современном программировании. Для него даже существует специальное название: "унаследованный код". Он пугает, он запутан, и с ним очень сложно работать. Большинство специалистов стремятся всеми возможными средствами избежать необходимости его поддерживать. В конце концов, чужой код иногда понять очень сложно, и одна ошибка, сделанная в модифицированном коде, может породить непредсказуемые побочные эффекты, вне зависимости от того, насколько тщательно этот код протестирован.
Наконец, еще одним важным новшеством 70-х годов стали метрики - показатели, которые, как предполагалось, должны характеризовать "качественность" кода, но зачастую их интерпретировали слишком субъективно. Десятилетие хаоса оказалось не самым лучшим временем для введения метрик. Эта теория строится на количественных аспектах исходных текстов - числе циклов, ветвлений, условных выражений и т.д. Вместо того, чтобы пытаться определить, является ли данное программное обеспечение функционально корректным, разработчики могли просто подсчитать число элементов в коде, чтобы установить его сложность.
В 70-х годах это было увлекательное занятие, и, возможно, давало многим разработчикам чувство удовлетворенности своим кодом. Однако до сих пор использование метрик остается исключением из правил. Большинство разработчиков игнорируют параметры, понимая, что хорошие программисты могут создать очень хороший код, у которого отдельные метрики окажутся далеко не лучшими, а плохие программисты могут написать плохой код, который по своим метрикам будет просто блестящим. Так что, к сожалению, "репутация" метрик была испорчена, поскольку изначально они не отражали действительность. Хорошие, современные метрики функциональной корректности и сейчас не пользуются доверием из-за ассоциации с метриками сложности кода, которые были предложены в 70-х годах.
В целом об этом хаотическом десятилетии развития программного обеспечения можно сказать, что оно было ориентировано на код, а не на качество. К концу 70-х стало очевидно, что изменения в отрасли просто необходимы. И первая книга по тестированию программного обеспечения (Glenford Myers, The Art of Software Testing, Wiley, 1979) появилась в конце именно этого десятилетия. Это был верный признак надвигающихся перемен.
В 80-е годы были предприняты первые попытки вернуть здравый смысл разработке программного обеспечения. Две из них заслуживают особого внимания.
Первая такая попытка обрела форму средств автоматизации разработки программ, получивших название CASE (computer aided software engineering). Идея CASE состояла в том, что программисты могли бы создавать более качественное программное обеспечение, если бы у них были вспомогательные программные средства. Каждому мастеру нужны определенные инструменты. Плотнику, к примеру, молотки. Попытайтесь забить гвоздь в доску с помощью ботинка.
Как и плотники, разработчики программного обеспечения имели свой набор основных, надежных инструментов: редактор, компилятор и отладчик. Подход CASE дал им возможность получить более совершенные инструменты, например, языки четвертого поколения (для них есть даже своя аббревиатура, 4GL). К сожалению, 4GL и большинство других высококачественных инструментальных средств не оправдали возложенные на них надежды. Возьмем, к примеру, Visual Basic. Все согласны, что это полезный, мощный и популярный 4GL-инструментарий, который позволяет увеличить производительность программистов и сократить число потенциальных ошибок. Однако до сих пор самую высокооплачиваемую работу предлагают программистам на Си, а подавляющее большинство крупных прикладных систем по-прежнему пишут на Си (Брайан Керниган, Деннис Ритчи, "Язык программирования Си" - Brian W. Kernighan, Dennis M. Ritchie, The C Programming Language, Prentice-Hall, 1978). По общему признанию, создание инструментария 4GL и CASE было вполне оправданно, но инструментальные средства общего назначения, такие как редакторы, компиляторы и отладчики, остаются главными в обиходе современных разработчиков программного обеспечения, несмотря на огромный интерес к CASE, возникший в начале 80-х.
Еще одна причина того, что этот инструментарий так и не завоевал широкой популярности, заключается в том, что их предназначение как средств, улучшающих качество программ, играет против них. Если инструментарий обещает значительное увеличение качества продукта, должен ли он сам быть высококачественным? Использовали ли его сами разработчики инструментария? Инструментальные средства, изобилующие ошибками, и при этом предназначенные для улучшения качества создаваемых программ, вряд ли понравятся разработчикам. Не менее важны и личные качества человека, который использует такой инструментарий. Утверждение "дурак с инструментом все равно дурак" остается верным и поныне.
Второе важное решение, предложенное в 80-х годах для создания более качественного кода, связано с использованием формальных методов. Как и в случае с CASE, многие рассматривали формальные методы как панацею (Richard Linger, "Cleanroom Process Model", IEEE Software, vol.11, no.2, Mar. 1994). И, как и в случае с CASE, это решение теоретически могло позволить решить проблему, но на практике все оказалось далеко не так.
Формальные методы представляли собой такие методики, как сокрытие информации, структурное программирование и поэтапное улучшение. Эти методики, появившиеся и ставшие популярными в 80-х годах, по-прежнему широко применяются современными программистами, что лишний раз подтверждает их успех. Структурное программирование и ориентация на объекты несомненно полезны для создания качественного кода. Они сейчас настолько широко применяются, что являются скорее правилом, нежели исключением.
Однако строгие формальные методы никогда не будут приняты в ведущих компаниях, специализирующихся на разработке программного обеспечения. Некоторые планируют внедрить тот или иной вариант строгих формальных методов (см. David P. Kelly, Robert S. Oshana, "Integrating Cleanroom Software Engineering Methods into an SEI Level 4-5 Program", Crosstalk, Nov. 1996), но подавляющее большинство современных разработчиков считают их узкоспециализированными. Причины - несоответствие затрат и возврата от инвестиций. Формальные методы сложно использовать, они весьма ресурсоемки и часто предполагают, что программист, применяющий их, должен был иметь чуть ли не кандидатскую степень. И что самое главное, как и в 80-х годах, по-прежнему не хватает инструментальных средств, которые могли бы помочь разработчикам в реализации формальных методов.
Тем не менее, десятилетие возрождения принесло ценные идеи, касающиеся увеличения производительности разработчика. Кроме того, ученые, неутомимо создающие формальные методы, дали научному сообществу методики, которые позволяют систематизировать руководство разработкой. К концу 80-х все осознали важность практических методов программирования, и в целом изменилось отношение к требованиям, гарантирующим более высокое качество.
Следующее "решение" проблемы качества программного обеспечения появилось в 90-х годах под названием "совершенствование процесса разработки программ". Основой этого движения была теперь популярная и часто критикуемая модель Capability Maturity Model. Для краткости упростим формулировку основного принципа совершенствования процесса разработки программ: создание программного обеспечения - это задача управления, к которой можно применять соответствующие процедуры управления данными, процессами и практическими методами, с целью создания максимально оптимального решения. Управление разработкой программного обеспечения гарантирует получение более качественного продукта.
Другими словами, поскольку разработчики не могли должным образом управлять своими проектами (что исторически подтверждается весьма низким уровнем качества программного обеспечения), менеджеры должны ввести организационный контроль. Впрочем, даже самые лучшие в мире процессы можно неправильно реализовать.
Несмотря на кажущуюся легкость тона, речь идет об очень серьезных вещах. При всей неоспоримости того факта, что хорошие процессы разработки программного обеспечения, как правило, необходимы, идея совершенствования таких процессов предполагает формирование антагонистических отношений между руководством и техническими специалистами. Ситуацию усугубляет и тот факт, что многие менеджеры, которые ничего не знают о программном обеспечении, внезапно выясняют, что их опыт якобы весьма востребован в программных компаниях, где задача совершенствования процессов разработки ставится во главу угла.