Разрабатывая приложения многие разрабы начинают с выбора архитектур UI слоя. Это ошибка.
Иногда перечитываю не полностью книги, а отдельные главы. Решил перечитать главу "UI Principle 2: UI architectures come and go" книги "Mobile System Design". Мне очень нравятся мысли и подходы книги и некоторые из них лучше переваривать порциями.
Например, я разделяю мнения, что к UI нужно подходить в конце. Сначала нужно уделить времени другим вещам. Даже автор книги подшучивает что про UI начали говорить только в середине книги.
Автор говорит:
Обычно под словом “архитектура” в мобильной разработке имеют в виду UI-архитектуру, а не архитектуру бизнес-логики (например, API, календарь и т.д.). Но если правильно спроектировать фичу, эти вопросы становятся менее важными. Мы научимся разделять UI и бизнес-логику так, чтобы можно было менять архитектуру без боли.
1️⃣ Первый принцип книги говорит: Откладывай реализацию UI
2️⃣ Второй принцип говорит: UI-архитектуры приходят и уходят
На этом этапе ты можешь задуматься:
“Какую архитектуру выбрать?”
- UIKit или SwiftUI?
- XML или Jetpack Compose?
- MVVM, MVC, MVI, Redux, TCA или вообще что-то своё?
Все эти аббревиатуры часто просто вариации одного и того же. Главное в разработке — не усложнять. Не нужна архитектура из шести букв, чтобы просто показать аватарку пользователя. Используй "модную" архитектуру только если простая не справляется.
Главная суть: Архитектуры как способ договориться внутри команды. Нет критической разницы если одна команда использует в своем модуле MVP, а другая VIPER. Ведь по сути все это одно и то же.
Автор ругает сторонние архитектурные фреймворки за частые изменения, сложность изучения новичкам, миграции в будущем (привет, TCA).
Люди пытаются проблемы процессов команды решить с помощью универсального шаблона. А ведь проблема не в архитектурах. Чаще всего любая архитектура подходит вашему проекту, просто нужно налаживать процессы:
- улучшить документацию
- добавлять примеры
- улучшать онбординг
- убирать плохие практики кодревью
Не нужно переживать, что выбрал "неправильную" архитектуру. Тренды постоянно меняются. Главное правило любой хорошей архитектуры — не усложнять и держать бизнес-логику вне UI.
Не стоит также переживать, что архитектура отличается по приложению и есть старые версии. Это нормально.
Это нормально, когда приложение состоит из разных архитектур, каждая из которых появилась в разное время. Но у них есть общее: Бизнес-логика меняется реже, чем UI.