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

Хочется сразу сделать правильные границы модулей, универсальные протоколы, хороший DI, покрыть всё тестами и предусмотреть развитие на несколько шагов вперёд.

С инженерной точки зрения это выглядит логично. С продуктовой — не всегда.

Представим: нужно проверить новую механику, и пока никто не знает, будут ли ей вообще пользоваться.

Есть два варианта:

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

Второй — аккуратно встроить минимальное решение в существующую систему и выпустить его за три дня.

Если через неделю окажется, что функция пользователям не нужна, первый вариант станет технически красивым способом потратить лишнее время команды. Проблема не в «плохой архитектуре». Мы просто оптимизировали систему под будущее, которое ещё не наступило.

Архитектура тоже имеет стоимость

Мы хорошо считаем технический долг, но реже — стоимость архитектурной сложности. Каждая новая абстракция — это код, который нужно написать, проверить, объяснить, поддерживать, изменять, а иногда и удалить. Поэтому вопрос должен звучать не только «как сделать правильно?», но и «насколько правильным это решение должно быть сейчас?».

Быстро — не значит плохо

Быстрое решение может быть понятным, тестируемым, безопасным и легко удаляемым. Оно просто не обязано решать проблемы, которых пока нет. Если сегодня у нас один источник данных, не всегда нужно сразу проектировать систему под пять providers только потому, что когда-нибудь они могут появиться. Качество решения определяется не количеством слоёв, а тем, насколько оно соответствует текущим ограничениям продукта.

Когда я бы выбрал быстрое решение

- Когда проверяется гипотеза и важнее быстрее получить реальные данные. - Когда цена ошибки невысока. - Когда решение легко обратимо: его можно заменить без сложных миграций, изменения публичного API и переписывания половины приложения.

А когда «быстро» уже опасно

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

Здесь сегодняшнее «потом переделаем» легко остаётся в продукте на годы. Неудачный UI можно переписать относительно спокойно. Неправильную модель хранения миллионов объектов — уже нет.

Для меня ключевой критерий — обратимость Перед реализацией полезно спросить: - Что будет, если через месяц мы решим всё удалить? - Насколько дорого изменить решение? - Мы знаем, что функция будет развиваться, или только предполагаем? - Какова цена ошибки? - Что сейчас дороже для продукта: технический долг или задержка релиза?

Эти вопросы часто определяют архитектуру лучше, чем выбор между MVVM, MVI или Clean Architecture.

AI всё сильнее смещает роль разработчика от «написать код» к «принять правильное решение». И последствия этих решений гораздо шире кода: они влияют на сроки, стоимость разработки, пользовательский опыт и бизнес-результат. Поэтому разработчику всё сложнее оставаться только внутри своей технической зоны ответственности.

Иногда правильно потратить дополнительную неделю на фундамент. Иногда — выпустить за два дня, получить данные и через месяц удалить половину написанного.

В продуктовой разработке идеальная архитектура — не цель сама по себе. Цель — дать достаточно ценности сегодня и не создать неприемлемую стоимость завтра.