Поддержи или умри (приложение Reviving 5 y.o. AN)

Пять лет для быстрорастущего мобильного мира - огромный срок. Мы такая компания, которая всегда пробует новые функции, способы создания приложений и пробует все возможные решения в наших новых проектах. На данный момент несколько моих товарищей по команде уже работают над приложениями, в которых используется компонент навигации, недавно представленный в Google I / O, вместе с другими функциями JetPack. Год назад мы все изучали Kotlin, а еще некоторое время назад соревновались в различных решениях CI для наших проектов Android. Но без прошлого нет будущего!

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

Я уже около 4 лет кодирую на Android и могу догадаться, как там выглядит код. Чтобы избежать подробных технических моментов, только для протокола я перечисляю охватываемые моменты:

  • Имея файл .classpath в корневом каталоге, я мог импортировать проект Eclipse в Android Studio.
  • Затем большинство библиотек, которые были импортированы как «.jar», можно было найти в репозиториях и импортировать через Gradle.
  • Конечно, все началось с того, что targetSdk был как можно более новым, а летом 2018 года это API 28. Этот огромный скачок (API 13 → API 28) перенесет вас в красивое и аркадное путешествие по обновлению различных библиотек. (которых, кстати, еще нет в Gradle [1]).

  • В какой-то момент вы понимаете, что некоторые библиотеки (в моем случае MapViewBaloon) больше не поддерживаются, и быстрого способа справиться с этим нет. Особенно с учетом того, что это связано с другими библиотеками (например, GoogleMaps), которые с тех пор тоже кардинально изменились. [2]
  • В другой момент где-то в будущем, когда вы будете иметь дело с разрешениями времени выполнения или какой-либо новой частью «потрясающего» SDK для Android, вы обнаружите секретные функции, о которых вы не знали, потому что разработчик приложения не покинул есть какие-либо комментарии или документация не сохранилась. Это совпадает с тем фактом, что тогда не было никаких шаблонов (по крайней мере, в большинстве приложений). [3]
  • Чем больше будет развиваться и расти какой-то конкретный фреймворк, тем больше библиотек будет появляться. Эти библиотеки, особенно если они популярны, обновляются и поэтому совместимы с другими популярными дополнительными библиотеками. Так что обычно работа с таким старым проектом означает возню с нестандартными решениями, созданными тогда разработчиком, у которого просто не было другого выбора. Рекомендуется обновить эти пользовательские части, потому что отсутствие обновления чревато ошибками, а также смешивается с другими проблемами, упомянутыми выше. [4]

Наверное, есть больше очков, но мой случай немного эксклюзивен. Потому что там был хороший код (по крайней мере, большая его часть) - вещи, которые я менял, не создавали беспорядка. Важные части были максимально разделены и модульны. Так что, я думаю, если это не ваш случай, вы напишите об этом больше здесь.

Как разработчик, вы, вероятно, чувствуете мою боль, но если вы являетесь владельцем продукта, приготовьтесь прямо сейчас. Я оставил несколько закладок в списке [1–4] - это те места, где вы теряете деньги. Потому что каждый раз, когда сталкиваются 2 или X независимых проблем / ошибок, разработчик тратит X раз часов на поиск правильного решения. И эти проблемы никогда не возникают одновременно - это то, что вы собираете как пыль на книге - годами не прикасаясь к этому.

Так что не сомневайтесь, ведь лечить больные ноги всегда хуже, чем покупать теплые ботинки в холодную погоду.

Назарий Овчарчин.