Проведение код-ревью мобильного приложения
Код-ревью, который сводится к «переименуй переменную» и «добавь комментарий» — не ревью. Реальное ревью мобильного кода ищет места, где приложение упадёт в продакшне: memory leak в замыкании, race condition в async коде, неправильный lifecycle обработчик, который будет ловить события после deinit.
Что проверяем в первую очередь
Memory management на iOS. Retain cycles через [weak self] — это знают все, но часто делают неправильно. Типичный баг: таймер держит сильную ссылку на ViewController через target: self, ViewController держит таймер — цикл. deinit никогда не вызовется, экран не освободится, память растёт. Проверяем все Timer.scheduledTimer, NotificationCenter.addObserver, DispatchQueue.asyncAfter — везде, где self захвачен без weak/unowned.
Вторая часть — @escaping замыкания в сетевых запросах: если запрос отменён, но колбэк всё равно приходит и обращается к deallocated ViewController — краш. Проверяем [weak self] + guard let self = self else { return } в каждом escaping completion.
Concurrency и data races на iOS (Swift Concurrency). После перехода на async/await и Actors появились новые паттерны ошибок: обращение к @MainActor-изолированному свойству из non-isolated контекста без await, захват Sendable-нарушающих типов в Task. Xcode Thread Sanitizer находит часть проблем, но не все — нужен manual review с пониманием Actor isolation rules.
Android: lifecycle и ViewModel. LiveData.observe(this, ...) внутри Fragment — this как LifecycleOwner. Если использовать viewLifecycleOwner вместо this не везде, наблюдатель остаётся живым после уничтожения View, обновления данных применяются к detached View — краш NullPointerException или дублирование наблюдателей при возврате на фрагмент. Проверяем каждый observe в Fragment.
Корутины и отмена. viewModelScope.launch — правильно, корутина отменяется при очистке ViewModel. GlobalScope.launch — красный флаг в ревью: живёт дольше ViewModel, не отменяется, держит ссылки. lifecycleScope.launch в Fragment — проверяем, что не запускаем из onCreate, а из onViewCreated, иначе множественные подписки при каждом пересоздании view.
Архитектурные паттерны
Смотрим на связность компонентов: ViewModel напрямую обращается к Context? Use case знает о слое представления? Repository импортирует android.view.*? Это нарушения Clean Architecture, которые делают код нетестируемым и хрупким.
Для Flutter: проверяем, нет ли бизнес-логики в StatefulWidget.build — она должна быть в Bloc/Cubit/ViewModel. Прямые вызовы setState с API-запросами внутри — признак архитектурного долга.
Безопасность и типичные уязвимости
- Токены в
UserDefaults/SharedPreferencesplaintext - Логирование чувствительных данных через
print/Log.d— в release-сборке логи видны черезadb logcat - SQL-запросы через конкатенацию строк вместо prepared statements (Room не позволяет это сделать случайно, но прямые SQLiteDatabase-вызовы — могут)
- Deeplink handling без валидации параметров — open redirect или injection через кастомную схему
Формат ревью
По каждому найденному паттерну — конкретный файл, строка, объяснение почему это проблема и пример исправления. Никаких «следует рассмотреть рефакторинг» — либо это баг/риск с приоритетом, либо незначительная рекомендация.
Приоритизация: Critical (краш, уязвимость, утечка данных), High (memory leak, неверный lifecycle), Medium (архитектурный долг, нетестируемость), Low (стиль, именование).
Сроки — 2–3 дня на проект среднего размера (50–100 файлов). Большие кодовые базы (200+ файлов) — до 5 дней.