Najczęściej spotykane problemy w pracy z legacy code

Praca z legacy code jest niemal nieunikniona i z pewnością nie należy do najłatwiejszych zadań. Właściwe podejście do przestarzałych systemów pozwala jednak na zakończenie projektu sukcesem. Jakie trudności możesz napotkać podczas pracy z legacy code?

Starsze projekty zwykle wiążą się z koniecznością podjęcia decyzji o tym, czy kod nadal powinien być utrzymywany lub czy wymaga znaczących modyfikacji. Utrzymanie starego kodu to nie tylko poświęcenie czasu i pieniędzy, ale też części zespołu, zatem jednym z największych wyzwań jest przekonanie klienta o konieczności refaktoryzacji i odpowiedniego zmotywowania programistów. 

Czym jest legacy code?

Dla mnie jest to przestarzały i niestrukturyzowany kod, napisany niechlujnie, bez użycia frameworków i bez dokumentacji, wykorzystujący biblioteki, które nie są już wspierane. Jest to więc kod pełen niedociągnięć, przez co staje się trudny do utrzymania. 

Grzegorz, Backend Developer

Warto jednak pamiętać, że, mimo że jest to kod napisany w starej technologii, to nadal działa, więc ma wartość biznesową. Programiści powinni więc wziąć to pod uwagę, bez zbyt pochopnego oceniania kodu.

Jakie są najczęstsze problemy podczas pracy ze starszymi systemami?

1. Niechęć programistów do pracy z legacy code

Prawda jest taka, że programiści nie chcą zajmować się czyimś kodem. Niemal każdy chce pracować przy projekcie od podstaw, wykorzystując nowe technologie. Daje to programistom pełną kontrolę nad kodem, więc są bardziej zmotywowani podczas kodowania.

Legacy code zwykle idzie w parze z dużymi systemami, opracowywanymi przez lata, więc takie projekty mogą zniechęcać programistów już na początku pracy. W związku z tym, celem jest zaszczepienie w zespole właściwego podejścia do pracy ze starszym kodem, co pomoże uniknąć dużej rotacji w zespole. 

Kiedy software house postrzega refaktoryzację jako lekarstwo na dług technologiczny, członkowie zespołu czują, że robią rzeczy, które mają znaczenie. Dlatego jednym z najważniejszych zadań project managera jest podniesienie morale pracowników, co pozytywnie wpływa na skrócenie czasu poświęconego na analizę i zrozumienie legacy code. 

2. Wywieranie nacisku na tworzenie nowych funkcjonalności

Im dłużej odkłada się refaktoryzację, tym więcej pracy zespół będzie miał w późniejszym etapie. Dodatkowo presja wywierana przez klientów na tworzenie coraz większej liczby funkcjonalności niekorzystnie wpływa na produkt. Z biznesowego punktu widzenia więcej funkcjonalności oznacza więcej pieniędzy, jednak może to mieć spory wpływ na obniżenie jakości kodu. 

Project manager powinien szybko reagować w takich sytuacjach, a jego obowiązkiem jest uświadomienie klientom, że taka krótkowzroczność może w znacznym stopniu obniżyć jakość produktu. Ważne jest więc uświadomienie przedstawicieli biznesu, że liczy się czas przeznaczony na refaktoryzację, której wynikiem będzie ulepszenie projektu. 

3. Każda nowa funkcjonalność może zaszkodzić istniejącej aplikacji

Dodanie nawet niezbyt istotnej funkcjonalności może mieć wpływ na pracę całej aplikacji, a uzupełnienie kodu o kolejne linijki może przyczynić się do pogłębienia długu technologicznego. 

Jest to szczególnie powszechne w aplikacjach monolitycznych, w których jeden element zależy od drugiego, zatem pojedyncza zmiana może wpłynąć na inne części aplikacji. Takie aplikacje wymagają więc dodatkowego czasu na przetestowanie rozwiązania. 

4. Brak dokumentacji

Przeglądanie dokumentacji pomaga zrozumieć kod. Jeśli dokumentacja jest niekompletna lub w ogóle jej nie ma, wdrożenie projektu IT może zająć znacznie dłużej niż oczekiwano. 

To samo dotyczy przestarzałej dokumentacji, która właściwie jest bezużyteczna dla programistów. Zrozumienie źle napisanej aplikacji może więc potrwać tygodnie, co z kolei generuje dodatkowe koszty. 

5. Przepisanie kodu nie zawsze jest rozwiązaniem

Jeśli uważasz, że przepisanie kodu na nowo jest dobrym rozwiązaniem, upewnij się, że to się opłaci. Takie rozwiązanie jest kuszące, ale zazwyczaj zajmuje dużo czasu i pochłania zasoby firmy, więc powinna to być decyzja biznesowa, a nie techniczna. Warto też wziąć pod uwagę możliwość pojawienia się błędów, które nie występowały w obecnej wersji aplikacji. 

Zdarza się, że decyzja o przepisaniu kodu jest słuszna. Przykładem jest rozbicie aplikacji monolitycznej na mikroserwisy, co staje się coraz popularniejsze wśród programistów. 

Podsumowanie

Decyzja o przepisaniu kodu powinna być dobrze przemyślana i poparta korzyściami biznesowymi. Zwykle lepszym rozwiązaniem jest refaktoryzacja kodu, która pomaga wyeliminować problemy, zanim staną się kosztowne. 

Zrozumienie legacy code i przekształcenie go w aplikację spełniającą oczekiwania biznesowe klienta może być prawdziwym utrapieniem dla programistów. Z odpowiednim podejściem praca z przestarzałym kodem może jednak przynieść sporo satysfakcji.