Legacy code nie zawsze oznacza bardzo stary kod – to raczej kod, który nie jest przygotowany na przyszłość. Często przytacza się tu słowa Michaela Feathersa, który zdefiniował legacy code po prostu jako "kod bez testów". Innymi słowy, nawet świeżo napisany fragment może stać się legacy, jeśli brakuje mu testów i jasnej struktury. Najczęściej jednak chodzi o kod pisany dawno temu, przez kogoś, kogo już nie ma w zespole, pełen skrótów i tymczasowych rozwiązań. Taki kod bywa wyjątkowo trudny do zrozumienia i budzi uzasadnione obawy, bo nie wiemy, jak zareaguje na zmiany. Mimo to prędzej czy później trzeba go zrefaktoryzować – poprawić strukturę, czytelność i jakość – np. po to, by móc dodać nowe funkcje lub naprawić błędy.
W tym artykule znajdziesz kilka sprawdzonych praktyk, dzięki którym refaktoryzacja legacy code przebiegnie bez przykrych niespodzianek.
Przygotowanie do refaktoryzacji
Zanim napiszesz choćby linię nowego kodu, poświęć czas na zrozumienie istniejącego rozwiązania. W legacy code tkwią różne zależności i ukryte założenia, więc dobra analiza to podstawa.
Oto kroki, które warto wykonać na starcie:
• Przeanalizuj kod i kontekst: Przeczytaj uważnie fragment, który planujesz zmieniać. Poszukaj komentarzy, dokumentacji lub opisów commitów – każda wskazówka się liczy.
• Uruchom aplikację (lub moduł): Zobacz, jak ten kod działa w praktyce. Wejdź na ekran, który korzysta z legacy komponentu, wywołaj daną funkcjonalność. Im więcej zrozumiesz z bieżącego działania, tym lepiej.
• Sprawdź zależności: Ustal, co woła ten kod i co on sam wywołuje. Dzięki temu wiesz, które części systemu mogą zostać dotknięte Twoją zmianą.
• Wykonaj (lub dopisz) testy: Jeżeli istnieją testy automatyczne dla tego fragmentu – uruchom je i upewnij się, że przechodzą. Jeśli testów brak, rozważ dopisanie prostych testów charakteryzujących obecne zachowanie kodu. Nawet kilka podstawowych testów (lub ręcznych scenariuszy testowych) da Ci punkt odniesienia, czy po refaktoryzacji wszystko nadal działa.
Dobre przygotowanie daje Ci dwie korzyści: po pierwsze, nabierasz pewności co do działania kodu, a po drugie – tworzysz sobie sieć bezpieczeństwa. Testy (manualne lub automatyczne) pełnią rolę takiego asekuracyjnego pasa – ostrzegą Cię, gdyby refaktoryzacja coś zepsuła.
Refaktoryzacja małymi krokami
Główna zasada bezpiecznej refaktoryzacji brzmi: wprowadzaj zmiany małymi porcjami i często sprawdzaj efekty. Zamiast przepisywać cały moduł naraz, zmieniaj jedną rzecz na raz i od razu testuj.
Przykładowo:
• Najpierw popraw czytelność: zmień nazwę zmiennej na bardziej zrozumiałą albo wyodrębnij zbyt długi fragment kodu do osobnej metody. To zmiany, które nie wpływają na logikę, a ułatwią dalszą pracę.
• Po każdej małej modyfikacji uruchom testy (lub sprawdź aplikację ręcznie w krytycznych miejscach). Jeśli coś przestaje działać – od razu wiesz, gdzie szukać przyczyny.
• Korzystaj z systemu kontroli wersji: commituj często, zwłaszcza po udanej zmianie. W razie problemów łatwiej będzie wycofać konkretny commit niż cały dzień pracy.
• Wdróż zasadę "śpiesz się powoli" – wolniejsze, ostrożne zmiany paradoksalnie pozwolą ukończyć refaktoryzację szybciej, bo unikniesz czasu straconego na naprawianie dużych regresji.
Takie iteracyjne podejście sprawia, że cały czas trzymasz rękę na pulsie. Jeśli w którymś momencie coś pójdzie nie tak, natychmiast to zauważysz i cofniesz drobną zmianę zamiast stanąć przed widmem wielkiej awarii. Pamiętaj też o code review (jeśli pracujesz w zespole) – świeże spojrzenie kolegi może wychwycić potencjalny problem, zanim trafi on na produkcję.
Refaktoryzacja czy przepisanie od zera?
Czasem przy pracy z wyjątkowo trudnym kodem kusi myśl: "wyrzucić wszystko i napisać od nowa". Nowy kod od zera wydaje się czystszy i prostszy… niestety to pułapka, przed którą przestrzegają doświadczeni programiści. Pełne przepisanie działającego modułu rzadko bywa lepszą opcją – wymaga dogłębnego zrozumienia oryginału, a bez tego łatwo wpędzić się w niewykonalne zadanie. Dodatkowo, legacy code często skrywa istotne, lecz nieudokumentowane funkcjonalności i przypadki brzegowe, które w nowej wersji mogłyby zostać pominięte.
Zamiast totalnego przepisania od zera, postaw na ewolucyjną refaktoryzację. Małymi krokami poprawiaj strukturę i jakość kodu, upewniając się na bieżąco, że stara funkcjonalność nadal działa. Taka strategia bywa bezpieczniejsza i tańsza. Oczywiście, są sytuacje, gdy napisanie fragmentu od nowa ma sens (np. gdy stary kod jest zbyt błędny, a zakres działania dobrze rozumiesz). Jednak traktuj przepisanie od zera jako ostateczność, a nie pierwszy wybór.
Podsumowanie
Praca z legacy code to spore wyzwanie, ale jest możliwa do okiełznania. Kluczem jest cierpliwość i dyscyplina: najpierw analiza i zabezpieczenie się testami, potem małe kroki refaktoryzacji z ciągłym monitorowaniem efektów. Dzięki temu nawet stare, problematyczne fragmenty kodu można ulepszyć bez wywoływania niechcianych bugów. Co więcej, każde udane ulepszenie takiego kodu zwiększa Twoją pewność siebie i pozostawia projekt w lepszym stanie dla przyszłych programistów.
Warto też wyciągnąć z tego lekcję na przyszłość: pisząc nowy kod, dbaj o jego jakość i testy, aby to, co tworzysz dziś, nie straszyło jako legacy code za rok czy dwa. Jeśli dopiero zaczynasz swoją drogę programisty i chcesz nauczyć się dobrych praktyk (w tym pisania czystego, łatwo testowalnego kodu), zapraszam Cię do mojego kompletnego szkolenia online "Zostań Programistą .NET". To kompleksowy program, w którym w ciągu 3 miesięcy przechodzisz od absolutnych podstaw C#/.NET do poziomu junior developera gotowego do pierwszej pracy. Uczymy się tam m.in. jak tworzyć solidny kod od początku – tak, by w przyszłości uniknąć tworzenia kolejnego legacy code. Powodzenia w refaktoryzacji.
