Синдром божественного объекта и нарушение единой ответственности
Это классическая ловушка. Божественный объект может содержать тысячи строк кода, выполняя парсинг, валидацию, работу с базой и отправку уведомлений. Для джуна такой класс — источник ужаса. Он боится изменить одну строку, не понимая, как это повлияет на не связанные модули. Вместо решения бизнес-задач новичок тратит дни на реверс-инжиниринг, пытаясь нащупать границы ответственности там, где их нет. Такой код невозможно безопасно модифицировать, а любые изменения порождают регрессионные баги.
Преждевременная абстракция и оверинжиниринг
Желание предусмотреть все варианты развития событий на годы вперед приводит к созданию чудовищных конструкций. Джуну ставят задачу добавить одно поле, но из-за переусложненной архитектуры ему приходится создавать новый интерфейс, реализовывать его в трех фабриках и обновлять абстрактные стратегии. Оверинжиниринг убивает продуктивность. Начинающие разработчики мыслят итеративно. Когда вы заставляете их проходить через десять слоев абстракций ради простейшего действия, вы парализуете команду. Код превращается в лабиринт из ненужных паттернов.
Скрытые зависимости и магия глобального состояния
Ничто так не демотивирует джуна, как невозможность отследить поток выполнения. Скрытые зависимости, синглтоны, изменяющие глобальное состояние, и методы, которые помимо возврата значения очищают кэш и отправляют письмо, создают иллюзию магии. В такой архитектуре нет явных контрактов. Джун вызывает функцию, ожидая предсказуемого результата, но получает каскад побочных эффектов, ломающих систему. Отсутствие явной инъекции зависимостей делает отладку кошмаром. Новичок не может построить ментальную модель приложения, потому что связи скрыты в недрах вызовов.
Расползание бизнес-логики по слоям инфраструктуры
Анемичная доменная модель, при которой сущности — лишь набор геттеров и сеттеров, вынуждает искать правила бизнеса где угодно. Логика расчета скидок и валидации размазывается по контроллерам, сервисам и репозиториям. Для джуна это полная потеря ориентации. Когда поступает задача изменить правило начисления бонусов, он не знает, куда смотреть, и будет искать ответ в слоях представления. Такая архитектура не имеет четкого центра тяжести, что делает рефакторинг процессом, требующим знания всей кодовой базы наизусть.
Умный код вместо понятного и отсутствие контекста
Сеньоры часто пытаются написать код максимально компактно, используя сложнейшие цепочки вызовов и хитрые регулярные выражения. То, что кажется элегантным автору, становится непроходимым лесом для джуна. Умный код требует огромных когнитивных затрат на расшифровку намерений. Хуже того, если к такому коду не приложены комментарии, объясняющие, почему было принято нестандартное решение, джун просто сломает его при первом рефакторинге. Архитектура — это не только структура файлов, но и читаемость намерений, ведь код читается чаще, чем пишется.
Хорошая архитектура всегда эмпатична. Она создана для людей, которые будут поддерживать ее после вас. Если ваш код отторгается начинающими разработчиками, это верный сигнал о том, что вы усложнили систему сверх меры. Истинное мастерство заключается не в том, чтобы написать код, который поймете только вы, а в том, чтобы создать среду, в которой даже новичок сможет уверенно приносить пользу бизнесу.
