Przejęcie aplikacji EDK i odzyskanie kontroli nad jej rozwojem.

Warunki użycia

Mapa jest częścią bezpieczeństwa i ciągłości doświadczenia

Ekstremalna Droga Krzyżowa prowadzi uczestnika nocą przez trasę liczącą około 40 kilometrów, często poza głównymi drogami i w terenie o słabym zasięgu. Telefon nie jest wtedy dodatkiem do wydarzenia. Pomaga rozpoznać przebieg trasy, własne położenie i kierunek marszu, a równocześnie udostępnia rozważania przypisane do kolejnych stacji. Drobny problem interfejsu, który w codziennej aplikacji byłby tylko niedogodnością, po ciemku może przerwać skupienie i utrudnić podjęcie właściwej decyzji na skrzyżowaniu.

Mapa, GPS i kompas są podstawowymi narzędziami prowadzącymi uczestnika przez trasę. Muszą współpracować: pozycja powinna być czytelna, kierunek zrozumiały, a widok mapy powinien zachowywać się przewidywalnie także wtedy, gdy użytkownik idzie, obraca telefon albo zmienia skalę. Aplikacja powinna przekazywać wystarczająco dużo informacji, lecz nie konkurować o uwagę z samą drogą i refleksją. Ten kontekst wpływał na moje priorytety techniczne równie mocno jak kod.

Równie operacyjny jest dostęp offline. Trasa może przebiegać przez las, pola i miejscowości, w których transmisja danych zanika. Uczestnik potrzebuje wcześniej pobranej mapy w jasnym lub ciemnym wariancie oraz lokalnie dostępnych materiałów, bez założenia, że sieć wróci w odpowiednim momencie. Dlatego objąłem pracą nie tylko widok mapy online, lecz także pobieranie, przełączanie motywu, obsługę błędów i zachowanie aplikacji przy zmianach cyklu życia.

Punkt wyjścia

Model zewnętrznego utrzymania i rozwoju aplikacji

Aplikacja była stabilna i bardzo dobrze napisana. Poprzedni dostawca specjalizował się w produktach mapowych, dbał o wersjonowanie i jakość oraz stosował rozsądne zasady wydawania - na przykład nie publikował wydań w piątki. Nie przejmowałem produktu, który wymagał ratunku technicznego, i nie mam zastrzeżeń do jakości pracy poprzedniego zespołu.

Wyzwanie dotyczyło dopasowania modelu do aktualnych potrzeb Fundacji. Zewnętrzne utrzymanie wiązało się z określonym kosztem i naturalnym procesem uzgadniania większych zmian. Nie była to wada po stronie dostawcy, lecz cecha tego modelu współpracy. Fundacja potrzebowała bardziej zwinnego modelu rozwoju: możliwości szybkiego sprawdzania hipotez, dzielenia zmian na małe etapy i uczenia się na podstawie zachowania prawdziwych urządzeń.

Odzyskanie wiedzy

Przejęcie zaczęło się od rekonstrukcji, nie od przepisywania

Zacząłem od rekonstrukcji architektury istniejącej aplikacji Flutter: przepływów użytkownika, zależności między ekranami, źródeł danych, stanu mapy, integracji Firebase, zachowania GPS i obszarów szczególnie podatnych na regresje. Nie wynikało to z chaosu w kodzie, lecz z odpowiedzialności za poznanie dobrze zbudowanego produktu przed rozpoczęciem dużej modernizacji. Wiedzę rozproszoną w kodzie i historii zmian zamieniłem w jawny model produktu.

Następnie przygotowałem wersjonowane reguły i kontekst projektu dla Claude Code. Opisałem w nich architekturę, konwencje, ograniczenia, sposoby uruchamiania kontroli jakości oraz kryteria akceptacji. Dzięki temu kolejne sesje nie zaczynały od zgadywania, a ważne ustalenia pozostawały w repozytorium razem z kodem. Kontekst nie zastępował dokumentacji produktu; łączył ją z praktycznymi instrukcjami potrzebnymi do bezpiecznego wykonania konkretnej zmiany.

Każdemu zadaniu dla Claude Code nadawałem ograniczony zakres i obserwowalny rezultat. Po implementacji wykonywałem review, uruchamiałem testy, budowałem aplikację i sprawdzałem jej zachowanie na rzeczywistych urządzeniach. Problemy kierowałem do kolejnej małej iteracji zamiast pozwalać im ginąć w dużym pakiecie zmian. Kontrolowałem wydania, aby móc powiązać regresję z konkretnym zakresem i szybko zdecydować o poprawce.

To ja odpowiadałem za cały ten system pracy: wybór kierunku architektonicznego, zakres zadań, ocenę kodu, testy urządzeniowe, interpretację awarii i decyzję, co jest gotowe do wydania. Claude Code wspierał mnie w analizie i pisał znaczną część implementacji, lecz nie przejmował odpowiedzialności za produkt. To rozróżnienie było kluczowe w aplikacji używanej nocą, w ruchu i poza stabilnym zasięgiem.

Nawigacja w terenie

Od statycznej mapy do przewidywalnego narzędzia nawigacyjnego

