Entropia kodu - kiedy naprawiać, a kiedy przepisać od nowa?

Wprowadzenie: Uniwersalne prawo chaosu

Jest takie prawo fizyki, które dotyczy wszystkiego - od galaktyk, przez żywe organizmy, aż po twój kod. To drugie prawo termodynamiki:

W izolowanym układzie entropia (miara nieporządku) zawsze rośnie lub pozostaje stała - nigdy nie maleje samoistnie.

Innymi słowy: chaos jest naturalny, porządek wymaga energii.

Twój kod podlega tym samym prawom co reszta wszechświata. I nie da się tego oszukać.

Czym jest entropia? Lekcja z fizyki

Definicja dla programistów

Entropia to miara nieporządku w systemie. Im więcej możliwych stanów, w których może znajdować się system, tym wyższa entropia.

Przykład z życia:

• Nowy pokój po sprzątaniu → niska entropia (wszystko na swoim miejscu)
• Ten sam pokój po miesiącu → wysoka entropia (chaos)

Czy pokój sam się posprząta? Nigdy. Potrzebujesz energii (twojej pracy), żeby przywrócić porządek.

Entropia w chemii

W chemii entropia wyjaśnia dlaczego:

• Lód topnieje w ciepłym pomieszczeniu (cząsteczki wody przechodzą z uporządkowanej struktury krystalicznej do chaotycznego ruchu)
• Perfumy rozchodzą się po pokoju (cząsteczki dążą do równomiernego rozmieszczenia)
• Rdza zjada metal (żelazo + tlen → tlenek żelaza - bardziej chaotyczna struktura)

Wszystkie te procesy są nieodwracalne bez dostarczenia energii z zewnątrz.

Entropia we wszechświecie

Na skalę kosmiczną:

• Gwiazdy wypalają się
• Galaktyki się rozpraszają
• Wszechświat dąży do "śmierci cieplnej" - stanu maksymalnej entropii

Stephen Hawking ujął to tak:

"Entropia jest strzałką czasu - wskazuje kierunek, w którym czas płynie."

Entropia w kodzie - ta sama historia

Jak kod zwiększa entropię?

Każdy system software'owy zaczyna jako uporządkowany - czysta architektura, jasne granice, spójna konwencja.

A potem przychodzi rzeczywistość:

Miesiąc 1-6: Honeymoon

- Czysta architektura
- Dokumentacja aktualna
- Testy pokrywają 80%
- Wszyscy rozumieją kod
- Entropia: NISKA ✅

Miesiąc 6-18: Kompromisy

- "Szybki fix" który zostaje na zawsze
- "Tymczasowe" rozwiązanie
- Nowy developer dodaje kod "po swojemu"
- Dokumentacja przestaje być aktualna
- Entropia: ROSNĄCA ⚠️

Rok 2-5: Legacy

- Nikt nie wie dlaczego ten kod istnieje
- "Nie dotykaj tego, bo się posypie"
- Każda zmiana to 3 nowe bugi
- Onboarding nowego developera: 2 miesiące
- Entropia: WYSOKA 🔴

Rok 5+: Ruina

- Kod działa, ale nikt nie wie jak
- Framework przestał być wspierany
- Brak ludzi którzy znają technologię
- Koszt każdej zmiany: astronomiczny
- Entropia: MAKSYMALNA 💀

Matematyka entropii kodu

Jeśli chcesz to ująć liczbowo:

Entropia_kodu = f(
  wiek_systemu,
  liczba_developerów_którzy_go_dotykali,
  liczba_hotfixów,
  tempo_zmian_wymagań,
  brak_refaktoryzacji,
  zmiana_technologii_w_ekosystemie
)

Każdy z tych czynników TYLKO ZWIĘKSZA entropię.

Żaden z nich jej nie zmniejsza samoistnie.

Dlaczego refaktoryzacja to walka z entropią?

Refaktoryzacja to dostarczanie energii do systemu, żeby zmniejszyć jego entropię.

Ale uwaga - to jak sprzątanie pokoju w domu który się rozpada:

| Sytuacja | Refaktoryzacja pomoże? | |----------|------------------------| | Niespójne nazewnictwo | ✅ Tak | | Duplikacja kodu | ✅ Tak | | Brak testów | ✅ Tak | | Przestarzały framework | ⚠️ Częściowo | | Błędna architektura | ❌ Raczej nie | | Fundamentalnie zła technologia | ❌ Nie |

Prawo malejących zwrotów

