Ви інтегруєте новий SDK, збірка падає з linker command failed. Причина — CocoaPod, залишений кілька мажорних версій тому, який тягне застарілий бінарник. Або Android-збірка ламається через конфлікт залежностей Gradle. Кожен такий інцидент — наслідок технічного боргу, накопиченого заради прискорення перших релізів. Ціна цього боргу: зростання time-to-market нових фіч на 40% і збільшення кількості крэшів на 25%. Ми системно вирішуємо проблему технічного боргу в мобільних застосунках: перепроєктуємо архітектуру так, щоб кожна нова фіча не збільшувала борг. Наш підхід дозволяє знизити вартість підтримки на 30% вже через три місяці. Ми провели аудит та рефакторинг понад 40 мобільних проєктів під iOS, Android, Flutter та React Native. Типові знахідки: retain cycles у Swift, витоки пам'яті через LeakCanary, дублюючі HTTP-пакети у Flutter. Кожен другий проєкт мав SQALE-індекс нижче 40, що вимагало негайного втручання. Замовте аудит та отримайте дорожню карту усунення боргу.
Три типи технічного боргу
Три типи боргу, кожен зі своєю ціною:
- Інструментальний. Deprecated API, застарілі SDK, підтримка версій iOS, які App Store вже не приймає. Xcode видає 200 warnings при кожній збірці — команда навчилася ігнорувати їх усі, включаючи ті, які попереджають про реальні проблеми. Інструментальний борг вимагає негайного виправлення, інакше App Store reject — його усунення в 5 разів дешевше, ніж очікування блокування.
- Архітектурний. Відсутність розділення шарів, прямі залежності між фічами, тести написати неможливо без підняття всього застосунку цілком. Вартість кожної нової фічі зростає нелінійно.
- Продуктивнісний. Memory leaks у довгоживучих об'єктах, main thread stall при відкритті екранів, excessive CPU usage у background tasks, що викликає thermal throttling. Користувач помічає, ставить 1 зірку.
Як пріоритезувати технічний борг?
Не все потрібно чинити. Інструмент оцінки: SQALE-матриця або простий варіант — оцінити кожен елемент боргу за двома осями: вартість не-лагодження за 6 місяців vs вартість лагодження. Перший квадрант (дорого не лагодити, дешево полагодити) — робимо негайно.
Приклад пріоритезації для iOS-застосунку:
| Елемент боргу | Вартість ігнору | Вартість лагодження | Пріоритет |
|---|---|---|---|
UIWebView (видалено в iOS 15) |
App Store rejection | 2 дні | Негайно |
Відсутність async/await, callbacks всюди |
+30% time-to-feature | 4 тижні | Високий |
AsyncTask на Android (deprecated) |
Warning, не крэш | 1 тиждень | Високий |
| Xcode storyboard vs SwiftUI | Повільна розробка | 8+ тижнів | Середній |
| Відсутність unit-тестів | Регресії при змінах | Поступово | Високий |
Наш системний підхід до пріоритезації скорочує час усунення боргу в 2 рази порівняно з хаотичним вирішенням проблем. Методологія SQALE детально описана в офіційній документації.
Коли потрібна реструктуризація коду?
Якщо новий feature вимагає зміни існуючого коду більше, ніж написання нового — це дзвіночок. Наприклад, додавання Universal Links зачіпає 10 файлів, хоча має бути два. Ми використовуємо аналіз графа залежностей та метрики цикломатичної складності, щоб об'єктивно оцінити архітектуру. Якщо цикломатична складність модуля перевищує 15, це сигнал до рефакторингу.
Як виявляти та усувати продуктивнісний борг?
Це окрема історія. Memory leak на iOS — Instruments Leaks profiler, граф сильних посилань. Типовий винуватець: closure захоплює self без [weak self], self захоплює closure в didSet — retain cycle. У Swift Concurrency: Task із захопленням actor — теж вміє текти.
Android: StrictMode в debug-збірці негайно виявляє операції з диском на main thread (StrictMode.setThreadPolicy). LeakCanary — обов'язковий інструмент, ловить memory leaks автоматично і пише зрозумілий stack trace. LeakCanary виявляє витоки в 3 рази швидше ручного аналізу.
Кейс: Flutter-застосунок, більше двох років у продакшні. Скопився борг: http пакет 0.13 (застарів, dio всюди, але обидва підключені), provider 5.x та riverpod 1.x одночасно для різних фіч, немає null-safety міграції в 60% коду. Dart analysis видавав 340 warnings, CI фактично не працював — забагато хибних спрацьовувань. Працювали поетапно: спочатку null-safety migration (dart migrate --apply-changes), потім уніфікація state management на Riverpod 2.x, потім видалення дублюючих HTTP-пакетів. Три місяці, паралельно з feature-розробкою. Warnings: 340 → 12.
Процес усунення без зупинки розробки
«Заморозимо фічі на місяць і все полагодимо» — нереалістично і не потрібно. Працюємо за схемою:
- Audit & Roadmap (3–5 днів): аналіз кодової бази, класифікація боргу, створення дорожньої карти.
- Critical fixes (1–3 тижні): deprecated API, security issues, immediate blockers.
- Debt Sprint Budget (20% кожного спринту): рефакторинг, тести, документація.
- Continuous improvement (кожен PR): code review з перевіркою «залишаємо код кращим, ніж знайшли».
Таблиця етапів
| Етап | Що робимо | Результат |
|---|---|---|
| Audit & Roadmap | Аналіз кодової бази, класифікація боргу | Дорожня карта з пріоритетами |
| Critical fixes | Виправлення deprecated API, security | Стабільна збірка, без warnings |
| Debt Sprint Budget | 20% спринту на рефакторинг | Зменшення боргу, зростання швидкості |
| Continuous improvement | Code review, тести | Запобігання новому боргу |
Отримайте консультацію інженера для узгодження плану робіт.
Що входить до складу робіт?
- Детальний звіт про технічний борг з пріоритезацією за SQALE.
- План поетапного виправлення з оцінкою трудозатрат.
- Впровадження практик Debt Sprint Budget та інспекцій коду.
- Документування змін та навчання команди.
- Гарантія: після кожного етапу — регресійні тести та демонстрація результату.
Чек-лист аудиту техборгу
- Перевірка актуальності залежностей (
flutter pub outdated,pod outdated). - Аналіз всіх warnings у білді. Якщо >0, розбираємо кожен.
- Перевірка коду на memory leaks (Instruments, LeakCanary).
- Оцінка наявності та покриття тестів критичних модулів.
- Відповідність мінімальної версії платформи вимогам App Store / Google Play.
Наш досвід
Багаторічний досвід на ринку, понад 40 проєктів з оптимізації мобільних застосунків. Сертифіковані розробники iOS (Swift, SwiftUI) та Android (Kotlin, Jetpack Compose), досвід з Flutter та React Native. Кожен проєкт завершується документацією та планом подальшої підтримки. Середня економія наших клієнтів після рефакторингу суттєва і залежить від обсягу робіт. Отримайте консультацію інженера по вашому проєкту.







