Wzorce do pracy z legacy Leszek Prabucki PHP/Angular Tech Leader | www.iteo.com [email protected] / linkedin.com/in/leszek-prabucki/

Jak Ja definiuje system legacy? ● Brak możliwości aktualizacji: Systemy legacy są zazwyczaj starsze i mogą nie być już wspierane przez producenta. Nie są one regularnie aktualizowane, co może prowadzić do problemów z bezpieczeństwem i kompatybilnością. ● Krytyczne dla biznesu: Często są kluczowe dla działania firmy, ponieważ przez lata były rozwijane i integrują wiele procesów biznesowych. Ich nagła wymiana byłaby kosztowna i ryzykowna. ● Trudne w utrzymaniu: Utrzymanie systemów legacy może być trudne i kosztowne. Często styl ich pisania jest już przestarzały i nie jest czytelny. Zmiany wymagają dużo czasu i debugowania. ● Brak elastyczności: Systemy te zazwyczaj nie są elastyczne i trudno je modyfikować lub integrować z nowoczesnymi rozwiązaniami technologicznymi. ● Problemy z bezpieczeństwem: Starsze systemy mogą mieć luki bezpieczeństwa, które nie są już naprawiane, co naraża firmę na ryzyko ataków. ● Zależność od przestarzałych technologii: Mogą być zależne od technologii, które są już nieużywane lub trudne do zdobycia, co utrudnia ich dalsze utrzymanie i rozwijanie.

Use case 1: Kalkulator ofert leasingowych ● Projekt ma ponad 15 lat (zmigrowany z svn w 2017 roku) ● Cześć monolitycznego systemu oparta o PHP która odpowiadała za odpowiednie obliczenia kosztów leasingu dla danych ofert i umów ● Problemy z utrzymaniem, struktura zmieniana przez lata, stary nieużywany kod nie był usuwany przez wiele lat. Kontrola wersji przez dziedziczenie + ifkologię ● Próby restrukturyzacji i przeniesienia części kodu do Laravela, niestety nie dokończone co spowodowało tylko to że projekt był jeszcze mniej zrozumiały ● Brak rozgraniczenia widoków od logiki ● Brak sensownego routingu i frameworka ● Duże powiązanie wszystkiego ze sobą - zmiany w formularzu mogły zmienić coś w kalkulacji ● Dane zapisywane i dostarczane w archaicznej bazie danych (FireBird) ● System krytyczny dla działania biznesu - zmiany w systemie czy stawkach muszą być potwierdzone uchwałą zarządu ● 1 osoba która jest w stanie utrzymywać system

Use case 1: Kalkulator ofert leasingowych - jak pracowaliśmy nad projektem ● Audyt (zrobiony przez ludzi z zewnątrz) ● Analiza po naszej stronie ● Przygotowanie planu migracji, debugowanie obecnego kodu, dokumentacja oraz architektura rozwiązania (między innymi wykresy z C4 model) ● Zdecydowaliśmy się (również zgodnie z sugestiami z audytu) na podejście przy użyciu Parallel Models ● Oba modele zintegrowane razem, oraz mechanizm porównywania ich rezultatów

Use case 1: Kalkulator ofert leasingowych - Parallel Models Opis wzorca: Parallel Models polega na utrzymaniu dwóch modeli (starego i nowego) jednocześnie, aby umożliwić stopniową migrację danych i funkcjonalności bez przerywania działania systemu, lub sprawdzenia działania modeli pod względem jakiś wybranych przez nas metryk ● https://martinfowler.com/bliki/ParallelModel. html Dlaczego ten wzorzec? ● Możliwość testowania na produkcji poprzez porównanie starych i nowych rezultatów ● Możliwość wydzielenia kalkulatora do nowego kontekstu (aplikacji)

Use case 1: Kalkulator ofert leasingowych - Parallel Models Można też poczytać o tym podejściu w poście w którym to opisałem https://tinyurl.com/iteo-legacy-calculator

