Добавление новой фичи превращается в две недели вместо двух дней? Команда избегает трогать WorkoutActivity на 1800 строк — боятся, что сломается что-то непредсказуемое. Это классические симптомы технического долга. Мы занимаемся рефакторингом мобильных приложений: от реструктуризации одного экрана до полной архитектурной перестройки кодовой базы. Опыт — более 20 проектов, платформы iOS, Android, Flutter, React Native. Рефакторинг сокращает время на новую фичу в 3-5 раз, а количество крешей падает на 60-80%. Свяжитесь с нами для оценки вашего проекта.
Как выглядит кодовая база, которая требует рефакторинга?
iOS: ViewController на 1500 строк с URLSession, CoreData, бизнес-логикой и расчётом высоты ячейки в одном файле. NotificationCenter с magic-string именами нотификаций. Closure-hell в completion handler'ах, отсутствие [weak self] — утечки памяти, стабильный рост Allocations в Instruments.
Android: Activity с 800 строк, прямые вызовы SharedPreferences в UI, AsyncTask вместо корутин, статические синглтоны в Application классе. LiveData подключена, но логика всё равно живёт в Activity.
React Native / Flutter: бизнес-логика прямо в JSX/build, состояние через setState на 200+ строчных компонентах, отсутствие типизации (any в TypeScript, dynamic в Dart).
Почему важны тесты перед рефакторингом?
Рефакторинг без тестов — это переписывание с надеждой, что ничего не сломали. Первый шаг — покрытие критических путей snapshot- и unit-тестами до изменений. Это фиксирует текущее поведение как эталон. Особенно критично для приложений с бэкенд-интеграцией через GraphQL или REST — ошибки в данных видны только на проде. Мы гарантируем, что после рефакторинга ни один существующий сценарий не пострадает. Получите бесплатную консультацию, чтобы оценить готовность вашего проекта к рефакторингу.
Как мы проводим рефакторинг по платформам?
iOS. Выносим сетевой слой в отдельный NetworkService с async/await (Swift Concurrency). ViewController получает только ViewModel через Dependency Injection (без Swinject — достаточно init-инъекции). CoreData operations — в PersistenceController с NSPersistentContainer.performBackgroundTask. Combine или async/await заменяет closure callbacks — читаемость кода меняется кардинально.
Android. Миграция с AsyncTask / RxJava на Kotlin Coroutines + Flow. ViewModel + StateFlow вместо изменяемых LiveData. Repository pattern — UI ничего не знает о том, откуда данные: Room, Retrofit, или кеш. Hilt для DI — устраняет статические синглтоны, которые делают тесты невозможными.
Кейс: Android-приложение для трекинга тренировок, 2 года в production, команда 3 разработчика. Главная проблема: WorkoutActivity.java — 1800 строк, Bluetooth-соединение с датчиком, запись в SQLite, расчёт статистики и UI в одном классе. Новая фича (поддержка второго типа датчика) оценивалась в 6 недель. После рефакторинга: BluetoothSensorManager, WorkoutRepository, StatisticsCalculator, WorkoutViewModel — каждый класс до 200 строк с чёткой ответственностью. Следующая аналогичная фича — 5 дней. Подход основан на принципе Boy Scout Rule.
Как рефакторинг влияет на метрики?
| Метрика | До рефакторинга | После рефакторинга |
|---|---|---|
| Среднее время на новую фичу | 3-6 недель | 1-2 недели |
| Количество крешей в день | 20-50 | 2-5 |
| Test coverage | <20% | >70% |
| Build time (инкрементальная сборка) | 8-12 минут | 3-5 минут |
Результат — измеримые цифры, а не «стало лучше». Мы фиксируем velocity в Jira, мониторим Crashlytics и собираем coverage отчёты. Закажите оценку вашего проекта — мы предоставим детальный план.
Как выбрать стратегию рефакторинга?
Полный рефакторинг «всё сразу» — почти всегда плохая идея. Работаем по Boy Scout Rule: каждый PR улучшает код, которого касается. Для масштабного рефакторинга — feature branch с поэкранной декомпозицией, параллельный запуск старого и нового кода через feature flag, постепенный перевод трафика. Сравнение стратегий:
| Стратегия | Когда применима | Риски | Сроки |
|---|---|---|---|
| Полный рефакторинг | Маленькое приложение (< 20 экранов) | Высокий — стоп-мир | 4-8 недель |
| Постепенный (Boy Scout) | Большое приложение, активная разработка | Низкий — контролируемый | постоянно |
| Замена модуля | Один проблемный модуль изолирован | Средний — только модуль | 1-3 недели |
Что входит в работу и сроки
- Диагностика: анализ кодовой базы, выявление антипаттернов, замер метрик.
- Покрытие тестами: unit- и snapshot-тесты на критические пути.
- Рефакторинг по модулям: выделение слоёв, внедрение DI, замена устаревших API.
- Документация: описание новой архитектуры, ADR (Architecture Decision Records).
- CI/CD: интеграция проверок кодстайла, автотестов и code coverage.
- Поддержка: после внедрения сопровождаем проект 2 недели для выявления регрессий.
Сроки: рефакторинг одного модуля / экрана — 1–2 недели. Полная архитектурная реструктуризация — 6–14 недель в зависимости от объёма кода и наличия тестов.
Если хотите оценить ваш проект, получите бесплатную консультацию — рассчитаем объём работ и предложим оптимальный план рефакторинга.