Legacy Code staje się gorszy z upływem czasu

Kod legacy nie starzeje się jak wino. Staje się gorszy z każdym dniem, w którym go ignorujesz.

W zeszłym tygodniu spędziłem trzy godziny na debugowaniu problemu, który powinien zająć 20 minut. Winowajcą był moduł walidacji z 2019 roku. Ludzie zostawiali go w spokoju, bo działał. Nie działał. Znalazłem komentarz „TODO: refactor this” z 2020 roku.

Wielu traktuje kod legacy jako opcjonalny dług. Myślą, że spłacą go, gdy tylko znajdą czas. Kod legacy działa jak pleśń. Rozprzestrzenia się. Zainfekuje wszystko wokół. Im dłużej zwlekasz, tym droższe staje się jego sprzątanie.

Cykl jest przewidywalny:

  • Dziedziczysz niechlujną, ale działającą funkcjonalność.
  • Dodajesz jeszcze jedną instrukcję „if”, aby to zadziałało.
  • Pół roku później ktoś inny robi to samo.
  • Rok później plik ma 800 linii i zero testów.

Ten ukryty koszt uderza w Ciebie na trzy sposoby:

  • Spada prędkość. Spędzasz więcej czasu na zrozumieniu kontekstu niż na pisaniu kodu.
  • Przybywa błędów. Jedna poprawka psuje coś innego, ponieważ logika jest splątana.
  • Onboarding zawodzi. Nowi programiści mają trudności ze zrozumieniem, dlaczego ta sama logika istnieje w siedmiu różnych miejscach.

Uważaj na te sygnały ostrzegawcze:

  • Bezużyteczne komentarze typu „HACK: do not touch this”.
  • Duplikująca się logika biznesowa w różnych plikach.
  • Cykliczne zależności, w których usługi zależą od siebie nawzajem.

Nie przepisuj wszystkiego. Całkowite przepisywanie kończy się niepowodzeniem w 80% przypadków. Zamiast tego stosuj stopniową refaktoryzację z wykorzystaniem testów charakterystyki.

Postępuj zgodnie z tym procesem:

  • Uchwyć obecne zachowanie za pomocą testów, nawet te dziwne fragmenty.
  • Przeprowadź refaktoryzację kodu bez zmiany tego zachowania.
  • Powtarzaj, aż kod stanie się czytelny.
  • Zmieniaj zachowanie dopiero wtedy, gdy będziesz mieć prawdziwe testy.

Zasady, których należy przestrzegać:

  • Nigdy nie refaktoryzuj bez testów.
  • Unikaj ulepszeń, które zmieniają sposób działania kodu. Błąd może być funkcjonalnością, na której polega klient.
  • Zostaw „cichy” kod w spokoju. Jeśli moduł nie zmieniał się od trzech lat i nie powoduje problemów, nie ruszaj go.

Skup swoją energię na kodzie, który często modyfikujesz.

Źródło: https://dev.to/taina_costa_f/legacy-code-nao-envelhece-como-vinho-quanto-mais-espera-pior-fica-132h