Jak przygotować się do pracy z zastanym kodem w aplikacjach Androidowych

Pewnego dnia dowiedziałem się, że niedługo trafię do nowego projektu. Byłem podekscytowany i ciekawy, jak będzie wyglądać moja praca w następnych miesiącach! Mój entuzjazm opadł, kiedy poznałem kilka rozczarowujących faktów.

Łukasz Kopociński. Android Developer. Był developerem w Droids on Roids. Do firmy dostał się po wzięciu udziału w siedmiodniowym bootcampie, podczas którego poznawał pracę programisty od siedmiu różnych liderów. Dziś student Data Science na Politechnice Wrocławskiej, pasjonat języka hiszpańskiego i wszystkiego, co z nim związane. Zajął drugie miejsce w prestiżowym HackTrain 5.0.

Okazało się, że projekt był tworzony dawno temu, przez nieznanych mi developerów i został napisany w Javie (kto zasmakował Kotlina, wie co mam na myśli). Jedno spojrzenie na kod i od razu wiedziałem, że będę pracował nad zastanym kodem. – No nie, naprawdę muszę się tym zajmować?! – pomyślałem.

Wypiłem melisę, zebrałem się w garść i zmieniłem zdanie. Zacząłem myśleć o całej sytuacji w kategoriach wyzwania. Powiedziałem sobie: Ja nie dam rady? W sumie mogę się wiele nauczyć.

Jeśli spotkałeś się z podobną sytuacją, zachęcam do lektury. Mam nadzieję, że znajdziesz rady, które Ci pomogą.

Zajrzyj do „Gradla”

Mając przed sobą kod, nad którym zamierzasz pracować, tak naprawdę nie wiesz co Cię może spotkać. Dobrym punktem wyjścia do odkrywania, co siedzi w projekcie, jest zajrzenie do plików Gradle – build configuration script – zawierających sporo przydatnych informacji.

Dependencje

Warto zwrócić uwagę na użyte w projekcie dependencje oraz numer wersji w jakiej zostały załączone. Podpowiedzą Ci jaki stos technologiczny został użyty i zapoznają Cię z użytymi w kodzie koncepcjami, nad którym będziesz pracował. Innymi słowy, pomogą Ci przygotować się na to, jakie rozwiązania spotkasz w kodzie, oraz ułatwią Ci zrozumienie dlaczego kod został napisany w taki, a nie inny sposób.

Jeśli jesteś świeżym programistą Androida, niektóre z zewnętrznych zależności mogą Cię zaskoczyć lub będą dla Ciebie zupełnie nowe. Możesz na przykład napotkać RxJava 1, której End-Of-Life (EOL) minął w marcu tego roku, Event Bus (bardzo popularny jakiś czas temu), bibliotekę Material Edit Text nie utrzymywaną od 2016 roku, lub GCM (Google Cloud Messaging) uznany przez Google jako deprecated. W niektórych przypadkach może być konieczna migracja do nowej technologii.

API level requirement

Plik Gradle jest również dobrym miejscem, by upewnić się, że spełnimy wymagania Google Play’s target API level. Google Play wymaga aby aplikacje były pisane z target API nie niższym niż Android 8.0. Może się więc zdarzyć, że będziesz musiał dokonać pewnych zmian w projekcie, zanim zostanie wypuszczona kolejna aktualizacja.

Przede wszystkim należy się upewnić czy został zaimplementowany mechanizm przyznawania uprawnień w RunTime. Twoja aplikacja powinna być przygotowana na odrzucenie żądania o przyznanie uprawnień. Na przykład jeśli użytkownik odmówi aplikacji dostępu do modułu GPS, aplikacja powinna zapewnić bezproblemowy sposób na kontynuowanie pracy.

Support Library

Kolejnym potencjalnym źródłem problemów w projekcie może okazać się Support Library używana w aplikacji, która może być w bardzo starej wersji. Gdyby przyszło Ci ją aktualizować nie bądź zaskoczony, jeśli coś nie będzie działać tak, jak się spodziewałeś. Support Library Revisions mogą być pomocne.

Sprawdź pliki Manifest

Warto również zajrzeć do Manifestu i wydobyć ważne dla nas informacje.

Permissions

W pliku Manifest zawarte są informacje o uprawnieniach z jakich korzysta aplikacja. Wśród nich, znajdziesz uprawnienia, które są przyznawane automatycznie oraz takie, które potrzebują zatwierdzenia w czasie używania aplikacji. Te drugie to tzw. Runtime permissions. Jak zająć się ich obsługą i dlaczego to ważne, wspomniałem powyżej.