Use case 2: ATS z integracją EBOK ● Projekt ma ponad 15 lat (zmigrowany z svn w 2015 roku) ● Monolityczny system który służył do obsługi agencji HR ● Proof of concept tworzony na szybko, przez ludzi bez odpowiedniego doświadczenia ● Bardzo trudny w utrzymaniu, tworzenie nowych funkcjonalności trwało długo ● System rozwojowy dla biznesu - pełno pomysłów do realizacji, na część pobrane granty z unii ● Brak sensownego routingu i frameworka ● 1 osoba która jest w stanie utrzymywać system ● Nasze zadanie wprowadzenie modułu EBoK ale bez za dużej integracji w obecne rozwiązanie (utrzymuje inna osoba)

Use case 2: ATS z integracją EBOK - jak pracowaliśmy nad projektem ● Analiza istniejącego kodu i debugowanie istniejącego kodu ● Podejście BDD do opisu funkcji EBOK ● Identyfikacja miejsc w których możemy podpiąć się integrować z starym systemem przez ACL ● Debugowanie i rozumienie starego modelu ● Duża warstwa testów funkcjonalnych w ACLu

Use case 2: ATS z integracją EBOK - ACL Opis wzorca: Anti-corruption Layer (ACL) tworzy warstwę izolującą stary system od nowego, chroniąc go przed potencjalnym "zanieczyszczeniem" niechcianymi zależnościami i różnicami w modelach danych. (Zobacz też Bubble Context) ● https://martinfowler.com/bliki/AntiCorruptionLay er.html ● Wzorce projektowe: adapter i repozytorium Dlaczego ten wzorzec? ● Możliwość pisania nowego kodu i synchronizacji z starym przez API lub po bazie danych lub kolejkach ● Nie trzeba się tak dużo przejmować zmianami w części legacy po za naszym kontekstem

Use case 2: ATS z integracją EBOK Można też poczytać o tym podejściu w poście w którym to opisałem https://tinyurl.com/iteo-legacy-acl

Use case 3: Modernizacja API ● Projekt ma ponad 7 lat ● BFF - backend for frontend napisany w Symfony ● Możliwość dostępu po REST jak i GraphQL ● API Platform ● Projekt raczej CRUDowy ● Duże problemy z wydajnością, trzeba było zaciągnąć varnisha do http proxy cache ● Dużo annotacji/atrybutów do sterowania serializacją ● System mógł być utrzymywany przez kilka osób ● Sporo integracji

Use case 3: Modernizacja API - Strangler Fig Application Opis wzorca: Metoda stopniowego zastępowania starego systemu nowym poprzez wycinanie i zastępowanie funkcji. Zapewnia ciągłość działania i minimalizuje ryzyko. W tym wypadku przy użyciu infrastruktury mogliśmy przekierować konkretne RESTowe entrypointy na nową aplikacje Dlaczego ten wzorzec? ● Możliwość przepisania części aplikacji webowej bez integracji w obecny system przy uwzględnieniu potrzeb biznesowych (mniejszy koszt) ● Mogliśmy zachować kontrakt starej aplikacji

Use case 3: Modernizacja API - Strangler Fig Application Można też poczytać o tym podejściu w poście w którym to opisałem https://tinyurl.com/iteo-legacy-strangler

Use case 4: Poprawki w systemie e-commerce związane z deadlockami - testy charakteryzacyjne ● Projekt ma 4 lata ● E-commerce stworzony w Laravelu 5.2 ● System aktywnie utrzymywany ● Niska jakość kodu ● Dużo problemy z wydajnością oraz rzeczami takimi jak deadlocki w czasie składania zamówienia ● Nasze zadanie to zlikwidowanie deadlocków

Use case 4: Poprawki w systemie e-commerce związane z deadlockami - testy charakteryzacyjne Opis wzorca: Testy charakteryzacyjne są to testy automatyczne które powinny nam sprawdzić aktualne zachowanie kodu legacy W tym przypadku mogliśmy napisać warstwę testów integracyjnych na część aplikacji odnośnie zamówień w której występują deadlocki. Przy użyciu narzędzi do pokrycia kodu z phpunit zapewniliśmy się że pokryliśmy wszystkie istotne miejsca w kodzie. Dlaczego ten wzorzec? ● Nie chcemy wprowadzać w regresji ● Nie chcemy zmieniać zachowania w aktualnej wersji, tylko chcemy poprawić strukturę (zmniejszyć czas transakcji) oraz wydajność

Dzięki! Leszek Prabucki PHP/Angular Tech Leader | www.iteo.com https://joind.in/talk/39173