;
Иван Алякскин

Android Legacy

21.03.2018 1842
IBS Training Center Telegram
Подписывайтесь на наш канал в Telegram:
больше материалов экспертов, анонсы бесплатных вебинаров и задачки для IT-специалистов
Подписаться
Привет, кто о чем, а я о 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 и т.д.

alyakskin_21_03_18.jpg

Расскажи друзьям:

Комментировать
Как не пропустить самое интересное?
Подписывайтесь на наш ежемесячный дайджест!
Спасибо.
Вы подписаны на ежемесячный дайджест.
Пользователь только что записался на курс ""
Спасибо!
Форма отправлена успешно.