Консультирование по архитектуре мобильного приложения
Архитектурные ошибки дорого стоят не в момент принятия решения — а через 6–12 месяцев, когда скорость разработки упала вдвое, а новый разработчик тратит неделю чтобы понять как добавить новый экран.
Типичные ситуации, с которых начинается консультация
«Мы хотим добавить офлайн-режим» — а приложение написано без слоя абстракции над сетью, ViewModel'ы напрямую вызывают URLSession/Retrofit, кеш не предусмотрен. Добавить офлайн — значит переписать треть приложения.
«У нас slow build time» — монолитное приложение без модуляризации компилируется 8 минут при каждом изменении. Developers/день тратят 30–40 минут на ожидание сборки.
«Хотим добавить второй таргет/flavour» — для белого лейбла или второго бренда, но кодовая база не разделяет бизнес-логику и бренд-специфику. Всё перемешано в одном таргете.
«Онбординг нового разработчика занимает три недели» — отсутствие явной архитектуры, магические зависимости через статические синглтоны, неочевидные side effects.
Что даёт архитектурная консультация
Не «давайте перепишем всё на Clean Architecture». Анализ текущего состояния → выявление конкретных узких мест → рекомендации с оценкой трудозатрат и рисков → дорожная карта изменений.
Для iOS: оцениваем разделение на слои (Presentation / Domain / Data), использование Swift Concurrency против Combine против callbacks, модуляризацию через SPM vs CocoaPods, тестируемость (можно ли написать unit-тест на UseCase без запуска симулятора).
Для Android: Clean Architecture с domain/data/presentation модулями, Hilt vs Koin vs manual DI, ViewModel lifecycle, корутины и Flow в репозиторном слое, Jetpack Navigation для deep linking.
Для Flutter: BLoC vs Riverpod vs GetX — не выбор «что лучше», а соответствие команде и задаче. Riverpod 2.x с code generation — меньше boilerplate, compile-time safety. Модуляризация через Dart packages. Сепарация логики от UI через use_case / repository паттерн.
Кейс: React Native приложение, 2 года разработки, команда 5 человек. Жалоба: «всё работает, но мы боимся трогать код». Аудит показал: Redux store с 40 reducers без нормализации (Normalizr не используется), бизнес-логика в компонентах и в thunks одновременно, нет чёткого разделения «откуда данные». Рекомендация: не переписывать полностью, а ввести domain/ слой с чистыми функциями, постепенно перенести логику из компонентов. За 6 недель часть команды внедрила паттерн в двух фичах, скорость добавления нового функционала выросла.
Форматы консультации
Разовая сессия — 3–4 часа технического разговора, code review, выявление основных проблем и рекомендации. Подходит для: проверки перед началом нового проекта, быстрого аудита перед привлечением инвестора.
Расширенный аудит — 1–2 недели: изучение кодовой базы, интервью с командой, детальный документ с приоритизацией проблем и планом работ.
Сопровождение — регулярные сессии (1–2 раза в неделю) в ходе архитектурных изменений: code review ключевых PR, ответы на вопросы по ходу рефакторинга.
Стоимость и сроки определяются после предварительного разговора о задаче.