Planowanie wycieczki w góry wiąże się z potrzebą odpowiedzenia sobie na kilka pytań. Jaka będzie pogoda? Na ile czuję się na siłach? Czy ta trasa zawiera utrudnienia? Czy zdążę przed zmrokiem? Oczywiście jest ich o wiele więcej, a im trudniejsze pasmo wybierzemy, tym tych pytań będzie przybywać. 

Moja historia też rozpoczęła się od ogromnej niepewności. Byłem jeszcze studentem. Chciałem w końcu skonfrontować zdobytą wiedzę z rzeczywistymi wymaganiami na rynku pracy. Po kilku rozmowach i przejściu całego procesu rekrutacji zostałem przyjęty do Onwelo. Cieszyłem się bardzo, że udało mi się z sukcesem zakończyć ten etap, a dodatkowym elementem radości była informacja, że projekt, do którego trafię, jest prowadzony dla nowego klienta z branży finansowej – Vodeno. Dołączyłem do zespołu, w którym toczyły się prace nad Proof of Concept rozwiązania – tutaj można trochę pobłądzić, spróbować odpowiedzieć na pytania, zanim wybierze się docelowe rozwiązanie. Jest to sprzyjająca atmosfera do zadawania pytań i popełniania błędów, a tym samym do nauki.

Pierwsze kroki

Następuje w końcu ten czas, kiedy trzeba podjąć decyzję, że to koniec przygotowywań i czas wyruszyć na szlak. Zabiera się ze sobą spakowany plecak (zapakowany doświadczeniem), wygodne buty (ulubione narzędzia do pracy) oraz mapę z zaplanowaną trasą (plan, który powstał na koniec PoC–a). Bierze się głęboki wdech i stawia pierwszy krok.

Dla mnie pierwszym zadaniem było napisanie rozwiązania umożliwiającego wymianę informacji między dwoma systemami core banking. Jeden z nich był tworzony w Vodeno. Razem z zespołem zaplanowaliśmy prace i konsekwentnie, zaczynając od pierwszej linii kodu, zrealizowaliśmy je w całości. Wyszło z tego całkiem zgrabne rozwiązanie, wykorzystujące systemy kolejkowe i Spannera (baza do zarządzania i przechowywania rozproszonych danych) – w tamtym czasie była to świeżynka od Google’a. 

Uczmy się od przewodnika

Jeśli robi się coś po raz pierwszy, to dobrze jest poradzić się kogoś bardziej doświadczonego. Dzięki temu można uniknąć niepotrzebnych błędów (albo będzie się je popełniać w kontrolowanych warunkach).

Przyszedł taki moment, kiedy trzeba było zmigrować dane klientów ze starego systemu do nowego. Do tego przedsięwzięcia zostało zaangażowanych bardzo wiele osób. Ja również znalazłem się w tym gronie, a zadanie, nad którym pracowałem, było niebagatelne – miałem stworzyć narzędzie do orkiestracji migracją. Dzięki współpracy z bardziej doświadczonymi osobami z zespołu dowiedziałem się, jak to powinno wyglądać, najpierw z lotu ptaka, a potem bardziej szczegółowo. Statystyki, mechanizmy zatrzymywania i ponawiania procesów, zapewnienie równoległości przetwarzania – było tego naprawdę sporo. Tworzenie tego narzędzia oraz jego testowanie było prawdziwą lekcją. Nie byłbym w stanie znaleźć tej wiedzy w Internecie lub w literaturze.

Długa droga do celu

Kiedy zaczyna doskwierać nam droga, warto zatrzymać się i chwilę rozglądać – być może da się ujrzeć majaczący w oddali cel? To zawsze, choć trochę, podnosi morale.

Takim długim szlakiem w Vodeno była praca nad modułem pasywnego PSD2 (ang. Payment Service Directive 2). Jest to dyrektywa Unii Europejskiej dotycząca usług płatniczych i obligująca banki do m.in. udostępniania informacji o szczegółach kont czy umożliwienia zlecania przelewów przez inne podmioty (posiadające odpowiednie licencje) po uzyskaniu zgody od klienta. Wystartowaliśmy w kilkuosobowym gronie. Po drodze dołączyło do nas sporo osób, które pomogły nam w dotarciu do celu. Rozpoczęliśmy pracę wraz z zewnętrznym dostawcą. Powoli rozwijaliśmy moduł o kolejne elementy takie jak: mobilny proces zatwierdzania zgód, wielopodpis – zgoda na przelew w powyżej pewnej kwoty w firmie, która ma więcej niż jednego reprezentanta. W pewnym momencie stanęliśmy przed potrzebą dostosowania rozwiązania PSD2 do nowego modelu sprzedażowego związanego z wprowadzeniem architektury multitenant (jedna instancja aplikacji jest w stanie obsługiwać wiele kontekstów). Aktualne rozwiązanie było niewystarczające i trudno skalowalne. Jedynym sposobem sprostania temu wyzwaniu było zaprojektowanie własnego rozwiązania. Dzięki zdobytemu wcześniej doświadczeniu dość szybko zaproponowaliśmy nowy system oparty m.in. na rozwiązaniach open source dotyczących zarówno PSD2, jak i zakresu bezpieczeństwa. Nasz plan został zaakceptowany i w kolejnych miesiącach skrupulatnie się go trzymaliśmy, by w końcu go sfinalizować. Powstały system w pełni spełnia wymogi PSD2, wpisuje się w model multitenancy, jest łatwy w rozwoju i bezpieczny, co potwierdziły testy penetracyjne.

