Можешь рассказать о задаче которая больше всего запомнилась

Архитектурный рефакторинг приложения для доставки еды

Одна из самых сложных и запомнившихся задач в моей практике — полноценный рефакторинг монолитного Android-приложения крупного сервиса доставки еды на чистую многомодульную архитектуру. Приложение содержало более 500 экранов, разрабатывалось 5+ лет разными командами и накопило критичные проблемы.

Проблемы в изначальной архитектуре:

• Полное отсутствие модульности — весь код в одном модуле app
• Жёсткие связи между компонентами через синглтоны
• Отсутствие единого подхода к навигации — фрагменты, Activity, кастомные роутеры
• Неуправляемые зависимости — Dagger компоненты с 1000+ зависимостями
• Тесты отсутствовали из-за сильной связанности кода

Ключевые этапы рефакторинга:

1. Проектирование новой архитектуры

Мы выбрали подход Clean Architecture + многомодульность с чётким разделением ответственности:

// Структура модулей после рефакторинга
:app                      // Точка входа
:core:network            // Сетевой слой
:core:database           // Локальное хранилище
:core:di                 // Dependency Injection
:feature:restaurant      // Модуль ресторанов
:feature:cart            // Модуль корзины
:feature:order           // Модуль заказов
:feature:profile         // Модуль профиля

2. Внедрение MVI для управления состоянием

Для устранения проблем с состоянием UI ввели MVI (Model-View-Intent):

class RestaurantViewModel @Inject constructor(
    private val getRestaurantsUseCase: GetRestaurantsUseCase
) : ViewModel() {
    
    private val _state = MutableStateFlow(RestaurantState())
    val state: StateFlow<RestaurantState> = _state
    
    fun processIntent(intent: RestaurantIntent) {
        when (intent) {
            is RestaurantIntent.LoadRestaurants -> loadRestaurants(intent.location)
            is RestaurantIntent.FilterByCuisine -> applyFilter(intent.cuisineType)
        }
    }
    
    private fun loadRestaurants(location: Location) {
        viewModelScope.launch {
            _state.update { it.copy(isLoading = true) }
            val result = getRestaurantsUseCase(location)
            _state.update { 
                it.copy(
                    isLoading = false,
                    restaurants = result,
                    error = null
                )
            }
        }
    }
}

3. Внедрение кастомного роутера навигации

Разработали типобезопасную систему навигации с обработкой deep links:

interface AppRouter {
    fun navigateTo(route: Route)
    fun handleDeepLink(uri: Uri): Boolean
}

sealed class Route {
    data class RestaurantDetails(val id: String) : Route()
    data class MenuScreen(val restaurantId: String) : Route()
    object CartScreen : Route()
    data class CheckoutScreen(val orderId: String) : Route()
}

// Использование в ViewModel
viewModel.processIntent(RestaurantIntent.NavigateToMenu(restaurantId))
router.navigateTo(Route.MenuScreen(restaurantId))

Технические сложности и решения:

Проблема миграции без остановки разработки:

• Реализовали параллельную разработку — старый и новый код работали одновременно
• Создали adapter-слой для постепенной миграции компонентов
• Внедрили feature flags для контроля включения новых модулей

Проблема тестирования:

• Разработали многоуровневую систему тестов: модульные, интеграционные, UI-тесты
• Создали fake-реализации для всех зависимостей
• Настроили CI/CD pipeline с запуском 3000+ тестов

Результаты после 9 месяцев работы:

• Уменьшение времени сборки с 8 минут до 2 минут
• Увеличение покрытия тестами с 5% до 65%
• Снижение количества критичных багов на 80%
• Ускорение онбординга новых разработчиков — с 3 месяцев до 3 недель
• Возможность независимой разработки фич разными командами

Эта задача научила меня, что успешный рефакторинг — это не только техническое преобразование кода, но и:

1. Тщательное планирование с анализом рисков
2. Поэтапный подход с измеримыми результатами каждого этапа
3. Постоянная коммуникация с бизнесом о прогрессе
4. Инвестиции в документацию и знания команды

Самым ценным уроком стало понимание, что архитектурные решения должны балансировать между идеальной чистотой и практической целесообразностью. Иногда приходится принимать компромиссы ради бизнес-требований, но сохраняя ключевые принципы поддерживаемости и тестируемости кода.