Консультування по архітектурі мобільного додатку
Архітектурні помилки не коштують багато на момент прийняття рішення — але коштують дорого 6–12 місяців пізніше, коли швидкість розробки впала вдвічі і onboarding новим розробником займає тиждень лише щоб додати екран.
Типові ситуації, з яких починається консультація
«Ми хочемо додати offline режим»—але додаток не має шару абстракції над мережею. ViewModels викликають URLSession/Retrofit безпосередньо, кеширування не передбачено. Додавання offline означає переписування третини додатку.
«Повільне время збірки»—монолітний додаток без модуляризації компілюється 8 хвилин за кожну зміну. Розробники втрачають 30–40 хвилин щодня, чекаючи на збірку.
«Ми хочемо другий target/flavor»—для white-label або іншого бренду, але кодова база змішує бізнес-логіку з брендовою специфікою. Все заплутано в одному target.
«Onboarding займає три тижні»—немає явної архітектури, магічні залежності через статичні синглтони, невидимі side effects.
Що дає архітектурна консультація
Не «давайте переписати все як Clean Architecture». Аналіз поточного стану → виявити конкретні вузькі місця → рекомендації з оцінкою трудозатрат та ризиків → дорожна карта змін.
iOS: оцінюємо розділення на шари (Presentation / Domain / Data), використання Swift Concurrency проти Combine проти callbacks, модуляризацію через SPM проти CocoaPods, тестованість (чи можна написати unit тест на UseCase без запуску симулятора).
Android: Clean Architecture з domain/data/presentation модулями, Hilt проти Koin проти manual DI, ViewModel lifecycle, корутини та Flow у repository шарі, Jetpack Navigation для deep linking.
Flutter: BLoC проти Riverpod проти GetX — не вибір «який кращий», а відповідність команді та задачі. Riverpod 2.x з code generation — менше boilerplate, compile-time безпека. Модуляризація через 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, відповіді на питання протягом рефакторингу.
Вартість та строки визначаються після попередньої розмови про вашу задачу.