Wzorce do pracy z legacy

Chciałbym powiedzieć o kilku wzorcach których możemy użyć w czasie pracy z różnymi projektami tak zwanymi legacy. Wzorce te mam sprawdzone w bojach na różnych projektach więc będę odnosił się do konkretnych przypadków które faktycznie były zaimplementowane.

Transcript

1. Wzorce do pracy z legacy Leszek Prabucki PHP/Angular Tech Leader | www.iteo.com leszek.prabucki@iteo.com / linkedin.com/in/leszek-prabucki/
2. 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.
3. 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
4. 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
5. 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)
6. 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
7. 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)
8. 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
9. 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
10. 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
11. 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
12. 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
13. 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
14. 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
15. 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ść
16. Dzięki! Leszek Prabucki PHP/Angular Tech Leader | www.iteo.com https://joind.in/talk/39173