Praca z legacy code

Rozwój oprogramowania w pracy z legacy code może być trudny i zazwyczaj nieunikniony, jeśli nie zaczynasz projektu od zera. A to oznacza, że potrzebujesz dobrego sposobu na pracę z nim.

Czym jest legacy code?

Klasyczna definicja

To każdy kod utrzymywany przez kogoś, kto go nie napisał.

Nowe definicje

Każdy kod, którego nie rozumiesz i który trudno jest zmienić.

Może się to odnosić do kodu odziedziczonego po kimś innym lub po wcześniejszej wersji oprogramowania. Sformułowanie może się również odnosić do kodu bez testów jednostkowych.

Praca z legacy code w procesie rozwoju oprogramowania jest wyzwaniem!

Największym wyzwaniem przy pracy ze starą bazą kodową mogą być twoje założenia na ten temat.

Jeśli masz wrażenie, że kod jest zły, sam napisałbyś go lepiej, a ktokolwiek go stworzył, nie wiedział, co robi, to musisz uważać, by samemu nie wpaść w pułapkę. Zazwyczaj istnieje powód, dla którego kod wygląda tak, jak wygląda, a skoro go nie napisałeś, to po prostu możesz go nie znać. Sprawia to, że rozwój oprogramowania nie jest wcale taki łatwy, jak na początku może się wydawać. 

Dlatego ulepszając dotychczasową bazę kodową, trzeba zachować ostrożność. Fragment, który zmieniamy, może zawierać zależności, których nie jesteśmy jeszcze świadomi. Ważne jest, by wiedzieć, kiedy utrzymywać, a kiedy zmieniać dotychczasową bazę kodową.

Jak pracować z legacy code 

Na pewno nie ulepszysz starej bazy kodowej w ciągu jednej nocy. Skup się na stopniowych ale przemyślanych krokach, by ją poprawić.

Niezależnie od tego, czy dopiero zaczynasz pracę z dotychczasową bazą kodową, czy też pracujesz nad nią już od jakiegoś czasu, podajemy osiem wskazówek, jak ją ulepszyć:

1. Przetestuj kod

Jednym ze sposobów na zrozumienie kodu jest stworzenie testów charakteryzacji i testów jednostkowych. Możesz też uruchomić analizator statyczny nad swoim kodem, aby zidentyfikować potencjalne problemy.

Dzięki temu zrozumiesz, co naprawdę robi kod, a ten ujawni wszelkie potencjalnie problematyczne obszary. Kiedy już go zrozumiesz, będziesz mógł wprowadzać zmiany z większą pewnością siebie.

2. Przejrzyj dokumentację

Przeglądanie dokumentacji dotyczącej oryginalnych wymagań pomoże Ci zrozumieć, skąd pochodzi kod, a to z kolei dostarczy informacji, jak ulepszyć go, nie narażając systemu na szwank. Pomijając te istotne kroki, można przypadkowo wprowadzić zmiany, które wywołają niepożądane zachowania.

3. Napisz ponownie kod tylko wtedy, gdy jest to konieczne.

Przepisanie starej bazy kodowej może być kuszące, ale zazwyczaj to błędne działanie, gdyż przepisanie wszystkiego zajmuje zbyt dużo czasu i kosztuje wiele siły roboczej. Nawet jeśli się na to zdecydujesz, przepisanie kodu może wprowadzić nowe błędy lub usunąć ukryte funkcje.

4. Zamiast tego – zrefaktoryzuj.

Refaktoryzacja to proces zmiany struktury kodu bez zmiany jego funkcjonalności. Oczyszcza to kod i czyni go łatwiejszym do zrozumienia. Eliminuje również potencjalne błędy. Lepiej więc zrefaktoryzować starą bazę kodową, niż ją przepisać. Działanie takie przeprowadzamy stopniowo:

• Zrefaktoryzuj kod, który posiada testy jednostkowe – dzięki temu wiesz, nad czym pracujesz.
• Zacznij od najgłębszego punktu kodu – jest najłatwiejszy do refaktoryzowania.
• Testuj po refaktoryzacji - aby upewnić się, że niczego nie popsułeś.
• Posiadaj sieć bezpieczeństwa - np. Continuous Integration - abyś mógł wrócić do poprzedniej wersji.

5. Dokonaj zmian w różnych cyklach rewizyjnych

Nie rób zbyt wielu zmian na raz. To zły pomysł, aby w tym samym cyklu recenzencyjnym, co zmiany funkcjonalne, ponownie wprowadzać inne zmiany.

