Оптимізація технічного боргу мобільного додатку
Технічний борг у мобільному додатку — це не абстракція. Це конкретна причина, чому Xcode 15 падає з linker command failed при додаванні нового SPM пакету, тому що три роки тому хтось додав застаріле CocoaPod, яке конфліктує з сучасним Swift Concurrency runtime.
Три типи боргу з різною вартістю
Інструментальний борг. Застаріле API, старі SDK, підтримка iOS 13 коли App Store Connect вже вимагає мінімум iOS 16. Xcode видає 200 warnings при кожній збірці — команда навчилась ігнорувати їх усі, включаючи попередження про реальні проблеми.
Архітектурний борг. Відсутність розділення шарів, прямі залежності між функціями, написання тестів неможливе без завантаження всього додатку. Вартість кожної нової функції зростає нелінійно.
Борг продуктивності. Витоки пам'яті в довгоживучих об'єктах, main thread stall при відкритті екранів, надмірне використання CPU у фоновому завданні, що викликає thermal throttling на iPhone 12. Користувачі помічають, ставлять 1 зірку.
Як приоритизувати
Не все потрібно чинити. Інструмент: SQALE матриця або простий варіант — оцінити кожен елемент боргу по двох осях: «вартість не-припинення за 6 місяців» проти «вартість припинення». Перший квадрант (дорого не чинити, дешево чинити) — робимо відразу.
Приклад приоритизації для iOS додатку:
| Елемент боргу | Вартість ігнорування | Вартість припинення | Пріоритет |
|---|---|---|---|
UIWebView (видалено iOS 15) |
Відхилення App Store | 2 дні | Негайно |
Без async/await, callbacks везде |
+30% time-to-feature | 4 тижні | Високий |
AsyncTask на Android (застаріло) |
Попередження, не крах | 1 тиждень | Високий |
| Xcode storyboard проти SwiftUI | Повільна розробка | 8+ тижнів | Середній |
| Відсутність unit-тестів | Регресії при змінах | Поступово | Високий |
Розв'язання боргу продуктивності
Це окрема історія. Витік пам'яті на 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 — обов'язковий інструмент, ловить витоки пам'яті автоматично з зрозумілим stack trace.
Реальний приклад: Flutter додаток, 2.5 року в production. Накопився борг: http пакет 0.13 (застаріло, dio везде, але обидва підключені), provider 5.x та riverpod 1.x одночасно для різних функцій, 60% коду без null-safety. Dart analysis видав 340 warnings, CI фактично не працював — занадто багато хибних срабатувань. Працювали поступово: спершу null-safety migration (dart migrate --apply-changes), потім уніфікація управління станом на Riverpod 2.x, потім видалення дублюючих HTTP пакетів. Три місяці, паралельно з розробкою функцій. Warnings: 340 → 12.
Процес без зупинення розробки
«Заморозимо функції на місяць і все чинимо» — нереалістично та не потрібно. Використовуємо цей підхід:
- 20% кожного спринту виділяємо на техборг (Debt Sprint Budget)
- Критичний борг (застаріле API, проблеми безпеки)—окремий hotfix-трек
- Кожен новий PR не збільшує борг: code review включає перевірку «залишаємо код краще ніж знайшли»
Час реалізації: аудит та план роботи — 3–5 днів. Усунення критичного боргу (застаріле API, security fixes) — 1–3 тижні. Повна реструктуризація архітектурного боргу — 2–4 місяці паралельно з розробкою.