Co to jest kod makaronowy

Kod makaronowy (spaghetti code) — to metafora opisująca kod, którego struktura przypomina talerz spaghetti: poszczególne nitki (bloki logiczne) są poplątane, sklejone i nieodłączone od siebie. W takim kodzie nie można wydzielić warstw, modułów ani komponentów — wszystko jest wymieszane w jednej wielkiej masie.

W przeciwieństwie do bad code, który może być po prostu niechlujny, kod makaronowy to fundamentalny problem architektoniczny. Nawet idealnie sformatowany kod z dobrymi nazwami zmiennych może być spaghetti, jeśli jego architektura jest chaotyczna. Problem leży na poziomie struktury programu, a nie stylu pisania.

Według danych IEEE (2022), około 35% wszystkich błędów w dużych projektach wynika właśnie ze splątanej struktury kodu, a nie z błędów logicznych programisty. Programista popełnia błąd nie dlatego, że źle zrozumiał zadanie, ale dlatego, że nie mógł prześledzić przepływu wykonania w spaghetti code.

Kluczowa różnica od innych antywzorców

Jeśli bad code to zły kod w skali jednej funkcji lub pliku, to kod makaronowy to zła architektura w skali całej aplikacji. Spaghetti może składać się z pojedynczych dobrze napisanych funkcji, ale ich interakcja jest chaotyczna i nieprzewidywalna.

Historia terminu i era goto

Termin „spaghetti code” pojawił się w latach 70. XX wieku wraz z krytyką operatora goto. We wczesnych językach programowania (BASIC, FORTRAN, COBOL) goto był podstawowym sposobem sterowania przepływem wykonania. Program stanowił sekwencję ponumerowanych linii, a goto pozwalał przejść do dowolnej z nich. Tworzyło to „plątaninę” skoków, której nie dało się rozplątać.

W 1968 roku Edsger Dijkstra opublikował słynny list „Go To Statement Considered Harmful”, który zapoczątkował erę programowania strukturalnego. Dijkstra udowodnił, że każdy algorytm można zaimplementować bez goto, używając tylko trzech konstrukcji: sekwencji, rozgałęzienia (if) i pętli (while). Stało się to fundamentem nowoczesnego programowania.

Programowanie strukturalne nie wyeliminowało problemu całkowicie. Kod makaronowy przeszedł na nowy poziom — zamiast fizycznych goto programiści zaczęli tworzyć logiczne „goto”: zmienne globalne, callback hell w JavaScript, złożone łańcuchy wywołań i niejawne zależności między komponentami. Problem pozostał, zmieniła się tylko forma.

Współczesne formy goto

Callback hell w JavaScript, głęboko zagnieżdżone Promise, async/await bez obsługi błędów, zdarzenia, które nie wiadomo kto i kiedy inicjuje — wszystko to współczesne odmiany kodu spaghetti. Antywzorzec żyje i ma się dobrze, tylko teraz nie używa operatora goto.

Oznaki kodu spaghetti w projekcie

Brak warstw — pierwszy i główny objaw. W kodzie makaronowym logika biznesowa, praca z bazą danych, szablon HTML i komunikacja sieciowa są wymieszane w jednym pliku, a nawet w jednej metodzie. Zmiana zapytania do bazy danych może zepsuć wyświetlanie interfejsu, ponieważ kod tych warstw nie jest rozdzielony.

Zmienne globalne i singletony — drugi wyraźny objaw. Gdy stan aplikacji jest przechowywany w globalnych obiektach, przepływ wykonania staje się nieprzewidywalny. Dowolna funkcja może zmienić stan globalny, a prześledzenie gdzie i kiedy to nastąpiło jest praktycznie niemożliwe.

God-classes i god-funkcje — trzeci objaw. Klasa na 2000+ linii, która odpowiada i za logikę biznesową, i za wyświetlanie, i za pracę z danymi — to typowy kod spaghetti. Funkcja, która przyjmuje 10 parametrów i robi 5 różnych rzeczy — też.

Diagnostyka przez testy

Jeśli nie możesz napisać testu jednostkowego dla funkcji bez tworzenia 15 obiektów mock — to kod makaronowy. Jeśli testowanie jednego modułu wymaga uruchomienia całej infrastruktury aplikacji — to kod makaronowy. Niemożliwość testowania to obiektywny wskaźnik splątanej architektury.

Dlaczego powstaje spaghetti w kodzie

Brak projektowania architektonicznego — najczęstsza przyczyna. Gdy zespół zaczyna pisać kod bez planu, wybierając architekturę „na bieżąco”, wynik nieuchronnie zamienia się w spaghetti. Każda nowa funkcja jest dodawana tam, gdzie „jest teraz wygodnie”, a nie tam, gdzie jej miejsce według logiki.

Rozwój ewolucyjny — druga przyczyna. Projekt zaczyna się jako mały skrypt, potem obrasta funkcjami, potem staje się aplikacją, a następnie — monolit. Przy tym architektura nie jest weryfikowana. To, co działało dla 100 linii kodu, staje się katastrofą dla 100 000 linii.

Naruszenie zasad SOLID — trzecia przyczyna. Szczególnie zasady jednej odpowiedzialności (S) i inwersji zależności (D). Gdy klasa odpowiada za wszystko, zależności są sztywne, a moduły połączone na stałe — powstaje kod makaronowy.

Czynnik czasu

