W 2011 roku dużo czytałem na temat pracy ze starszym kodem, jakości kodu i refaktoryzacji.
Jest cytat Martina Fowlera (który dosłownie napisał książkę o refaktoryzacji) przypisywany wujkowi Bobowi, który utkwił mi w pamięci – i jestem pewien, że wielu, wielu programistów – od tego czasu:
zawsze zostawiaj kod w lepszym stanie niż go znalazłeś
Rzecz w tym konkretnym pomyśle jest taka, że myślę, że może brzmieć nieco bardziej idealistycznie, dopóki naprawdę nie zaczniesz go praktykować we wszystkim, co robisz.
Oznacza to, że jeśli weźmiesz to za dobrą monetę, brzmi to tak, jakby za każdym razem, gdy musisz pracować nad bazą kodu, musisz zostawić całą bazę kodu lepiej niż wtedy, gdy ją znalazłeś. Ale im bardziej staram się stosować tę zasadę w mojej codziennej pracy, tym bardziej praktyczny, czystszy i łatwiejszy w utrzymaniu staje się kod specyficzny dla WordPressa.
Więc jeśli chodzi o refaktoryzację kodu opartego na WordPressie, jak to wygląda?
To nie będzie długi post. Zamiast tego zamierzam po prostu podzielić się kilkoma punktami, którymi się kieruję, jeśli chodzi o pracę nad kodem, który napisałem wcześniej, z którym spotykam się od innych lub który pochodzi z bazy kodu, nad którą pracowałem z innymi w po.
W dowolnej kolejności:
- Nie bądź idealistą; Bądź praktyczny. Refaktoryzacja całej bazy kodu nie jest praktyką, zwłaszcza jeśli baza kodu nie jest opakowana w testy jednostkowe. Spójrz na kod, nad którym pracujesz, i zobacz, jakie drobne modyfikacje możesz wprowadzić, aby go ulepszyć.
- Korzystaj z najnowszych standardów. Nie musisz konfigurować zupełnie nowego środowiska programistycznego dla starszego kodu. Zamiast tego upewnij się, że masz dobre sniffery kodu. Jeśli przeszedłeś ze Standardów Kodowania WordPressa na PSR, spójrz na ostrzeżenia lub uwagi, że sniffery rzucają i próbują aktualizować kod tylko w tym pliku (lub zestawie plików).
- Napisz funkcje pomocnicze. Jeśli Twoje funkcje są zbyt długie, poszukaj sposobów na ułatwienie ich pracy. Najpierw zaktualizuj dowolne struktury kontrolne, takie jak pętle lub instrukcje warunkowe, a następnie napisz funkcje pomocnicze, aby były łatwiejsze do odczytania.
- Dodaj testy (jeśli to możliwe). Jeśli masz już wdrożoną platformę testów jednostkowych, dodaj testy dla nowego kodu. Jeśli nie masz czasu lub ram, nie przejmuj się. O ile pragmatyczni programiści to głoszą, nie zawsze jest czas na dodawanie testów. (Nie chodzi o stwierdzenie, że nie są one przydatne lub nie powinny być uwzględniane, ale nie zawsze jest praktyczne włączenie ich w dowolnym momencie).
Niektóre z rzeczy, które robiłem w ostatnich projektach, obejmują również proste rzeczy:
- aktualizacja nazw zmiennych i funkcji zgodnie z PSR,
- zamiana tabulatorów na spacje,
- dodanie funkcji pomocniczych, aby warunki i pętle były bardziej czytelne,
- podział klas na wyższy stopień spójności,
- poprawić docblocki każdej funkcji
To tylko niektóre przykłady i wyraźnie nie jest to wyczerpująca lista. Ale nie o to chodzi. Zamiast tego chcę po prostu podzielić się, w jaki sposób można zastosować refaktoryzację kodu opartego na WordPressie, jednocześnie wykonując codzienną pracę w łatwy sposób.
Wszystkie powyższe zmiany lub zalecenia to rzeczy, które zwykle można zrobić z pomocą IDE, kilkoma skrótami i może z pół godziny dodatkowego czasu (i jestem liberalny z tymi szacunkami).
Więc nie, nie musisz przepisywać całej bazy kodu. Nie wiem nawet, czy jest to praktyczny cel, do którego należy dążyć. Ale możesz naprawić jeden mały element całego systemu, za który jesteś odpowiedzialny?
A dlaczego przynajmniej nie dążyć do tego?