70% проектів із високим тестовим покриттям (80%+) стикаються з регресіями в бізнес-логіці — це статистика наших аудитів. Причина: тести покривають UI та геттери, а не Use Cases та ViewModels. Типова ситуація: ви додаєте нову фічу, CI зелений, але після мерджа падає вже працюючий функціонал. Аудит кодової бази мобільного застосунку виявляє такі «сліпі зони» та показує, де реально потрібні тести. Наш досвід — понад 10 років у мобільній розробці та десятки виконаних аудитів — діагностує проблеми, які в 60% проектів залишаються прихованими до першого інциденту. Ми гарантуємо, що звіт міститиме actionable рекомендації, а не загальні фрази.
Як аудит кодової бази запобігає регресіям?
Код-рев'ю перевіряє окремий PR: стиль, логіку, баги. Аудит відповідає на питання: «чи можна з цим кодом жити наступні два-три роки, додавати фічі без постійних регресій, онбордити нових розробників за розумний час?» Це аналіз системного технічного боргу, а не точкових проблем. Циклічні залежності між модулями зустрічаються в 40% проектів, hardcoded API keys — у 30%. Без аудиту ці цифри залишаються прихованими до першого інциденту. Згідно з OWASP Mobile Security Testing Guide, подібні вразливості класифікуються як High Risk.
Що саме ми перевіряємо?
Архітектурна зв'язність. Дивимося на dependency graph: чи є циклічні залежності між модулями, чи порушені межі шарів, чи залежить UI від конкретних мережевих бібліотек напряму. Для iOS — перевіряємо розділення на feature modules або хоча б дотримання MVVM/VIPER у межах одного таргета. Для Android — Clean Architecture з Use Cases, або все звалено в Activity. Інструменти: Xcode Dependency Graph, Android Studio Module Dependencies, ArchUnit для автоматизованої перевірки.
Тестове покриття. Дивимося не лише відсоток, а й що саме покрито. 80% coverage на тривіальних геттерах і 10% на бізнес-логіці — гірше, ніж 30% правильних тестів на Use Cases та ViewModels. Перевіряємо наявність інтеграційних тестів (UI, XCUITest, Espresso), моків для мережевих залежностей, тестів на edge cases (порожній список, помилка мережі, таймаут). У 70% проектів тестове покриття бізнес-логіки не перевищує 20%, що призводить до регресій. Автоматизований аналіз у 3-5 разів скорочує час перевірки порівняно з ручним рев'ю.
Управління залежностями. CocoaPods vs SPM, Gradle catalogs, застарілі версії. Бібліотеки з відомими CVE — перевіряємо через OWASP Dependency-Check або знімок із pod outdated / ./gradlew dependencyUpdates. Особливо дивимося на бібліотеки, які запитують надлишкові дозволи (Analytics SDK, Ad SDK) — вони можуть порушувати App Store/Play Store privacy policies.
Продуктивність та витоки пам'яті. Статичний аналіз не замінює профілювальник, але в 90% випадків знаходить патерни: синхронні завдання на main thread, image створюється без кешування в циклі, URLSession створюється per-request замість синглтона. Для Flutter — const конструктори не використовуються там, де повинні, дорогі обчислення в build(). Середня частота витоків пам'яті у великих проектах — 3-5 на 1000 рядків коду.
Безпека. Автоматизований аналіз через MobSF (Mobile Security Framework) або Semgrep з мобільними правилами. Шукаємо: hardcoded API keys у коді або plist, логування чутливих даних, небезпечні IPC (exported Activities без permission), використання застарілих алгоритмів (MD5, SHA1 для критичних операцій). Також перевіряємо конфігурації Code Signing, provisioning profile, налаштування Push Notifications (APNs/FCM), deep linking (Universal Links / App Links) та ATT (App Tracking Transparency). Згідно з App Store Review Guidelines, user data must be handled with care — hardcoded credentials are a direct violation.
Які інструменти ми використовуємо?
| Задача | iOS | Android |
|---|---|---|
| Статичний аналіз | SwiftLint, Periphery (невикористаний код) | Detekt, Android Lint |
| Залежності/CVE | pod audit + OWASP Dependency-Check |
OWASP Dependency-Check |
| Складність коду | SonarQube | SonarQube |
| Безпека | MobSF | MobSF |
| Витоки пам'яті | Instruments (Leaks) | LeakCanary |
SonarQube інтегрується в CI та рахує цикломатичну складність, дублювання коду, cognitive complexity. Функція з complexity > 15 — кандидат на рефакторинг, це не смаковщина, це вимірний ризик.
| Проблема | Частота в проектах |
|---|---|
| Циклічні залежності між модулями | 40% |
| Тестове покриття бізнес-логіки < 20% | 70% |
| Застарілі бібліотеки з CVE | в середньому 5-8 на проект |
| Витоки пам'яті | 60% |
| Hardcoded API keys | 30% |
Чому автоматизовані інструменти не замінюють ручний аналіз?
Хоча інструменти на кшталт Periphery знаходять невикористаний код, а MobSF виявляє вразливості, лише ручний аудит архітектури дозволяє оцінити, як технічний борг вплине на майбутню розробку. В одному проекті ми виявили циклічну залежність, яка збільшувала час збірки на 40% — статичний аналізатор її не показав, тому що залежності були через reflection. Наш досвід запобігає таким ситуаціям.
Як ми проводимо аудит?
- Збір метрик — статичний аналіз всього коду, dependency graph, тестове покриття.
- Глибоке рев'ю архітектури — виявлення cyclic dependencies, violation of Clean Architecture.
- Ручна перевірка безпеки — перегляд конфігурацій, маніфестів, plist.
- Профілювання продуктивності — пошук витоків і вузьких місць.
- Формування звіту — дорожня карта з оцінкою ризиків та пріоритетів.
Використання автоматизованих інструментів скорочує час аналізу в 3-5 разів порівняно з ручною перевіркою. Periphery для iOS знаходить невикористані функції, класи, протоколи. У великій кодовій базі накопичуються тисячі рядків мертвого коду, які читають, підтримують і бояться видалити.
Що ви отримуєте в результаті?
- Звіт із чотирма рівнями: Critical (негайне виправлення — витік даних, crasher), High (наступний спринт — архітектурний ризик, security issue), Medium (технічний борг, планується), Low (рекомендації щодо якості).
- Дорожня карта рефакторингу з оцінкою ризиків та пріоритетів — що рефакторити спочатку, що можна відкласти.
- Документація щодо виявлених проблем та рекомендації щодо їх усунення.
- Список застарілих залежностей із зазначенням CVE та версій для міграції.
- Рекомендації щодо покращення CI/CD для автоматизації контролю якості.
Зв'яжіться з нами для оцінки вашого проекту. Отримайте консультацію щодо аудиту — оцінимо терміни та обсяг робіт індивідуально. Аудит без плану дій — безглуздий документ, тому ми завжди даємо actionable рекомендації.
Терміни — від 3 до 5 днів на проект середнього розміру (до 200k рядків). Великі проекти (300k+ рядків, декілька платформ) — до 2 тижнів. Точна вартість розраховується після ознайомлення з проектом. Економія бюджету на рефакторинг з нашими рекомендаціями може досягати 40% за рахунок пріоритизації критичних проблем.