Deep Links

Plik Manifest zawiera także tzw. deep link scheme. Jeśli aplikacja posiada świetnie zaimplementowany mechanizm obsługi deep linków i uruchamiania związanych z nim ekranów, nie ma się czym martwić. W przeciwnym razie warto wiedzieć, przy których Activity należy uważać.

Brak testów? Dopisz je

Przejdźmy jednak do pisania kodu. Przy pracy z zastanym kodem, jednym z typowych zadań jest refaktoryzacja. Na myśl od razu przychodzi pytanie, jak być pewnym, że zmiana kodu w jednym miejscu nie sprawi, że w innej części program się nie popsuje?

Przed taką niepewnością powinny chronić Cię testy. Gdy w projekcie nie ma testów, powinieneś je napisać zanim zaczniesz wprowadzać zmiany.

W moim przypadku było mnóstwo nieprzetestowanego kodu i – co więcej – nietestowalnego kodu. Jednym z pomocnych narzędzi, w takim przypadku, jest PowerMock. Dostarcza mechanizmów do mockowania metod statycznych, konstruktorów, finalnych klas i metod, metod prywatnych oraz wiele innych. Pomogą Ci zaoszczędzić trochę czasu.

Refaktoryzuj kod pisząc w Kotlinie

Gdy już przetestujemy naszą klasę, możemy przejść do refaktoryzacji. Początkowo myślałem, że bez problemu przyjdzie mi powtórne pisanie w Javie. Ale robiłem głupie błędy. Zapominałem o średnikach umykało mi słówko „new” przed konstruktorem klasy. Zatęskniłem za Kotlinem.

Ale nawet jeśli kod jest napisany w Javie, nie musimy rezygnować z bogactwa kotlinowych właściwości. Jak twierdzą twórcy tego języka, Kotlin jest kompatybilny z Javą. Można więc zaimplementować nowe rzeczy w Kotlinie, które będą znacznie bardziej zwięzłe niż napisane w Javie i używać ich w kodzie Javy.

Kotlin bardzo pomaga w przypadku refaktoryzacji. Przepisanie niektórych części kodu w czysto javowej konwencji może zająć dużo czasu. Warto więc rozważyć przeniesienie kodu do nowej klasy kotlinowej, a następnie po uproszczeniu go, ponowne użycie tej klasy w kodzie Java.

Dlaczego zrozumienie kodu jest takie ważne?

Ktoś mógłby powiedzieć: Po co zaglądać do plików Gradle i Manifest? Lepiej poznawać projekt na bieżąco, niż tracić czas na przeglądnie ich.

Cóż, nasza praca jest ściśle powiązana z biznesem, a nasi klienci chcą wiedzieć, ile czasu zajmie dostarczenie nowych funkcjonalności. Zrozumienie i dobry przegląd projektu jest niezbędne, aby zapewnić dokładne oszacowanie czasu, co z kolei pozwala zapobiegać komplikacjom w przyszłości.

Wnioski

Praca nad czyimś kodem może być frustrująca, ale zanim zaczniesz przeklinać przed ekranem monitora, spróbuj zrozumieć, dlaczego kod jest napisany w taki sposób. Na pierwszy rzut oka coś może wydawać się zupełnie nieczytelne, ale zagłębienie się w projekt może pomóc Ci zrozumieć kod i uratować Cię od przyszłych kłopotów.

Praca z zastanym kodem do najprostszych nie należy. Znacznie przyjemniej jest pracować z Android Jetpack, pisać cały kod w Kotlinie, wspierając tylko najnowsze wersje Androida. Jednak w miarę jak nowy kod się rozrasta, doświadczenie zdobyte przy pracy z zastanym kodem może okazać się bardzo owocne.

Podczas pracy nad tym projektem wiele dowiedziałem się na temat Frameworka Androidowego i Support Library. Co więcej, miałem doskonałą okazję do tego, by zastosować poznane mechanizmy opisane w książce „Working Effectively With Legacy Code„.

Jeśli napotkałeś podobne problemy i chciałbyś podzielić się radami na ten temat, zachęcam do zostawienia komentarza.

Tekst został pierwotnie opublikowany na blogu Droids On Roids – Mobile & Web App Development. Zdjęcie główne artykułu pochodzi z pexels.com.

Oferty pracy z