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

Часть первая, оцениваем масштаб бедствий 
Это больше «менеджерский» раздел. Смотрим, какие подсистемы и связанные компоненты, в каких частях бизнес-логики больше багов. Делаем цветовую разметку, самым красным помечаем баги. Составляем список “опасных” интеграций, это кейс, когда UI плохо обрабатывает действия сетевой подсистемы или плохо происходит logout пользователя – UI + Data management.

Режем на слои, классическая архитектура
Возможно, об этом и писать не стоило, но не могу не упомянуть. Как обычно смотрим на UI, Controller/Presenter, Data Model, по возможности начинаем растягивать на отдельные классы. Не надо все делать сразу, начните с выносом UI в отдельные custom views, а сетевую и работу с данными в другую часть, писать тесты на это просто и это даст реальные результаты.

Выход в комплексное пространство и обход по контуру
Порой надо аккуратненько добавить новую фичу, старайтесь добавить ее по всем правилам чистой архитектуры или же какого-либо другого паттерна, это позволит вам тут же показать коллегам на проекте все выгоды и удобства отличного от legacy архитектурного подхода.

Добавляйте новые фичи с использованием слоев абстракции
Очень хочу заострить на этом внимание. Как только вы добавляете новую фичу, используйте доп. слои абстракции, во-первых, это аккуратный рефакторинг при реализации фичи, который обязательно купит менеджмент. Во-вторых, это задел на рефакторинг и оптимизацию работы соседних компонент. Плюс ко всему это упрощение кода, а следовательно, возможность покрывать код тестами. А это очень важно в проектах с большой кодовой базой.

Добавляйте Frameworks по необходимости
Добавляйте фрэймворки по необходимости:

• Dagger может помочь для управления графом зависимостей;
• RxJava для сложных последовательных и асинхронных операций;
• MVC/MVP/MVVM для удобного содержания в порядке кода и простоты тестирования.

Не увлекайтесь рефакторингом, изолируйте
Порой с реальностью реального мира просто смириться, не подвергайте рефакторингу то, что работает – просто изолируйте, обеспечьте враппером по необходимости и стройте вокруг то, что действительно требуется. 
В Android это делается очень просто:

• отдельно стоящий Activity/Fragment;
• отдельно запускаемый IntentService.

Уважайте Android framework
Прежде всего уважайте Android framework, он содержит всего 5 основных компонентов, чтобы выстроить работу всего приложения:

• Activity – создание UI и получение пользовательских воздействий;
• Service – для долгоживущих компонент используемых на разных экранах;
• ContentProvider – для работы данными в стиле “REST”;
• BroadcastReceiver – получение событий, с ними надо быть аккуратнее;
• Application – глобальный контекст, «тот приятель, что всегда будет с вами».

Используйте компоненты так, чтобы они «хостили» ваши объекты управления/данных с оглядкой на жизненный цикл, на то, сколько времени этот Android-компонент должен/может жить. 

Безумству храбрых поем мы славу (с) Максим Горький
Legacy-проекты, по моему мнению, это прекрасные плацдармы для обучения и оттачивания своих навыков. Это кладезь показательных примеров, как различные подходы могут привести к проблемам. Каждый Android-разработчик должен рано или поздно распутать “классический Android’ный клубок” из Activity, AsyncTask, отсутствия DataLayer и т.д.