Очень-очень краткая история вопроса, или зачем вообще понадобилось писать «Сквозь дебри проектирования»?
На этот вопрос Роман Зайруллин отвечает в предисловии к первой версии своего путеводителя для программистов.
На ранних этапах развития компьютеров и дисциплины программирования, процесс разработки связывался, в первую очередь, с навыками построения алгоритмов. Это прослеживается в публикациях Эдгара Дейкстры, Николауса Вирта, Дональда Кнута.
Первый «сторонний» заход на проблему описал Николаус Вирт в книге «Систематический подход к программированию». Зафиксированный в ней подход к разработке, через расширение возможностей вычислительной машины, вошёл в историю, как «подход сверху-вниз». Однако, фокус всё ещё оставался на разработке алгоритмов в пределах одной вычислительной системы и не покрывал разработку комплексных систем.
Фредерик Брукс в книге «Мифический человеко-месяц» попытался перейти уровень комплексных проектов, но больше с уклоном в сторону организации работы команды программистов. Так что множество проблем и вопросов по-прежнему оставались открыты.
С позиции проектирования программных систем большой вклад внёс Алан Кей, принеся ряд важных идей о дизайне вычислительных процессов из биологии. Однако по совершенно нелепой (полу)случайности произошла подмена понятий. Не без помощи ошибок в дизайне С++ и, в последствии, Java. Из-за чего под «объектной ориентированностью» стали пониматься не работы Кея, а более старая концепция типов абстрактных данных (abstract data types), появившаяся как надстройка над процедурным программированием. Это впоследствии аукнется ещё не раз.
Ряд системных эффектов и закономерностей были известны в кибернетике – они перешли в программирование через искусственный интеллект.
Классические работы по ИИ (Марвин Мински, Патрик Генри Уинстон), помимо прочего, активно концентрировались именно на способах репрезентации задачи. Но это были скорее советы и точечные рекомендации, нежели стройная процедура, и основная масса знания оставалась «в мышечной памяти» разработчиков алгоритмов и агентов. Основным передатчиком знаний между ИИ и разработкой клиентского софта на долгое время станет сообщество, сформировавшееся вокруг Lisp и его диалектов. Позже, в 2010-х, роль поставщика умных идей возьмёт на себя сообщество Haskell – однако, завязнет в специфичных для хаскеля программизмах и потеряет связь с задачами.
Надо отметить, что хоть и обсуждения в сообществе программистов свелись к дебатам вокруг типизации и изоляции побочных эффектов, это породило большое количество неплохих популярных материалов по теории категорий, вопросам построения цепочек обработки данных и т.д. Осталось только направить все эти знания в продуктивное русло.
Но вернёмся назад, во времена, когда С++ набрал своих первых адептов, а где-то на горизонте замаячила Java.
В это время лицом к задаче повернулась и «бытовая» разработка. Правда, это выльется в попытки натянуть все области на программистские термины и компьютерообразные суждения. Любые описанные процедуры по формализации условий задач были, мягко говоря, слабо применимы. Но тем не менее, именно с этого момента (~ середина 1990-х) множество исследований начинают обращаться к проблемам построения репрезентаций задач, и специалисты все чаще употребляют термин «Domain model».
Появляются конференции по системному анализу в разработке программных продуктов. В 2000-х публикуется ряд книг, посвящённых теме. Ряд авторов-практиков пытается формализовать отношения между задачей и кодом, – с переменным успехом, – и именно тут расцветает терминологическое разнообразие. Основной фокус смещается в сторону разработки DSL. Но возникает ошибочное представление, будто процесс моделирования работает только в том случае, если речь идёт о DSL, и для «бытового» программирования результаты просто игнорируются.
Затем ситуация несколько изменилась. Следующая волна интереса среди рядовых разработчиков поднимется после статьи (а потом и книги) Эрика Эванса “Domain Driven Design”. Однако, процедурная составляющая была несколько слабой и вся работа скорее напоминала попытку направить интуицию разработчиков в нужное русло. Это породило недопонимание: программисты приняли подход как парадигму и пытались «внедрять DDD», разочаровывались и забрасывали тезисы Эванса. Якобы, подход нерабочий.
Тогда же к задачам попытается вернуться и сообщество Haskell, копируя рассуждения и рекомендации Эванса, по сути просто заменив классы Java на алгебраические типы F#, Scala и Haskell, но споткнется о те же проблемы.
В разработке скопилась критическая масса прецедентов, ошибок и идей, и как с переохлажденной жидкостью, достаточно легонько тряхнуть колбу, и жидкость моментально превратится в кристалл. Появление этой книги было неизбежно, и во всех возможных вариациях событий менялся бы только автор и год, когда книга увидит свет.
