Разрыв
by Дядя Боб
Наиболее остро проблема проявляется в том, что большинство существующих фреймворков и инструментов проектирования программ сосредоточены на управлении синтаксическими конструкциями, часто игнорируя более глубокие уровни семантического содержания. Эти фреймворки могут быть эффективны для выполнения технических задач, но они не дают разработчикам средств для чёткого выражения намерений и смыслов, стоящих за функциональностью системы. Результатом становится пропущенное звено между тем, что программа “делает” и тем, что она “означает”. Программисты вынуждены адаптировать своё мышление к ограничениям инструментов и языков, которые по своей природе не обеспечивают достаточной гибкости для выражения смыслов и концептуальных связей.
Большинство фреймворков предлагает разработчику готовые конструкции для решения типичных задач, что на первый взгляд облегчает процесс программирования. Однако, когда дело касается проектирования систем с более сложной и изменчивой логикой, такие подходы начинают проявлять свои ограничения. Фреймворки, построенные вокруг заранее заданных шаблонов, диктуют разработчику синтаксис и архитектуру, не позволяя гибко адаптировать систему под уникальные требования задачи. Это приводит к тому, что разработчик вынужден “подгонять” реальную проблему под существующие инструменты, что может порождать неоптимальные или некорректные решения.
Существующие подходы, будучи сильными в формализации синтаксических аспектов, оказываются слабыми в области семантического проектирования. Для того чтобы эффективно решать современные задачи программирования, требуется подход, который учитывает не только формальные правила языка, но и смыслы, определяющие поведение системы. Такой подход должен быть основан на концептуальной схеме, которая бы связывала синтаксис программы с её семантикой, и предоставляла разработчику возможность осмысленного взаимодействия с программируемыми сущностями.
Мы можем, конечно вытащить из кода дерево модулей или в терминале можно вызвать команду tree и вытащить структуру из файлов и директорий, хотя бы на самом общем уровне. Но в реальности у нас часто смешиваются концепты предметной области и способы их реализации. Другими словами, если мы возьмем дерево модулей из кода проекта и преобразуем в mindmap, то он будет засорен словами вроде модель, репозиторий, декоратор или сериалайзер. А многих слов, которые мы произносим, говоря о проекте, там не окажется. Поэтому структура нашего кода не всегда становится идеальным отражением нашей предметной области. Мы сможем угадать знакомый фреймворк, но не всегда поймем суть проекта. Об этом писал еще дядя Боб, в посте о чистой архитектуре.
В процессе разработки программного обеспечения мы сталкиваемся с “вавилонской проблемой”, когда члены команды, используя разные термины и понятия, перестают понимать друг друга. Также мы сталкиваемся с проблемой “невидимого слона”, когда исследуем легаси проекты. Это приводит к разрыву между кодом и его смыслом, что в итоге мешает успешной реализации проекта. Для преодоления этой проблемы необходимо создать концептуальную схему на основе общего языка, которая будет использоваться всеми участниками проекта. Этот язык, или “ubiquitous language”, был предложен Эриком Эвансом в контексте Domain-Driven Design (DDD). Эванс подчеркнул важность создания единого словаря, который был бы понятен как разработчикам, так и бизнес-экспертам, чтобы устранить разрывы в коммуникации и облегчить понимание предметной области. Но нам нужны еще семантика и структура, которую рассмотрим дальше.
разрыв семантика синтаксис слон вавилон язык