Сегодня в России разработка крупных программных комплексов находится где-то на границе Programming in Small и Programming in Large (ремесла и мастерства), потому что, даже если в процессе их создания и используются мощные средства автоматизации программирования, бо’льший объем рабочего времени по-прежнему тратится на кодирование и отладку. Дело в том, что заказчик обычно сам точно не знает, что же он хочет в конечном счете получить, а расходовать деньги на computer consulting он (по крайней мере, сегодня) совершенно не настроен. Обычно заказчик стремится поскорее получить некое законченное решение, которое его, вероятнее всего, совершенно не устроит и за которое он откажется платить. Но нередко компания - системный интегратор получает достаточно четко продуманное техническое задание, на базе которого разрабатываются все спецификации и строится работающая система. Но после ее завершения заказчик заявляет: "А вот хорошо бы добавить в программу крохотную дополнительную возможность" (чтобы совершенствовать готовую систему по своему усмотрению), считая, что подобное пустяковое пожелание не потребует от разработчиков больших усилий. Но любой программист знает, что внесение изменений в тщательно продуманный и "заточенный" под конкретную задачу программный код обычно требует очень больших усилий по реализации этого изменения. Как правило, это выражается в появлении непредвиденных логических ошибок (в лучшем случае) или в необходимости проведения чуть ли не полного пересмотра структуры программы, если декомпозиция исходной задачи проводилась "от данных" (в худшем случае). Но в любом случае, когда проект создается профессиональными разработчиками, конкретные части кода обычно настолько "вылизаны", что внесение в них изменений вступает в противоречие с психологическими аспектами построения соответствующих логических элементов (Programming in Small), что было экспериментально подтверждено специалистами, занимавшимися исследованиями процессов мышления программистов. Получается, что подчас легче реализовать "невинное" дополнение заказчика, переделав всю программу заново.
Сегодня хорошо известные на российском рынке компании нередко с гордостью заявляют о том, что очередная версия их продукта "была полностью переписана". Но не говорит ли это скорее о плохо продуманной общей идеологии программы?
Более того, как показывает статистика, от 60 до 80% всех ошибок, обнаруженных в программе, приходится на ошибки проектирования. Не исключено, что и ошибки этапа Programming in Small на 100% являются косвенным (или прямым) следствием этих первичных ошибок.
Поэтому качество разработки общей идеологии проекта вроде бы выходит на первый план. Билл Гейтс достаточно давно заявлял, что все современные технологии программирования сводятся к одному - оттянуть (хоть за уши) разработчиков от компьютера и заставить их более тщательно продумывать структуру программы в целом.
Однако получается парадокс: чем больше времени отводится на этап проектирования и чем более объемным он становится, тем больше возникает на этом этапе ошибок, приводящих в дальнейшем к катастрофическим последствиям. (Конечно, если считать выражение "в каждой программе есть хотя бы одна ошибка" аксиомой.)
В крупных проектах все заранее продумать невозможно, так уж устроено наше с вами "серое вещество". Но даже если довести качество компьютерной модели проекта до 99,9%, то любое будущее пожелание заказчика о внесении изменений в программу (начиная от IDEF-описания и кончая кодированием и дополнениями в документации) способно резко снизить общую надежность программного продукта.
Выход из тупиковой ситуации подсказывает Ховард Шроуб, о котором недавно писал наш еженедельник. Он предложил вниманию публики так называемую эволюционную модель разработки приложений, когда "не должно быть разницы между процессами разработки и поддержки" программных комплексов.
Но практически все сегодняшние CASE-системы и системы проектирования программных продуктов сверхвысокого уровня пока являются прямой противоположностью идеям Шроуба. Основной акцент в них сделан на статическое ви’дение задачи и быструю ее реализацию с помощью набора готовых программных компонентов. Возможность гибкой и, главное, объемной модернизации без полного переписывания всего проекта пока остается за бортом этих систем.
К сожалению, для многих отечественных компаний и групп разработчиков все эти проблемы лежат пока "по ту сторону добра и зла". Не говоря уже о ничтожно малом количестве реально используемых CASE-систем (ну ладно, они довольно дороги) и доморощенных способах тестирования - исходя лишь из личного опыта (если серьезное тестирование проводится вообще!), много ли вы знаете программистов, использующих верификаторы для анализа своего кода? Недаром Дейкстра, основоположник структурного программирования, говорил: "Сколько не тестируй программу вручную, результаты такой проверки программы никогда не докажут отсутствие в ней ошибок". А хорошие верификаторы могут это сделать! Конечно, речь не идет о выявлении смысловых неточностей, хотя не исключено использование верификаторов и на уровне абстрактных описаний проекта.
Хорошие Шроуб-системы вряд ли появятся достаточно быстро, хотя бы просто из-за отсутствия на сегодня приличной теоретической базы. Но не так уж все плохо в программистском королевстве. Новое поколение программных продуктов должно строиться на следующем прекрасном утверждении - "программы без ошибок есть". Или, по крайней мере, будут!
Сергей Бобровский
