История рефакторинга приложения «Ситимобил»
Бизнес довольно часто рассматривает собственные мысли, ориентируя на это урезанные источники, и старается получить обратную зависимость, исследовать собственные догадки в кратчайшие сроки. В такие факторы, обычно, высококачественное обдумывание и реализация архитектуры проекта с учетом задела на будущее отступает на 2-й план. Равномерно проект зарастает новой функциональностью, возникают свежие бизнес-требования, и это воздействует на кодовой основе. «Ситимобил» в данном плане не выбился из привычных рамок. Проект поочередно проектировался некоторыми командами в древнем кабинете, потом, в процессе переезда, удерживался и отчасти переписывался на аутсорсе. Затем начали создавать свежую команду, и мне сообщили деятельность над планом.
Тогда «разработка» перебралась в столичный кабинет, работа бурлила — регулярно являлись свежие интересные и претенциозные цели. Но легаси все больше вводило трости в колеса, и когда-нибудь мы осознали, что настало время огромных перемен. Пока, тогда удалось отыскать не много необходимой литературы. Оно и ясно, это познается на эксперименте, едва ли можно разработать либо отыскать оптимальный рецепт, работающий в 100 % примеров.
1-ое, что необходимо сделать — осознать, в точности ли вам необходим рефакторинг? Про это необходимо задуматься, если:
Скорость внедрения свежих фич безосновательно невысокая, невзирая на высочайший уровень экспертов в команде.
Перемены кода в одной части платформы могут привести к внезапному действию в другой части.
Адаптация свежих членов команды задерживается.
После понимания присутствия неприятности необходимо отыскать решения на следующие вопросы:
Что, фактически, не так?
Что к данному привело?
Что надо сделать, чтобы такое больше не повторилось?
Как решать проблему?
Почти невозможно возвести отличный долгоиграющий проект без закладывания некоторой архитектуры. В собственном плане мы приняли решение вводить «слоеную» архитектуру, которая себя прекрасно показала.
Первоначально проект был опубликован, преимущественно, только при помощи средств, которые предлагает само Андроид SDK. Подход, очевидно, рабочий, но вымогает писать очень много трафаретного кода, что значительно притормаживает подготовку. А принимая во внимание, что сегодня очень многие пристрастились к некоторым стекам технологий, адаптация свежих создателей происходила продолжительнее. Равномерно мы пришли к не менее комфортным технологиям, которые очень многие понимают и оценивают, и которые установили собственную долговечность и непротиворечивость:
MVP — стандарт разработки пользовательского внешнего вида (Model-View-Presenter).
Dagger 2 — фреймворк для внедрения связей.
RxJava2 — реализация ReactiveX — библиотеки для создания синхронных и основанных на мероприятиях программ с применением паттерна «Наблюдатель», для JVM.
Cicerone — библиотека, которая позволяет облегчить навигацию в дополнении.
Ряд специфичных библиотек для работы с картами и локацией.
Важно взять суммарный для команды образ кода, сформировать свод самых лучших методик. Также необходимо побеспокоиться об инфраструктуре и действиях. На свежий код лучше сразу писать исследования, добро информации насчет этого присутствует много.
Внутри команды мы стали обязательно вести code review, это занимает не много времени, но качество кода стало намного выше. Даже если вы 1 в команде, советую работать по Git Flow, формировать merge request’ы несмотря на то что бы проверять их собственноручно. Если вас интересует сити мобил подключение рекомендуем сайт rabota-v-yandextaxi.ru.
Всю «грязную» деятельность можно направлять CI — в нашем случае это TeamCity с применением fastlane. Мы настроили его на сборку feature-веток, прогон испытаний и выкладку на врожденный анализ. У себя мы в отдельности настроили комплектации для продакшин/staging-окружения, feature- (их мы именуем по номеру цели с стандартом TASK#номер_задачи) и релизных ветвей. Это упрощает испытание, и в случае если появляется ошибка, мы сразу знаем, что и где надо поправить.
После выполнения всех ориентировочных действий воспринимаемся за деятельность. Свежую жизнь в древнем плане мы начали с создания пакета (cleanarchitecture). Принципиально не забыть про activity-alias при переводе пунктов входа в приложение (a-la ActivitySplash). Если этим пренебречь, то, в любом случае, у вас пропадет иконка в лаунчере, а в наихудшем — расстроится сопоставимость с иными дополнениями.
Как дает подсказку опыт, начинать рефакторинг лучше со вторых незначительных дисплеев и элементов приложения. И к тому моменту, когда настанет время исправлять наиболее трудную и масштабную часть платформы, большая часть кода будет опубликована для иных модулей и вполне может быть переиспользована.