Flutter и fullstack Dart в реальной разработке —
без занудства и ненужных абстракций.
Архитектура, практические приёмы, разборы кода.
Для Flutter-разработчиков, которые хотят увереннее чувствовать себя в реальных проектах
💬 @dartway_dev_ru_community
Post #105
355
После прошлого поста про архитектуру — хочу дать свой ответ 👀
Без книжных определений и «Clean/SOLID/DDD bingo».
Архитектурное решение — это осознанный выбор варианта реализации с пониманием его плюсов и минусов.
Из этого следует важный вывод:
— чтобы принять архитектурное решение, нужно знать хотя бы 2 способа решения задачи.
Если вы знаете только один подход — выбора у вас нет.
А значит, и архитектурного решения тоже.
Тогда что такое удачное архитектурное решение?
Это решение, которое подтвердило свою разумность в процессе развития продукта:
его преимущества действительно помогли;
а недостатки не стали критичными.
И тут появляется ещё один важный вывод:
— хорошая архитектура всегда связана с прогнозированием.
Нужно пытаться понять:
что будет меняться;
где появится сложность;
что точно не понадобится;
какие компромиссы сейчас выгодны, а какие создадут проблемы через полгода.
А архитектура приложения?
Это просто совокупность архитектурных решений, принятых в проекте.
Не папки.
Не паттерны.
Не модные названия.
А именно решения и компромиссы.
И отсюда, наверное, главный вывод:
если решения принимались неосознанно —
без понимания альтернатив,
без анализа последствий,
без взгляда в будущее,
то это уже не архитектура.
Это будущее легаси, с которым команде рано или поздно придётся столкнуться 🙂
Без книжных определений и «Clean/SOLID/DDD bingo».
Архитектурное решение — это осознанный выбор варианта реализации с пониманием его плюсов и минусов.
Из этого следует важный вывод:
— чтобы принять архитектурное решение, нужно знать хотя бы 2 способа решения задачи.
Если вы знаете только один подход — выбора у вас нет.
А значит, и архитектурного решения тоже.
Тогда что такое удачное архитектурное решение?
Это решение, которое подтвердило свою разумность в процессе развития продукта:
его преимущества действительно помогли;
а недостатки не стали критичными.
И тут появляется ещё один важный вывод:
— хорошая архитектура всегда связана с прогнозированием.
Нужно пытаться понять:
что будет меняться;
где появится сложность;
что точно не понадобится;
какие компромиссы сейчас выгодны, а какие создадут проблемы через полгода.
А архитектура приложения?
Это просто совокупность архитектурных решений, принятых в проекте.
Не папки.
Не паттерны.
Не модные названия.
А именно решения и компромиссы.
И отсюда, наверное, главный вывод:
если решения принимались неосознанно —
без понимания альтернатив,
без анализа последствий,
без взгляда в будущее,
то это уже не архитектура.
Это будущее легаси, с которым команде рано или поздно придётся столкнуться 🙂
- ❤ 1
- 👍 1
