Legacy Code z czasem staje się coraz gorszy

Kod legacy nie staje się lepszy z czasem. Staje się gorszy.

W zeszłym tygodniu spędziłem trzy godziny na naprawianiu błędu. Powinno to zająć 20 minut. Problemem był moduł walidacji z 2019 roku. Wszyscy go ignorowali, bo „działa”. Nie działał. Wewnątrz pliku znalazłem komentarz TODO z 2020 roku.

Wiele osób traktuje kod legacy jak opcjonalny dług. Myślą, że mogą go spłacić, gdy znajdą czas. Kod legacy jest bardziej jak pleśń. Rozprzestrzenia się. Zanieczyszcza inne części systemu. Im dłużej go ignorujesz, tym droższe staje się jego czyszczenie.

To tworzy błędne koło:

  • Dziedziczysz niechlujny projekt.
  • Dodajesz jeszcze jedną instrukcję if, aby Twoja funkcja działała.
  • Pół roku później ktoś inny robi to samo.
  • Rok później plik ma 800 linii i zero testów.

Ten „działający” kod ma ukryte koszty:

  • Prędkość rozwoju spada. Spędzasz więcej czasu na czytaniu kontekstu niż na pisaniu kodu.
  • Liczba błędów rośnie. Naprawa jednej rzeczy psuje coś innego.
  • Onboarding staje się trudny. Nowi programiści mają problem ze zrozumieniem, dlaczego logika jest powielana wszędzie.

Uważaj na te sygnały ostrzegawcze:

  • Bezużyteczne lub wprowadzające w błąd komentarze.
  • Powielona logika biznesowa w różnych plikach.
  • Cykliczne zależności i wysokie sprzężenie.

Nie próbuj przepisywać wszystkiego. Całkowite przepisanie kodu kończy się niepowodzeniem w 80% przypadków. Spędzasz miesiące na odbudowywaniu tego, co już istnieje, podczas gdy biznes czeka na nowe funkcjonalności.

Stosuj przyrostkową refaktoryzację z testami charakterystyki:

  • Uchwyć obecne zachowanie za pomocą testów, nawet jeśli jest dziwne.
  • Przeprowadź refaktoryzację bez zmiany tego zachowania.
  • Powtarzaj, aż kod stanie się czytelny.
  • Dopiero wtedy zmień zachowanie, używając właściwych testów.

Przestrzegaj tych zasad, aby uniknąć pułapek:

  • Nigdy nie refaktoryzuj bez testów.
  • Nie zmieniaj zachowania podczas refaktoryzacji. Błąd może być nieudokumentowaną funkcją, na której polega klient.
  • Zostaw „cichy” kod w spokoju. Jeśli moduł nie zmieniał się od trzech lat i nie powoduje problemów, zostaw 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