70% проектов с высоким тестовым покрытием (80%+) сталкиваются с регрессиями в бизнес-логике — это статистика наших аудитов. Причина: тесты покрывают UI и геттеры, а не Use Cases и ViewModels. Типичная ситуация: вы добавляете новую фичу, CI зелёный, но после мерджа падает уже работающий функционал. Аудит кодовой базы мобильного приложения находит такие «слепые зоны» и показывает, где реально нужны тесты. Наш опыт диагностирует проблемы, которые в 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% за счёт приоритизации критических проблем.