Im wyższa entropia systemu, tym więcej energii potrzebujesz żeby ją obniżyć:

Koszt_refaktoryzacji = entropia² × rozmiar_systemu

W pewnym momencie koszt utrzymania porządku przekracza koszt budowy od nowa.

Sygnały że entropia wygrała

🚨 Czerwone flagi

1. "Nie wiem dlaczego to działa, ale działa"

   • Jeśli nikt w zespole nie rozumie krytycznej części systemu

2. Czas na prostą zmianę: dni zamiast godzin

   • Dodanie nowego pola do formularza nie powinno zajmować tygodnia

3. Każda zmiana generuje regresje

   • Naprawiasz jedno, psujesz trzy inne rzeczy

4. Framework/język nie jest już wspierany

   • AngularJS, Python 2, jQuery jako fundament aplikacji w 2026?

5. Nie możesz zatrudnić developerów

   • "Szukamy eksperta od ColdFusion i ExtJS" - powodzenia

6. Koszt utrzymania > koszt rozwoju

   • 80% czasu idzie na gaszenie pożarów

7. Strach przed deploymentem

   • Piątek po 14:00 = freeze

Mój test: "Czy zatrudniłbym siebie?"

Zadaj sobie pytanie:

Gdybym był nowym developerem, czy chciałbym pracować z tym kodem?

Jeśli odpowiedź brzmi "nie" - masz problem z entropią.

Kiedy przepisać od nowa?

Argumenty ZA przepisaniem

✅ Fundamentalna zmiana wymagań

• System e-commerce → platforma SaaS
• Aplikacja desktopowa → mobile-first

✅ Technologia jest martwa

• Brak aktualizacji bezpieczeństwa
• Brak społeczności i wsparcia
• Brak nowych developerów na rynku

✅ Architektura nie skaluje się

• Monolith który powinien być mikroserwisami (lub odwrotnie!)
• Baza danych która nie udźwignie wzrostu

✅ Koszt utrzymania > koszt przepisania

• Policz ile kosztuje rok utrzymania vs rok przepisania + 5 lat utrzymania nowego systemu

✅ Dług techniczny jest niespłacalny

• Jak kredyt hipoteczny z 40% oprocentowaniem - lepiej zbankrutować i zacząć od nowa

Argumenty PRZECIW przepisaniu

❌ "Nowy będzie lepszy" (syndrom zielonej trawy)

• Nowy system też zbierze entropię - wolniej, ale zbierze

❌ Niedocenianie złożoności

• "To tylko CRUD, przepiszemy w 3 miesiące" → 18 miesięcy później...

❌ Utrata wiedzy domenowej

• Stary kod zawiera lata edge case'ów których nie ma w dokumentacji

❌ Ryzyko biznesowe

• Przepisywanie = brak nowych feature'ów przez X miesięcy

❌ Joel Spolsky's warning:

"Przepisywanie od nowa to najgorsza strategiczna decyzja jaką firma software'owa może podjąć."

Moja zasada: Strangler Fig Pattern

Zamiast "big bang" przepisywania, używam wzorca Strangler Fig (od drzewa figowego które obrasta i "dusi" inne drzewo):

1. Zidentyfikuj najbardziej problematyczny moduł
2. Napisz nową wersję obok starej
3. Przekieruj ruch do nowej wersji
4. Usuń stary kod
5. Powtórz dla kolejnego modułu

Zalety:

• Mniejsze ryzyko
• Ciągłe dostarczanie wartości
• Możliwość wycofania się
• Stopniowe uczenie się nowej architektury

Case study: Moje doświadczenie z entropią

Projekt A: Przepisaliśmy - i mieliśmy rację

Sytuacja:

• Aplikacja PHP 5.6 + jQuery (napisana w 2014)
• Framework: własny (tak, ktoś napisał własny framework PHP)
• Brak testów
• 3 osoby które znały kod - wszystkie odeszły
• Czas dodania prostego feature'a: 2 tygodnie

Decyzja: Przepisać w Next.js + TypeScript

Wynik po 18 miesiącach:

• Czas dodania feature'a: 2 dni
• Zespół: 4 osoby (łatwo rekrutować)
• Zadowolenie klienta: znacznie wyższe
• ROI przepisania: dodatni po 14 miesiącach

Projekt B: Refaktorowaliśmy - i mieliśmy rację

Sytuacja:

• Aplikacja React (napisana w 2020)
• Architektura OK, ale niespójny kod
• Testy: 30% pokrycia
• Zespół rotował, każdy pisał "po swojemu"