Przeprowadziłem migrację do MapLibre, przenosząc aplikację na renderowanie wektorowe i tworząc podstawę dla obrotu mapy, kompasu oraz płynniejszej pracy widoku mapy. Zmiana objęła zarówno technologię warstwy bazowej, jak i logikę zachowania widoku. Musiałem zachować spójność widoku mapy, znacznika użytkownika i orientacji urządzenia, aby obrót ekranu nie powodował dezorientacji, a powrót do śledzenia lokalizacji był oczywisty.

Zaprojektowałem trzy stany GPS odpowiadające różnym intencjom użytkownika: swobodne przeglądanie mapy, śledzenie własnej pozycji oraz prowadzenie z orientacją zgodną z kierunkiem ruchu. Dodałem kompas pozwalający wrócić do północy i zadbałem o to, aby automatyczne śledzenie nie walczyło z ręcznym przesunięciem mapy. Zbliżyłem wzorce interakcji do tych znanych z Google Maps, ponieważ rozpoznawalne zachowanie zmniejsza koszt poznawczy w sytuacji, gdy uwaga powinna pozostać na trasie.

Mapa pokazuje jednocześnie wiele typów informacji. Dodałem klastrowanie wydarzeń i stacji, aby ograniczyć wizualny chaos przy oddaleniu, oraz rozwijany panel trasy, który udostępnia szczegóły bez trwałego zasłaniania mapy. Zbudowałem także interaktywny wykres przewyższeń, który łączy profil wysokości z przebiegiem drogi i pomaga zrozumieć wybraną trasę przed marszem oraz w jego trakcie. Potraktowałem te elementy jako część jednego systemu informacji, a nie osobne widżety.

Przebudowę prowadziłem etapami, abym mógł porównywać nowe zachowanie ze znanymi scenariuszami. Najpierw zbudowałem stabilną podstawę renderowania, następnie orientację i stany GPS, a później warstwy, klastry, panel oraz wykres. Taka kolejność ograniczała liczbę zmiennych podczas diagnozy i pozwalała mi zachować działający produkt pomiędzy wydaniami.

Odporność produktu

Płynność i nowe funkcje bez utraty stabilności

Rozszerzyłem tryb offline o pobieranie jasnych i ciemnych map. Uwzględniłem współbieżność pobrań, błędy sieciowe, częściowe niepowodzenia i czytelny stan dla użytkownika, zamiast zakładać idealne połączenie. Zadbałem także o poprawne użycie lokalnych danych po zmianie motywu, tak aby przygotowana wcześniej mapa pozostała użyteczna wtedy, gdy urządzenie nie może pobrać innego wariantu.

Poprawiłem wydajność mapy, ograniczając zbędne repainty i konsolidując warstwy renderowania. Moim rezultatem było wyeliminowanie przycięć i przywrócenie płynnego działania mapy na budżetowych urządzeniach z Androidem, bez publikowania nieudokumentowanego pomiaru liczby klatek. Optymalizację oparłem na obserwacji prawdziwego zachowania, analizie ścieżek aktualizacji stanu i zmniejszaniu pracy wykonywanej przy każdej zmianie pozycji lub widoku mapy.

Rozbudowując centralny element produktu, musiałem zachować wysoką jakość, którą aplikacja miała już wcześniej. Dlatego zabezpieczyłem nowy stos przed awariami SIGSEGV związanymi z MapLibre, dopracowałem aktualizacje GPS, przełączanie jasnego i ciemnego motywu, Firebase Remote Config, cykl życia oraz bezpieczne obszary interfejsu. Problemy, przed którymi zabezpieczałem modernizowany stos, nie były wadami odziedziczonej aplikacji, lecz ryzykiem związanym z wprowadzaniem nowego silnika map i kolejnych funkcji.

Każdą poprawkę weryfikowałem nie tylko w izolacji, lecz także w połączeniu z mapą, nawigacją i przechodzeniem aplikacji między tłem a pierwszym planem. Dzięki temu naprawa jednego przypadku nie mogła bez kontroli naruszyć innego. Testami na urządzeniach uzupełniałem automatyczne kontrole tam, gdzie znaczenie miały sensory, sterowniki graficzne, zasoby telefonu lub zachowanie systemu operacyjnego.

Rezultat

Kontrolowany rozwój od wersji 1.8.0 do 1.10.5

Od kiedy przejąłem aplikację, rozwinąłem ją z wersji 1.8.0 do 1.10.5. Ważniejsza od liczby wykonanych zmian jest jednak zmiana sposobu działania: Fundacja ma jawny kontekst techniczny, możliwą do przeglądu historię decyzji i proces, w którym większy kierunek rozwoju można rozłożyć na sprawdzalne etapy bez utraty odpowiedzialności za całość.

Nie obiecuję prostego związku między zakresem zmian a ocenami. Dzięki mojej pracy Fundacja zyskała większą zwinność rozwoju przy zachowaniu wysokiej jakości produktu: nową mapę wektorową, przewidywalną nawigację, bardziej odporne działanie offline, lepszą płynność oraz infrastrukturę kontekstu dla pracy z Claude Code. Razem tworzą bazę, na której kolejne potrzeby uczestników mogą być oceniane i realizowane w kontrolowany sposób.