Одна маленькая правка потребовала изменений в пятнадцати местах

Задача выглядела простой: добавить новый статус заказа.

Разработчик рассчитывал справиться за час. Потом выяснилось, что статус нужно учесть в API, валидации, уведомлениях, отчетах, правах доступа и еще в десятке условий по всему проекту.

Одно место пропустили — клиент получил уведомление по уже отмененному заказу.

Проблема не в количестве файлов. Изменение публичного контракта действительно может затронуть несколько слоев. Тревожный сигнал — когда одно бизнес-правило скопировано в пятнадцать мест и разработчик должен помнить их все.

Так часто происходит из-за флагов

В объект добавляют:

isPaid
isCancelled
isRefunded

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

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

Код работает. Но каждое изменение становится дороже предыдущего.

А разве AI не может исправить все места?

Может найти похожие условия и быстро внести правки. Но AI не всегда знает, какое правило автор проекта держал в голове и какие связи не описаны в коде.

Он может одинаково исправить четырнадцать мест и пропустить пятнадцатое. Или добавить новую проверку поверх старой модели и сделать систему еще сложнее.

Скорость редактирования не исправляет архитектуру.

Что делает инженер

Он не начинает с поиска всех if. Сначала выясняет:

— где должно жить бизнес-правило;
— какие состояния действительно допустимы;
— какие переходы между ними разрешены;
— можно ли выразить это одной моделью или таблицей переходов;
— как проверить правило в одном месте.

После этого пятнадцать разрозненных условий превращаются в один источник правды и несколько понятных вызовов.

Хороший признак архитектуры — изменение приходится вносить там, где живет соответствующее решение. Плохой — нужно обойти весь проект и надеяться, что ничего не забыли.