Decyzja: Głęboka refaktoryzacja zamiast przepisywania

Działania:

• Wprowadzenie ścisłego TypeScript
• Ujednolicenie wzorców (custom hooks, komponenty)
• Zwiększenie pokrycia testami do 70%
• Code review z checklist

Wynik:

• Koszt: 3 miesiące pracy
• Efekt: system "odżył" na kolejne 3+ lata

Projekt C: Przepisaliśmy - i to był błąd

Sytuacja:

• "Legacy" Java aplikacja (działająca od 8 lat)
• Kod brzydki, ale stabilny
• Zespół znał każdy edge case

Decyzja: Przepisać w Node.js ("bo Java jest przestarzała")

Wynik:

• 12 miesięcy przepisywania
• Nowy system miał 60% funkcjonalności starego
• Odkryliśmy dziesiątki edge case'ów "po drodze"
• Klient stracił cierpliwość
• Wróciliśmy do starego systemu + inkrementalne modernizacje

Lekcja: Działający "brzydki" kod > niedziałający "ładny" kod

Praktyczne wskazówki

Jak mierzyć entropię kodu?

Metryki automatyczne:

• Cyclomatic complexity - im wyższa, tym gorzej
• Code churn - jak często zmieniają się te same pliki
• Bug density - bugi per 1000 linii kodu
• Test coverage - mniej testów = więcej niepewności
• Dependency freshness - jak stare są biblioteki

Metryki ludzkie:

• Czas onboardingu nowego developera
• "Bus factor" - ile osób może odejść zanim projekt umrze
• Ankieta: "Czy lubisz pracować z tym kodem?" (1-10)

Jak spowalniać wzrost entropii?

1. Code review - zawsze

   • Żaden kod nie wchodzi bez przeglądu

2. Testy - naprawdę

   • Nie "napiszemy później", tylko teraz

3. Dokumentacja decyzji (ADR)

   • Architecture Decision Records - dlaczego wybraliśmy X a nie Y

4. Regularna refaktoryzacja

   • 20% czasu na "sprzątanie" - nie negocjowalne

5. Aktualizacja zależności

   • Raz na kwartał - nie odkładaj na "kiedyś"

6. Rotacja wiedzy

   • Każdy moduł zna minimum 2 osoby

Kiedy podjąć decyzję o przepisaniu?

Framework decyzyjny:

JEŚLI:
  (technologia_martwa LUB architektura_fundamentalnie_zła)
  ORAZ (koszt_przepisania < 2 × roczny_koszt_utrzymania)
  ORAZ (masz_czas_i_budżet)
WTEDY:
  Rozważ przepisanie (strangler fig pattern)
W PRZECIWNYM RAZIE:
  Refaktoruj inkrementalnie

Filozoficzne zakończenie

Entropia jest nieunikniona. Twój kod, twoja firma, twoje ciało, wszechświat - wszystko zmierza ku chaosowi.

Ale to nie znaczy, że masz się poddać.

Entropia to nie wróg - to naturalna siła, którą trzeba zrozumieć i z którą trzeba pracować:

1. Akceptuj że chaos przyjdzie
2. Mierz poziom entropii
3. Inwestuj w utrzymanie porządku (regularnie, nie "kiedyś")
4. Rozpoznaj kiedy walka nie ma sensu
5. Przepisz gdy to jedyne racjonalne wyjście

Ostatnia myśl

Fizyka mówi nam, że porządek wymaga energii. W software to oznacza:

Czas i pieniądze na utrzymanie jakości kodu to nie "koszt" - to inwestycja w spowolnienie entropii.

Firmy które tego nie rozumieją, płacą później 10x więcej.

---

Potrzebujesz oceny entropii swojego systemu?

Jeśli zastanawiasz się:

• Czy nasz kod jest jeszcze do uratowania?
• Przepisać czy refaktorować?
• Jak zaplanować modernizację bez zatrzymywania biznesu?

Skontaktuj się ze mną - pomogę obiektywnie ocenić sytuację i zaplanować strategię.

Oferuję:

• 🔍 Audyt entropii kodu - metryki + analiza jakościowa
• 📋 Strategia modernizacji - roadmapa krok po kroku
• 🏗️ Wsparcie przy przepisywaniu - architektura, nadzór, code review

---

"Entropia wszechświata dąży do maksimum. Entropia twojego kodu też - chyba że coś z tym zrobisz."