Poprawa produktywności systemu poprzez refaktoryzację
Bardzo często, w systemach informatycznych, wraz ze wzrostem ilości funkcjonalności rośnie także trudność dodawania nowych. System staje się coraz cięższy w utrzymaniu i rozwoju, a koszty utrzymania zaczynają przekraczać koszty wprowadzania nowych funkcjonalności.
Poniższy obrazek przedstawia wspomnianą zależność.
Tego typu sytuacje najczęściej są bardzo złym znakiem wskazującym na duże problemy w systemie. Jedynym ze sposobów podnoszenia produktywności jest wprowadzenie do zakresu projektu fazy refaktoryzacji — czyli iteracyjnej modyfikacji kodu, która nie powoduje zmian funkcjonalnych. Celem procesu refaktoryzacji jest poprawienie atrybutów jakościowych systemu, takich jak łatwość utrzymania, rozszerzalność, wydajność, skalowalność, obserwowalność oraz elastyczność.
O kliencie
Britenet przeprowadził proces re-architektury systemu w firmie Education First. To ogólnoświatowy lider z branży edukacyjnej, który od ponad 50 lat oferuje przełomowe możliwości w zakresie nauki języków obcych dla osób w każdym wieku, różnych narodowości i środowisk. Firma posiada ponad 600 biur w ponad 60 krajach na wszystkich kontynentach. Kilka lat temu, w celu poprawy wydajności i szybkości obsługi klientów, jeden z działów Education First postanowił przenieść swój system CRM na platformę Salesforce.
Analiza i cele
Britenet rozpoczął pracę kilka miesięcy po go live systemu. Niestety, już wtedy system wykazywał znamiona erozji. Dość często dochodziło do przekroczenia limitów platformy. Było to spowodowane nieprawidłowym wykonaniem funkcjonalności i prowadziło do uszkodzenia danych. Dlatego też, poza dalszym rozwojem systemu, jednym z celów projektu stało się osiągnięcie szeroko idącej skalowalności, która umożliwi stabilną pracę przy jednoczesnym obciążeniu na poziomie kilku tysięcy użytkowników i napływie od kilkudziesięciu do kilkuset tysięcy rekordów dziennie. Oczywiście to wszystko przy zachowaniu ciągłej, nieprzerwanej pracy systemu oraz wysokiego poziomu rozszerzalności.
Plan
Wysokie wymagania wymuszały szeroki zakres zmian w architekturze systemu. Dlatego też specjaliści Britenet przeszli z mocno proceduralnego podejścia na podejście obiektowe, jednocześnie starając się dobrze określić zakres odpowiedzialności i relacje pomiędzy modułami systemu.
Do procesu wytwarzania wprowadzono standardy kodowania, wymóg pisania dobrej jakości testów jednostkowych, proces statycznej analizy kodu oraz peer review.
Przygotowano plan priorytetyzujący te zadania, które wymagały najmniejszej ilości pracy, dając jednocześnie najlepsze rezultaty. W każdym sprincie wprowadzano od 10 do 30% zadań technicznych w taki sposób, aby nie kolidowały z implementacją nowych wymagań biznesowych.
Efekty
Szybkość i wydajność systemu
Britenet zbudował moduł ułatwiający optymalizowanie wykonywania funkcjonalności oraz redukujący ilość operacji bazodanowych. Zredukowano ilość cyklicznych zależności w logice oraz przeniesiono większość funkcjonalności z wolnych Process Builderów do kodu w triggerach.
Skalowalność
Britenet wprowadził moduł naśladujący działanie Messaging Queues oparty o Salesforce Platform Events, który umożliwia kolejkowanie zadań oraz ich ponowne przetwarzanie w przypadku wystąpienia błędów. Zastosowano także generyczny mechanizm wywołań asynchronicznych kodu, umożliwiający dynamiczny dobór odpowiedniej strategii w zależności od kontekstu wywołania (np. kod wykonywany podczas pracy użytkownika systemu wykonywany jest synchronicznie, ale te same funkcjonalności dla procesów integracyjnych wykonywane są asynchronicznie).
Obserwowalność
Wprowadzono mechanizmy logowania błędów oraz śledzenia ilości i szybkości wywołań asynchronicznych, stanu kolejek systemowych, limitów platformy i stanu głównych procesów automatycznych w systemie. Pojawiła się możliwość tworzenia raportów i dashboardów pokazujących co aktualnie dzieje się w systemie od strony technicznej. Zastosowano także notyfikacje mailowe na temat niepoprawnego działania systemu.
Rozszerzalność i elastyczność
Podczas procesu refaktoryzacji większość kodu została rozbita na małe, proste klasy, przy jednoczesnej dbałości o utrzymanie odpowiednich zależności i zakresu odpowiedzialności. Wiele konfiguracji wyniesiono do Custom Settings oraz Custom Metadata. Stosując wzorzec Feature Toggle, Britenet sprawił, że praktycznie każda funkcjonalność może zostać dezaktywowana z poziomu administratora.
Łatwość utrzymania
Aby mieć pewność, że nie pojawią się nowe błędy Britenet zwiększył liczbę testów jednostkowych (z 200 do 1700). W efekcie zbudowano dobrze przetestowane i stabilne narzędzia, na których oparto logikę biznesową. Poprawiono jakość kodu redukując dług techniczny wskazany przez narzędzie statycznej analizy kodu (z 22k do 3k). Znacząco zmniejszono zużycie limitów platformy (np, daily async apex limit z około 800k do 100k, daily api calls limit z około 1 500k do 600k).
Poniższy diagram przedstawia raport ilości nierozwiązanych błędów per miesiąc. Kolorem niebieskim zaznaczony został czas od momentu wprowadzenia procesu refaktoryzacji do momentu ukończenia procesu re-architektury w około 80%.
Jak można zauważyć, proces refaktoryzacji nie przynosi natychmiastowych rezultatów, ale z biegiem czasu bardzo ułatwia utrzymanie i rozwój systemu, znacząco eliminuje błędy i utrudnia ich powstawanie.