Stałe miejsce

Gdy wędruje się po górach, często wraca się w pewne miejsca. Niekiedy jest to wymuszone przez siatkę szlaków. Innym razem specjalnie planuje się trasę, żeby kolejny raz odwiedzić swoje ulubione, stałe miejsce.   

W moim doświadczeniu takim miejscem był ekran główny aplikacji (powszechnie znany jako dashboardowy). Pierwszym etapem pracy nad dashboardem był ogrom wysiłku włożony w to, by ten ekran stworzyć. Po początkowej fali prac nastąpił etap stabilizacji i spokojnego rozwoju związanego z optymalizacją kodu i zastępowaniem mocków docelowymi rozwiązaniami. Za każdym razem kiedy kończyłem swoją pracę, to wracałem właśnie tutaj, do tego stałego miejsca. W dashboardzie zawsze czekało na mnie zadanie, które było powiązane z moim obszarem prac i którym mogłem się zająć. Ostatnim etapem, który tak naprawdę nadal trwa, było oddanie tych aplikacji w ręce testerów.

Komplikacje

Choćby nam się wydawało, że jesteśmy przygotowani na wszystko, to natura zawsze potrafi zaskoczyć. Prognoza pogody pokazuje bezchmurne niebo, ale niedaleko zaczynają kłębić się czarne chmury zwiastujące burzę.

Momentem niepewności była decyzja o wprowadzeniu multitenancy. Model ten pozwala na działanie aplikacji w taki sposób, że jest jasne, w jakim kontekście (tenant) jest ona uruchomiona. Wszystkie zasoby aplikacji są współdzielone przez dane oprogramowanie, przez co szczególną uwagę należy zwrócić na potencjalny wyciek danych między kontekstami. Właśnie o ten kontekst chodzi. W czasie wdrażania tego rozwiązania, słowo to było odmieniane przez wszystkie przypadki, by jak najlepiej dopasować do niego aplikacje. Zmiany w konfiguracji, w sposobie instalowania ich w środowiskach – tutaj też sporo rzeczy związanych ze zmianami infrastrukturalnymi – zostały przekazane programistom, co pozwoliło na poszerzenie wiedzy. Ponownie odwołam się do przykładu z PSD2, w którym to dostępne rozwiązanie z zewnętrznym dostawcą byłoby bardzo trudno zaadaptować do nowego modelu, stąd decyzja o przejściu na własne rozwiązanie. Kolejną istotną kwestią było poprawne zaimplementowanie kontekstu w aplikacji, tak, by była ona nadal prosta w utrzymaniu i spełniała nowo postawione wymagania. Trzeba było uważać i nadal trzeba, by nie wpaść w pułapkę zaszywania biznesowej logiki w kodzie – to dobre ćwiczenie na asertywność. Wystarczy tylko jeden raz się ugiąć przed kuszącym szybkim rozwiązaniem, by potem zasadą precedensu wejść w niekończącą się spiralę trudnych do zrozumienia instrukcji warunkowych (tzw. ifologia stosowana). Chodzi przede wszystkim o to, by wyniki dobrze wdrożonych zmian mogły cieszyć oraz by nadal przyjemnie czytało się kod.

Każdy koniec jest zarazem początkiem

To już koniec historii, którą chciałem Wam opowiedzieć. Mam nadzieję, że teraz Wy wybierzecie się w swoją wyprawę i będziecie czerpać z niej satysfakcję.

Doświadczenie udziału w projekcie realizowanym dla firmy Vodeno uznaję za bardzo udane i cieszę się, że po raz kolejny miałem okazję robić coś po raz pierwszy. Kolejne zadania i wyzwania przede mną!

Autor artykułu – Kamil Magiera, Java Developer w Onwelo