Стандартная структура от Xcode - это ловушка. ContentView.swift, пара папок, и вот уже через три месяца вы не можете найти, где лежит экран настроек, потому что он затерялся среди 50 других файлов в одной куче. Чтобы проект жил долго и счастливо, нужна система. И желательно с первого дня.
Главная ошибка - группировка по типам:
Самое популярное, но неудачное решение: папки Views, Models, ViewModels. Вроде логично, но когда в Views оказывается 40 файлов, а в Models - 20, вы начинаете тратить время на поиск. Хуже того, связанные сущности разбросаны по разным местам. Чтобы понять, как работает авторизация, нужно открыть три папки и собрать пазл.
Фичевая организация - спасательный круг:
Гораздо удобнее группировать код по функционалу. Каждая фича - отдельная папка, внутри которой лежит все необходимое: вьюхи, модели, вью-модели, кастомные компоненты, специфичные для этой фичи. Если нужно поправить экран профиля, вы идете в папку Profile и видите все, что к нему относится. Никаких блужданий по проекту.
Что вынести за пределы фич:
Не все должно жить внутри фич. Есть вещи, которые используются по всему приложению:
🔵Core: сеть, хранилище, базовые сервисы. Один экземпляр на все приложение, инициализируется один раз.
🔵UI Components: переиспользуемые кнопки, поля ввода, лоадеры. Чтобы не писать один и тот же стиль в каждом экране.
🔵Theme: цвета, шрифты, отступы. Единое место, где живет дизайн-система.
🔵Extensions: полезные расширения для стандартных типов.
🔵Resources: ассеты, локализация, шрифты.
ViewModel с человеческим лицом:
Каждая вью-модель должна быть аккуратной и предсказуемой. Несколько правил:
🔵
@MainActor - чтобы не думать о потоках при обновлении UI.🔵private(set) для публикуемых свойств - никто не должен менять состояние извне.
🔵Зависимости через инициализатор - чтобы можно было подменить их в тестах.
🔵Методы, которые четко отражают действия пользователя.
Навигация без боли:
Для простых приложений хватает встроенного NavigationStack с navigationDestination. Когда экранов становится много, стоит задуматься о координаторе. Один класс, который управляет всей навигацией в приложении - это сильно упрощает жизнь, особенно когда нужно передавать данные между экранами или обрабатывать диплинки.
Главное - последовательность:
Любая структура работает, если ей следовать. Хуже всего кога часть кода лежит по фичам, часть - по типам, часть - вообще в корне. Выберите один подход и придерживайтесь его от начала до конца. Новые разработчики в команде скажут спасибо.
🔗 Ссылка на подробную статью
💡 Вывод:
Организация проекта - это не про «красивую структуру», а про скорость разработки и стоимость поддержки. Когда на поиск нужного файла уходит 10 секунд вместо 5 минут, когда новая фича не ломает старую, когда код понятен даже тем, кто видит его впервые - это и есть правильная архитектура. А начинается она с правильной структуры папок.
➡️ Подписаться на канал
Мобильный трудоголик