Modernizacja czy przepisanie systemu od nowa – jak podjąć decyzję?

Netscape, Borland, wiele projektów rządowych na całym świecie – lista firm, które zdecydowały się przepisać działający system od zera i tego pożałowały, jest długa. Joel Spolsky nazwał to kiedyś „najgorszą możliwą decyzją w oprogramowaniu". Mimo to pokusa jest zawsze silna.

Dlaczego? Bo stary kod jest nieznany i przez to przerażający. Nowy – wydaje się prosty i czysty, bo jeszcze nie zderzył się z realiami biznesowymi.

Dlaczego „piszemy od nowa" jest tak kuszące?

Kiedy programista patrzy na stary kod, widzi problemy: złe nazewnictwo, brak testów, skomplikowane zależności, przestarzałe biblioteki, brak dokumentacji. Naturalną reakcją jest chęć zaczęcia od czystej kartki.

Problem w tym, że ten „brzydki" kod zawiera coś bezcennego: lata rozwiązanych problemów biznesowych. Każda dziwna instrukcja if, każdy niezrozumiały warunek – to często efekt napotkanego kiedyś edge case'a, który kosztował klienta kilka godzin straconej pracy. Przepisując, tracisz tę wiedzę.

Stary, „brzydki" kod często rozwiązuje problemy, o których istnieniu nie wiesz – dopóki ich nie przywrócisz pisząc od nowa.

Kiedy modernizacja jest lepszą opcją?

Modernizacja – czyli stopniowe ulepszanie istniejącego systemu – sprawdza się w zdecydowanej większości przypadków. Szczególnie, gdy:

• System działa i jest używany produkcyjnie. Przerwanie ciągłości działania to realne koszty biznesowe. Modernizacja pozwala wprowadzać zmiany bez przestojów.
• Logika biznesowa jest skomplikowana. Im bardziej złożone są reguły działania systemu, tym większe ryzyko, że przy przepisywaniu coś zostanie pominięte lub zrozumiane źle.
• Dokumentacja jest słaba lub brakuje jej całkowicie. Bez wiedzy o tym, co system powinien robić, przepisanie to podróż w nieznane.
• Masz ograniczony budżet i czas. Modernizacja jest tańsza i szybsza – pierwsze efekty widać po tygodniach, nie miesiącach.
• Problemy są konkretne i lokalne. Wolna baza danych, przestarzałe biblioteki, nieczytelny interfejs – to można naprawiać selektywnie.

Kiedy przepisanie od nowa ma sens?

Są sytuacje, gdzie przepisanie jest uzasadnione. Nie jest ich wiele, ale są:

• Technologia jest martwa lub niemożliwa do utrzymania. System napisany w technologii, której już nikt nie zna i nie można zatrudnić programisty – to realny problem. Ale nawet wtedy można migrować stopniowo.
• Architektura jest fundamentalnie zepsuta. Jeśli system nie można skalować, testować ani modyfikować bez ryzyka posypania wszystkiego – i jest to problemem nie do obejścia inkrementalnie.
• Model biznesowy zmienił się radykalnie. Stary system rozwiązuje inny problem niż ten, który firma ma dziś. Modernizowanie go to mozolne dostosowywanie czegoś, co nigdy nie będzie pasować.
• System jest mały. Im mniejszy system, tym mniejsze ryzyko przepisania. Aplikacja z 2000 linii kodu i trzema funkcjami to inny przypadek niż system ERP obsługujący cały łańcuch dostaw.

Jak podejmujemy tę decyzję? Nasze kryteria

Kiedy klient przychodzi z pytaniem „modernizować czy przepisać", zaczynamy od kilku pytań diagnostycznych:

1. Czy system działa poprawnie pod kątem biznesowym?

Jeśli tak – to ogromny argument za modernizacją. Logika biznesowa jest prawidłowa, tylko implementacja wymaga pracy. Dużo łatwiej poprawić implementację niż zrozumieć i odtworzyć logikę od zera.

2. Ile kodu jest „naprawdę złego"?

Często to, co na pierwszy rzut oka wygląda jak katastrofa, po głębszej analizie okazuje się zestawem konkretnych problemów w kilku kluczowych miejscach. Reszta kodu jest zwykła, nudna i działa.

3. Jak długo zajmie przepisanie?

Przepisywanie systemów zawsze trwa dłużej niż szacunki – zwykle 2-3x dłużej. Jeśli szacunek to 6 miesięcy, planuj 12-18. W tym czasie stary system musi być utrzymywany, a firma żyje z opóźnionym nowym systemem.

4. Czy możemy robić to stopniowo?

Często tak. Nawet poważna przebudowa systemu może być podzielona na moduły i robiona inkrementalnie – przy zachowaniu ciągłości działania produkcji. To tzw. strangler fig pattern – nowy system „obudowuje" stary, przejmując funkcje jedna po drugiej.

Wzorzec, który nam się sprawdza: modernizacja ewolucyjna

W praktyce rzadko stajemy przed wyborem zero-jedynkowym. Najczęściej robimy coś pomiędzy: zostawiamy działające jądro systemu i stopniowo wymieniamy lub modernizujemy poszczególne komponenty.

Przykładowe podejście:

1. Audyt – identyfikacja najgorzej działających i najbardziej problematycznych elementów
2. Priorytetyzacja – które problemy generują największy ból biznesowy?
3. Modernizacja iteracyjna – zaczynamy od jednego modułu lub jednej warstwy
4. Weryfikacja – każda zmiana jest testowana zanim trafi na produkcję
5. Powtórzenie – przechodzimy do następnego elementu

System przez cały czas działa. Zmiana jest kontrolowana. Ryzyko jest minimalne.

Czerwone flagi: kiedy ktoś proponuje Ci przepisanie od zera

Uważaj, gdy słyszysz następujące argumenty za przepisaniem:

• „Ten kod jest tak zły, że szybciej będzie napisać od nowa niż to naprawiać" – zwykle nieprawda
• „Nowa technologia X wszystko rozwiąże" – nowa technologia przynosi nowe problemy
• „W 3 miesiące zrobimy to samo, tylko lepiej" – niemal nigdy tak nie wychodzi
• „Stary system to już nie do utrzymania" – to często opinia, nie fakt; warto ją zweryfikować

Wnioski

Modernizacja jest prawie zawsze lepszą opcją niż przepisanie od zera – szczególnie dla systemów produkcyjnych z historią i złożoną logiką biznesową.

Przepisanie ma sens w wąskich, konkretnych przypadkach: martwa technologia, fundamentalnie zepsuta architektura, mały system, radykalna zmiana modelu biznesowego.

W każdym przypadku decyzja powinna być poprzedzona rzetelnym audytem – nie intuicją programisty, który właśnie spędził tydzień na walce ze starym kodem.