Terminy i kultura hotfix — katalizatory kodu spaghetti. Gdy „potrzebne było wczoraj”, programiści wstawiają kod w pierwsze lepsze miejsce, nie myśląc o architekturze. Dziesięć takich hotfixów — i architektura aplikacji jest zniszczona.

Konsekwencje kodu makaronowego

Główna konsekwencja — utrata kontroli nad bazą kodu. Programiści przestają rozumieć, jak działa aplikacja jako całość. Zmiana w jednym miejscu psuje inne, pozornie niepowiązane. Każdy łat tworzy dwa nowe bugi. Zespół wchodzi w stan „strachu przed zmianami”.

Wydajność zespołu spada wykładniczo. Badanie Microsoft Research (2023) wykazało, że czas dodania nowej funkcji w kodzie spaghetti rośnie zgodnie z prawem kwadratowym względem rozmiaru bazy kodu. Dla czystej architektury wzrost ten jest liniowy. Różnica staje się krytyczna przy 50 000+ linii kodu.

Bezpieczeństwo — kolejna ofiara. W kodzie makaronowym łatwo przeoczyć nieobsłużony wyjątek, nieprawidłową walidację wejścia lub wyciek danych. Audyt bezpieczeństwa w projekcie ze splątaną architekturą jest praktycznie niemożliwy — znalezienie wszystkich miejsc, w których używane są dane wejściowe użytkownika, jest nierealne.

Wpływ na zespół

Rotacja w projektach z kodem spaghetti jest wyższa niż przeciętna. Doświadczeni programiści odchodzą, ponieważ nie chcą pracować ze „spaghetti”. Nowi pracownicy nie mogą zrozumieć kodu i odchodzą w pierwszych miesiącach. Projekt traci wiedzę ekspercką, co jeszcze bardziej pogarsza jakość kodu — błędne koło.

Jak refaktorować kod makaronowy

Pierwsze — zacznij od wydzielenia warstw. Podziel kod na trzy poziomy: presentation (UI, kontrolery), business logic (serwisy, use cases) i data access (repozytoria, DAO). Nawet częściowe rozdzielenie od razu poprawia strukturę i czyni kod testowalnym.

Drugie — wdróż dependency injection. Zastąp bezpośrednie tworzenie zależności przekazywaniem przez konstruktor lub parametry. To zrywa sztywne powiązania między komponentami i pozwala testować każdy moduł w izolacji.

Trzecie — wydziel god-classes i god-funkcje. Podziel je na małe klasy i metody z pojedynczą odpowiedzialnością. Użyj wzorca Facade do uproszczenia złożonych podsystemów. Pamiętaj: klasa na 20 linii jest bardziej zrozumiała niż klasa na 2000 linii.

// spaghetti — wszystko w jednej metodzie
function handleRequest(req, res) {
  const db = new Database("mysql://...");
  const user = db.query("SELECT * FROM users WHERE id =" + req.params.id);
  let html = "";
  html += "
" + user.name + "
";
  html += "
Balance: " + user.balance + "
";
  html += "";
  res.send(html);
}

// czysta architektura — rozdzielone warstwy
class UserController {
  constructor(userService) {
    this.userService = userService;
  }

  async getUser(req, res) {
    const user = await this.userService.findById(req.params.id);
    res.json(new UserResponse(user));
  }
}

class UserService {
  constructor(userRepository) {
    this.userRepository = userRepository;
  }

  async findById(id) {
    return await this.userRepository.findById(id);
  }
}

Strategia refaktoringu: metoda chirurgii

Nie próbuj przepisać całej bazy kodu na raz — to gwarantowana porażka. Wybierz jeden moduł, napisz dla niego testy (characterization tests), które utrwalają obecne zachowanie, i dopiero wtedy refaktoruj. Stopniowo, moduł po module, rozplączesz spaghetti.

Profilaktyka powstawania spaghetti

Planowanie architektoniczne — podstawa profilaktyki. Przed rozpoczęciem rozwoju zatwierdź styl architektoniczny: MVC, MVVM, Clean Architecture, VIPER lub inny. Napisz ADR (Architecture Decision Record) z uzasadnieniem wyboru. Wymagaj przestrzegania architektury na code review.

Zasada inwersji zależności (DIP) — potężne narzędzie walki z kodem spaghetti. Moduły wysokiego poziomu nie powinny zależeć od modułów niskiego poziomu. Oba powinny zależeć od abstrakcji. Dependency Injection — praktyczna realizacja tej zasady.

Testowanie — najlepsza profilaktyka. Jeśli piszesz testy przed kodem (TDD), nieuchronnie projektujesz słabo powiązane komponenty. Testowalny kod to dobrze ustrukturyzowany kod. Nietestowalny kod to prawie zawsze kod spaghetti.

• Architektura przed kodem: zatwierdź schematy warstw i zależności
• Dependency Injection jako główny wzorzec wiązania
• TDD lub przynajmniej wysokie pokrycie testami
• Code review z kontrolą architektury, a nie tylko stylu
• Regularny refaktoring jako część procesu rozwoju

Narzędzia do walki z kodem spaghetti

SonarQube — śledzi złożoność cyklomatyczną, głębokość dziedziczenia, rozmiar metod. JDepend (Java) — mierzy zależności między pakietami. PhpMetrics — dostarcza wskaźnik maintainability dla projektów PHP. Śledź metryki w CI/CD — zapobiegaj pojawianiu się spaghetti, a nie walcz z nim post factum.