Как перестать беспокоиться и начать проектировать

Занимаюсь темой управляемой моделями разработки (Model Driven) в индустриальной софтостроительной практике уже более 10 лет с разными системами, включая собственную Genie Lamp. Если учесть различные генераторы отчетов и запросов на базе метаописаний или генерацию программ на базе семантической сети, то все 20. На основании опыта, подтвержденного коллегой по цеху, складывается следующие выводы о проблемах использования технологии.

В повседневную практику с трудом внедряются элементы автоматизации технологических операций, но управление моделью практически всегда натыкается на недостаток квалификации разработчиков.

Даже не выходя за рамки собственно технологий софтостроения, использование model-driven-технологий встречает препятствия, связанные с неумением работать с абстракциями выше, чем линейный код и его структурированные отображения в инструментальных средах.

Поднимаясь на уровень моделей предметной области, дело принимает какой-то уж совсем обреченный характер, упираясь уже в компетенции заказчиков. Собственно, целая глава "Программная фабрика: дайте мне модель, и я сдвину Землю" в книге посвящена этому вопросу, ответов на который пока не вижу. Наоборот, ситуация в отрасли в среднем ухудшается, число работников без профильного образования растет. Минимальный же срок подготовки системного аналитика - 10 лет, включая учебу в вузе.

Технологии меняются часто. Если 10-20 лет назад была возможность врабатываться в неё лет пять, а теперь за этот срок технология вся целиком меняется и необходимо начинать снова "с нуля". Для этого необходимо фундаментальное образование, поскольку "понимание некоторых принципов заменяет знание множества фактов". Относительный процент обладателей такового в отрасли падает (дорого). Остальным приходится осваивать по принципу "здесь бери больше, туда кидай подальше, под проводом не стой, бензин водой не разбавляй". Отсюда низкое качество разрабатываемых программных систем.

Подход разработки от моделей model-driven как раз и призван уберечь от затрат на обучение технологиям, которые изменятся (чаще просто будут выкинуты на свалку) через 2-3 года. Процесс создания программного обеспечения концентрируется вокруг моделей, сменилась технология - заменили кодогенераторы, все опять заработало.

Но для работы на таком уровне абстракции большинство разработчиков не готово ни морально, ни интеллектуально.

Что требуется для моральной и интеллектульной подготовки разработчика помимо желания?

На само деле, не нужно быть семи пядей во лбу. Образования с лихвой хватит профильного (АСУ, системотехника ЭВМ), нужны начальные навыки работы с CASE-инструментарием, понимание сути и роли моделей и метаданных. Морально: не сомневаться, что "какие-то картинки и стрелочки" могут генерировать работающий код хорошего качества.

За рамками остается организация процесса. Процесс по-настоящему гибкий в этом случае, любое изменение модели сразу приводит к изменению в программной системе. Отпадает необходимость в модульном тестировании. В упомянутой главе книги также затронуты эти вопросы в качестве начала дискуссии.