Хороший код ≠ хорошая архитектура.
Часто в команде всё выглядит прилично: код ревью пройдено, багов мало, фичи едут. Но через 2–3 года открываешь старую форму — и вместо понятной схемы видишь «слоёный пирог» из костылей, условий и побочных эффектов.
Как это обычно случается:
1. Сначала делают быстро, чтобы запуститься.
2. Потом «временно» добавляют ещё одну проверку.
3. Потом ещё одну интеграцию.
4. В итоге логика размазывается по компонентам, хукам, сервисам и утилитам.
Что происходит на практике:
- один файл начинает отвечать сразу за валидацию, отправку, форматирование и аналитику;
- бизнес-правила дублируются в 3–4 местах;
- любое изменение требует ручной проверки цепочки зависимостей;
- новый разработчик тратит часы не на задачу, а на расшифровку чужих решений.
Главный маркер плохой архитектуры — не размер файла, а стоимость изменения. Если маленькая правка ломает соседние части системы, архитектура уже работает против команды.
Полезный вопрос для ревью: «Это место можно понять и изменить за 10 минут без страха что-то сломать?» Если нет — значит, проблема не в коде, а в его устройстве 🛠️
PR Lab
@PRLabPro