🔒Открыть пост
и посмотреть медиа
и посмотреть медиа
Антипаттерн: "Сначала MVP — потом нормальная схема"
Частая ошибка при старте проекта — отложить продумывание структуры базы «на потом»:
«Сейчас сделаем быстро MVP, а потом приведём БД в порядок».
И вот что часто происходит:
– MVP превращается в продакшн без переработки схемы.
– Костыли начинают множиться.
– Появляется технический долг, который сложно погасить: миграции становятся болью, связи — запутанными, а данные — ненадёжными.
Типичные симптомы:
— nullable-поля без нужды
— дублирование данных
— универсальные таблицы вроде entities или attributes
— "магические" значения в enum-полях
— отсутствие внешних ключей и индексов
Как избежать:
1. Минимум нормализации — с самого начала. Даже для MVP важно заложить понятную структуру.
2. Используй миграции сразу. Даже если это скрипт в папке migrations/, а не полноценный tool.
3. Заведи ER-диаграмму. Она не обязана быть идеальной, но уже поможет избежать хаоса.
4. Смотри в будущее. Планируешь рост? Подумай о расширяемости схемы.
5. Не стесняйся рефакторить. Лучше на раннем этапе изменить структуру, чем через год бояться сломать прод.
👉 MVP не должен значить "без архитектуры". Плохая схема — это замедление развития и боль на каждый новый фичереквест.
♻️ Сделай репост, чтобы помочь другим.
📲 Мы в MAX
👉 @Bookflow