Ponadto, ułatwia to recenzje kodu - odosobnione zmiany są o wiele bardziej oczywiste niż ich nagromadzenie.

6. Współpraca z innymi programistami

Być może nie znasz zbyt dobrze bazy kodowej, ale niektórzy z twoich kolegów programistów pewnie tak. Więc o ile jest to możliwe, współpracuj z kimś, kto wie o niej więcej niż Ty. Drugie spojrzenie na kod może pomóc Ci lepiej go zrozumieć i przyspieszy wykonywanie zadania.

7. Utrzymuj nowy kod w czystości

Napisanie nowego kodu zgodnie z najlepszymi praktykami sprawi, że będzie mniej problematyczny. Nie możesz kontrolować jakości dotychczasowej bazy kodowej, ale możesz sprawić, by nowo utworzony kod był czysty.

8. Zrób dalsze badania

Z czasem praca ze starą bazą kodową staje się łatwiejsza. Młodszy programista może nie rozumieć, dlaczego baza kodowa nie została przerobiona (i może być chętny do przerobienia jej), ale starszy deweloper będzie wiedział, kiedy nie powinno się jej ruszać.

Kiedy dowiesz się więcej o bazie kodowej, będziesz mógł ją ulepszyć.

Dobrym punktem wyjścia jest "Working Effectively With Legacy Code" autorstwa Michaela C. Feathersa, który zawiera kilka dobrych przykładów, jak poprzez rozwój oprogramowania wprowadzać zmiany w bazie kodowej.

Innym źródłem jest "Refactoring: Improving the Design of Existing Code" autorstwa Martina Fowlera. Książka ta zawiera wiele wskazówek dotyczących skutecznego refaktoringu kodu.

Rozwój oprogramowania - narzędzia do pracy z istniejącym kodem

Rozwój oprogramowania wiąże się z kilkoma wyzwaniami. Zazwyczaj będziesz musiał pracować ze starą bazą kodową - lub wokół niej. W końcu z pewnością  kod znalazł się tam z jakiegoś powodu.

Istnieją też dobre powody do wprowadzania zmian w kodzie. Może to być dodawanie funkcji, naprawianie błędów lub ulepszanie projektu.

W idealnym świecie ciągle przepisujesz starą bazę kodową, aż do momentu, gdy zostanie ona całkowicie usunięta. Ale możliwe, że nie będzie to praktyczne.

Musisz więc dowiedzieć się, co możesz zmienić, a resztę zostawić w spokoju.

Statyczna analiza kodu i kod legacy

Jednym ze sposobów jest użycie statycznego narzędzia do analizy kodu. Można ustawić poziom bazowy, a następnie przeprowadzić analizę nowego kodu, aby upewnić się, że jest on czysty. Można też wyłączyć wyniki z dotychczasowej bazy kodowej.

Przykładowo Helix QAC sprawia, że jest to bardzo łatwe do zrobienia.

Analizuj kod legacy

Helix QAC może sprawdzić Twoją dotychczasową bazę kodową pod kątem zgodności z regułami, zazwyczaj pochodzącymi ze standardu kodowania, dzięki czemu dostaniesz diagnostykę naruszeń. Szeregując je według ważności, możesz w pierwszej kolejności skupić się na naprawieniu najbardziej obciążonych błędami fragmentów dotychczasowej bazy kodowej.

Określanie wartości bazowych

Możesz również ustawić swoją dotychczasową bazę kodową jako punkt odniesienia, jeśli np. kod jest dobry i nie chcesz go zmieniać. Ustawienie linii podstawowej oznacza, że dotychczasowa baza kodowa nie zostanie wciągnięta do diagnostyki. Zamiast tego możesz skupić się na znalezieniu problemów w nowym kodzie i zapewnieniu, że jest on czysty.

Używaj Tłumików

Możesz użyć tłumików do tworzenia wyjątków dla swojej dotychczasowej bazy kodowej, więc można zasadniczo odrzucić naruszenia w nim. Możesz ustawić tłumienie do określonych zasad lub naruszeń w ramach określonej kategorii.

Zapewnienie zgodności

W niektórych przypadkach może się zdarzyć, że będziecie ponownie używać starej bazy danych z jednego projektu do drugiego. Ale niektóre z nich nie zostały opracowane w oparciu o standardy kodowania. Jeśli trzeba osiągnąć zgodność (np. z MISRA), może to stwarzać problemy. Używając Helix QAC z MISRA, łatwo zaobserwować, gdzie w kodzie znajdują się błędy.

► Jeżeli potrzebujesz wsparcia w rozwoju oprogramowania, skontaktuj się z nami!