Эдсгер Дейкстра: Научная фантастика и научная реальность в информатике

Моё растущее беспокойство, однако, вызывает то, что подобные проекты используют лишь часть компьютерных характеристик, и то, что они ведут к достаточно неспецифицированным продуктам, в которых исчезают другие характеристики компьютера. Расчётные программы используют способность компьютера к перемалыванию чисел, оптическое распознавание символов использует ёмкость памяти и гибкость, но в обоих случаях конечный продукт больше не является автоматом с точно установленными свойствами. Следовательно, результирующий продукт уже не является машиной в смысле информатики, и его использование сродни занятиям математикой без аксиом. Подобные расчётные программы могут использоваться лишь в контексте, в котором результат не имеет столь большого значения, либо аналитик, использующий их, располагает другими средствами для проверки ответа; подобная система оптического распознавания может применяться лишь в обстоятельствах, в которых не имеет большого значения, если, скажем, часть писем сначала отправится в неверном направлении. Мы больше не можем полагаться на такие системы, как если бы они были автоматами, и нам придётся удалять их из замкнутых циклов.

Для многих такое заключение неприемлемо, и как результат существует школа мышления — или, если вам так больше нравится, школа недомыслия, — которая утверждает, что ситуация не столь серьёзна, что нам не следует быть столь строгими, что инженеры всегда допускали периодические сбои своих компонентов, что стремление к совершенству быстро начинает препятствовать производительности, и что лучше бы нам научиться жить в реальном мире с системами и подсистемами, которые обычно делают то, что мы от них ожидаем. Это соблазнительное предложение. Разве не замечательно — достичь превосходства без гонки за совершенством?

(Тем более что в крайне популистском обществе последнее социально неприемлемо). Такова позиция, ныне принятая под знаменем «программной инженерии».

Однако то, что сторонники называют «прогрессом программной инженерии», страдает несколькими непреодолимыми противоречиями.

Одно из них — это то, что стремление к совершенству находится в противоречии с производительностью в том смысле, что сделает разработку программного обеспечения чересчур дорогостоящей. Но в чём основная причина заоблачных цен на неё? Дороже всего обходится как по людским ресурсам, так и по непредвиденным задержкам отладка, и можно немало сэкономить, вложив больше средств в предотвращение будущих ошибок, поставив разработку на первое место. Поскольку ошибки обходятся столь дорого, в конечном счёте высококачественный дизайн обходится куда дешевле. Другая важная причина состоит в том, что многие системы построены на зыбком фундаменте в том смысле, что базовое программное обеспечение в виде операционных систем и компиляторов слишком неустойчивы, поэтому каждый новый релиз этого базового программного обеспечения требует возможно дорогой адаптации базирующейся на нём прикладной части. Наконец, многие инструменты, с которыми собирается работать программист, настолько плохо документированы, что вынуждают его выяснять экспериментальным путём, чем же они могут оказаться для него полезными. Поскольку эти эксперименты могут быть весьма дорогостоящими и длительными, бедный программист оказывается в поистине незавидном положении, поскольку вынужден полагаться лишь на свои догадки. Так что вы видите здесь три основных источника роста цены, след от которых ведёт к чьему-то предположению, что стремление к совершенству противоречит производительности!

Другое противоречие в развитии инженерии программного обеспечения всплывает, как только инженер-информатик задаётся вопросом, каким образом стать лучше, как искусство, мастерство или практика инженерии программного обеспечения могут быть улучшены. Он немедленно обнаружит, что вынужден обратиться к дисциплине, которую отверг. Приняв в качестве хартии «Как программировать, если не можешь этого делать», инженерия программного обеспечения загнала себя в неприемлемую позицию, в позицию, которой информатика может избежать, лишь отказавшись от компромисса, придерживаясь своей собственной формальной дисциплины и не прикидываясь чем-то большим.

Чуть раньше я упомянул плохую документацию системы как внутреннее ограничение надёжности, с которой система может быть использована механически в более широком контексте. Теперь самое время указать, что привлечение технического писателя редко является выходом из положения; в сущности, это не более как признание того, что разработчики системы в некотором роде функционально безграмотны. Обычно даже целая армия технических писателей не может справиться с задачей, поскольку система становится столь сложной, что не поддаётся точному описанию.