Czym jest refaktoring kodu?
Refaktoring kodu do proces poprawy jakości kodu ale bez zmiany jego funkcjonalności. Polega na przekształceniu kodu który już istnieje w kod który będzie czytelniejszy i w którym łatwiej wprowadzić modyfikacje lub nowe funkcjonalności a więc łatwiej rozwijać produkt na szeroką skalę.
Refaktoring kodu nie jest tak widoczny z zewnątrz jak wprowadzanie nowych funkcjonalności ale w pewnych sytuacjach może okazać się niezbędny.
Kiedy jest potrzebny refaktoring kodu?
Refaktoryzacja kodu odgrywa szczególną rolę w aplikacjach które były tworzone przez długi czas, które są zaniedbane lub zostały napisane bez zastosowania dobrych praktyk np. gdy pracowało nad nimi wielu freelancerów. W takich aplikacjach mogły być sytuacje w których zostały usunięte pewne funkcjonalności ale nie ze wszystkich miejsc w kodzie. Lub zostało dodane wiele nowych funkcjonalności, następnie zostały zmienione i obecny kod jest trudny do zrozumienia. Albo ze względu na niski budżet kod był tworzony w pośpiechu. Możliwe także, że pierwotny kod jest zbyt mało elastyczny żeby wprowadzić w nim nowe funkcjonalności albo nie jest w stanie obsłużyć zwiększonego ruchu użytkowników. Lub po prostu został napisany na przestarzałych bibliotekach.
Jakich praktyk się trzymać przy refaktoringu kodu?
Don’t Repeat Yourself
Podczas refaktoringu kodu powinniśmy trzymać się zasady Don’t Repeat Yourself (DRY), czyli unikania powtarzania kodu. Powtarzanie kodu jest niewłaściwe, może prowadzić do wielu błędów, może wymagać aktualizacji wielu miejsc w kodzie o czym łatwo zapomnieć. Do tego niepotrzebnie zwiększa rozmiar aplikacji. Wszędzie gdzie to możliwe powinniśmy starać się wykorzystywać stworzony już kod zamiast go kopiować.
Single Responsibility Principle
Kolejna zasada to Single Responsibility Principle (SRP). Zakłada ona że każdy moduł, klasa lub funkcja powinna być odpowiedzialna tylko za jedną funkcjonalność aplikacji. Nie powinna zajmować się wieloma aspektami ale tylko jednym – dzięki temu kod jest łatwiejszy w zrozumieniu i w kolejnych modifikacjach.
Dead code
Nieużywany kod powinien być usuwany. Nie powinien zostawać w aplikacji „bo kiedyś się może przydać”. Lepiej korzystać z Git-a i po prostu jeśli w przyszłości kod miałby być potrzebny to można go przywrócić z historii commitów.
Nazewnictwo zmiennych
Program może działać poprawnie ale użyte nazwy zmiennych mogą wprowadzać w błąd programistę lub być trudne do zrozumienia. Nazwy zmiennych powinny od razu wskazywać co się w nich znajduje.
Komentarze
Program może wymagać wielu komentarzy aby móc go zrozumieć. W tej sytuacji dobrze jest przeanalizować nazwy zmiennych, funkcji i klas aby były bardziej jednoznaczne, tak żeby nie trzeba było do nich dodawać dodatkowych komentarzy.
Podsumowanie
Choć refaktoryzacja kodu może być kosztowna to jeśli naprawdę chcesz realizować projekt przez dłuższy czas lub wprowadzać w nim nowe funkcjonalności to będzie to opłacalna inwestycja. Nie zwlekaj z refaktoryzacją – może to tylko zwiększyć liczbę problemów jak i sam koszt refaktoringu.
Masz inne zdanie? Podziel się nim w komentarzu!