Фраза «потом перепишем» редко является техническим планом. Когда продукт доказывает ценность, команда уже обслуживает клиентов, защищает выручку и выполняет обязательства. Переписывание начинает конкурировать именно с возможностями, которые создал первый релиз.
Это не значит, что раннему продукту нужна сложная архитектура. Код должен ясно выражать предметную область, автоматически проверять критические правила и оставлять заменяемые границы вокруг решений, которые, вероятно, изменятся.
Измеряйте стоимость изменений
Качество кода видно во времени поставки, числе дефектов и объёме координации для небольшого изменения. Система становится дорогой, когда инженеры заново открывают правила, затрагивают несвязанные области или зависят от ручных ритуалов релиза.
Полезные практики должны быть соразмерны: типизированные контракты на границах, тесты бизнес-инвариантов, наблюдаемость продакшена и короткая документация неочевидных решений.
Стройте для второго года
Цель — не абстрактное совершенство, а способность реагировать на новые знания о продукте. Тактические компромиссы допустимы, когда их влияние явно, ограничено и записано.
Поддерживаемость — продуктовая возможность. Она определяет, насколько быстро команда превращает новые данные в более безопасный и полезный опыт.
