Każdy developer prędzej czy później trafia na projekt, w którym kod przypomina talerz spaghetti. Wszystko jest ze sobą połączone, trudno zrozumieć gdzie zaczyna się jedna logika, a kończy druga, a próba zmiany jednej rzeczy powoduje trzy nowe problemy. Co ciekawe, taki kod rzadko powstaje z premedytacją. Najczęściej jest efektem wielu małych decyzji podejmowanych w pośpiechu. I właśnie dlatego warto wiedzieć, kiedy projekt zaczyna zmierzać w tym kierunku.
Małe poprawki, które nigdy nie są małe
Wiele projektów WordPress zaczyna się od prostego założenia. Strona ma kilka podstron, formularz kontaktowy i blog. Kod jest przejrzysty, struktura motywu czytelna, wszystko ma swoje miejsce. Potem pojawia się pierwsza zmiana. „Dodajmy jeszcze jedną sekcję.” Potem kolejna. „Potrzebujemy dodatkowego pola.” A później jeszcze jedna poprawka, która „powinna zająć tylko chwilę”. Każda z tych zmian jest niewielka. Problem polega na tym, że rzadko towarzyszy im refaktoryzacja istniejącego kodu. W efekcie nowe funkcje są dokładane do starych rozwiązań, zamiast być częścią przemyślanej struktury. Po kilku miesiącach projekt zaczyna przypominać system, który powstawał w różnych momentach i przez różne osoby.
Funkcje, które robią wszystko
Jednym z najczęstszych sygnałów ostrzegawczych jest funkcja, która zaczyna robić zbyt wiele rzeczy. Zamiast jednej odpowiedzialności obsługuje:
- pobieranie danych
- przetwarzanie logiki
- generowanie HTML
- dodatkowe warunki dla różnych przypadków
W kodzie wygląda to mniej więcej tak:
function render_section() {
if ($type == 'hero') {
// kod sekcji hero
} elseif ($type == 'team') {
// kod sekcji zespołu
} elseif ($type == 'contact') {
// kod formularza
}
}Na początku wydaje się to wygodne. Z czasem jednak każda nowa funkcja dokłada kolejne warunki i zależności.
Kopiowanie zamiast struktury
Innym momentem, w którym kod zaczyna się komplikować, jest kopiowanie fragmentów kodu zamiast budowania wspólnych komponentów. To bardzo naturalne zachowanie. Kiedy coś działa, najłatwiej jest skopiować istniejący fragment i zmienić kilka szczegółów. Problem pojawia się wtedy, gdy takich kopii zaczyna być kilkanaście. W pewnym momencie zmiana jednego elementu wymaga modyfikacji wielu plików, a łatwo przeoczyć któryś z nich.
Zbyt wiele warunków
Kod zaczyna przypominać spaghetti także wtedy, gdy pojawia się zbyt wiele zagnieżdżonych warunków.
Na przykład:
if ($user) {
if ($user->is_logged_in) {
if ($user->has_access) {
if ($feature_enabled) {
// właściwa logika
}
}
}
}Im więcej takich zależności, tym trudniej zrozumieć, kiedy dana część kodu faktycznie się wykonuje.
Brak granic między warstwami
W projektach WordPress często zdarza się również mieszanie różnych odpowiedzialności w jednym miejscu. Kod, który powinien odpowiadać za logikę aplikacji, zaczyna generować HTML. Pliki szablonów zaczynają zawierać skomplikowane operacje na danych. Granice między warstwami systemu zaczynają się rozmywać. To moment, w którym kod przestaje być czytelny dla innych developerów – a po jakimś czasie również dla autora.
Jak uniknąć kodu spaghetti
Nie ma jednego sposobu, który całkowicie zapobiega takim sytuacjom. Istnieje jednak kilka praktyk, które znacząco zmniejszają ryzyko. Po pierwsze, warto pilnować zasady jednej odpowiedzialności. Funkcja lub komponent powinien robić jedną rzecz i robić ją dobrze. Po drugie, dobrze jest regularnie refaktoryzować kod. Czas poświęcony na uporządkowanie struktury zwraca się bardzo szybko przy kolejnych zmianach. Po trzecie, warto budować projekt w oparciu o komponenty. Dzięki temu nowe funkcje powstają przez składanie istniejących elementów, a nie przez kopiowanie fragmentów kodu.
Podsumowanie
Kod spaghetti nie pojawia się nagle. Jest efektem wielu drobnych decyzji, które w danym momencie wydają się najszybszym rozwiązaniem. Dlatego najważniejszą umiejętnością developera nie jest tylko pisanie kodu, ale także rozpoznawanie momentu, w którym projekt zaczyna wymykać się spod kontroli. Czasem najlepszą decyzją jest zatrzymanie się na chwilę i uporządkowanie tego, co już powstało. W dłuższej perspektywie to właśnie takie momenty decydują o jakości projektu.