🏗️ Гибкая архитектура 🏗️

Мне очень откликнулась статья с Хабра "Код, не боящийся изменений". Не ко всем проектам это применимо. Но для длинных проектов из геймдева, где сегодня можно начать фермой, а через год закончить пост-апокалиптическим шутером, я нахожу всё описанное очень актуальным.

Также этот материал отлично дополнил мои заметки по Гибкой Архитектуре. Приправив этот мэшап своими комментариями, я собрал коллекцию карточек по теме. И ещё немного доработал свой конструктор карточек.

📌 Особо важным я нахожу раздел про дублирование. Почему-то у разработчиков есть неудержимая тяга к избеганию любого маломальского дублирования. Порой до фанатизма: на уровне простой последовательности символов. Это зачастую приводит только к бóльшим проблемам, увеличению ненужных связей и сложностям в поддержке.

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

Гибкая архитектура — это не паттерн и не фреймворк. Это представление об архитектуре, к которому разработчик или команда могут сознательно стремиться (или сознательно не стремиться).

Это не готовые практики, а концепция и набор критериев, влияющих на все принимаемые решения в процессе разработки. Степень влияния этих критериев индивидуальна не только для разных продуктов и команд, но и для разных этапов одного и того же продукта.

Самый важный критерий — скорость внесения изменений. Этот критерий нам, если хотим следовать концепции Гибкой Архитектуры, нужно максимизировать. Для этого необходим баланс между косвенными критериями.

Невозможно все критерии просто выкрутить на максимум. Каждый из критериев будет обязательно влиять на другие. И попытка максимизировать один может дать просадку по другому. Но на общую Эволюционность будет влиять именно их комбинация.

Баланс придётся постоянно регулировать, потому что критерии сильно зависят от субъективных факторов — экспертизы команды, особенностей проекта, пайплайнов, сроков и т.д. Это отличается от продукта к продукту и постоянно меняется. А значит и постоянно нарушается баланс критериев, что может повлиять на эволюционность, в т.ч. негативно.

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

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

И, хотя чрезмерно низкая связанность, как критерий гибкой архитектуры, не вредит гибкости (чем ниже, тем гибче), это будет верным, только если абстрагироваться от других критериев и практического значения.

Когда в процесс включается человек, слишком низкая связанность сильно повышает когнитивную сложность и бьёт по ясности, читаемости и скорости рефакторинга. И по мере роста кодовой базы эти критерии становятся более важными для поддержания Эволюционности.

Не всегда требуется построение Гибкой Архитектуры. Например, джемы, маленькие быстрые проекты, прототипы, разработка в одиночку, фиксированные проекты "под ключ". Или разработка через AI-агентов.

Для LLM важны спецификации и контекст. Им удобнее, когда архитектура проста, а код написан "в лоб", прямолинейно и задокументировано. С минимальным кол-ом абстракций.

Машине чужды критерии читаемости, переиспользования и прочего. Некоторые модели так и вовсе переиспользовать что-то умеют очень плохо. AI важно, чтобы компилятор принял правки, а тесты прогнались. Всё остальное — фактор человека, который не готов полностью делегировать ответственность за написанный код машине и хочет понимать, что делает LLM.

Чем больше человек готов довериться LLM, тем меньше для него значимы критерии Гибкой Архитектуры. LLM при должном оперировании способна сохранять скорость внесения изменений на примерно одном уровне. Ей зачастую вообще даже проще просто всё переписать, чем пытаться подстраиваться. Это только вопрос цены.

#development #gamedev #architecture #карточки #рекомендация #статья