Przepisanie systemu od zera kusi - świeży kod, żadnego "nie ruszać, nikt nie wie czemu to działa. A jak sie zepsuje to na amen". Rzeczywistość jest niestety brutalniejsza: większość pełnych rewrite'ów kończy się porażką, drastycznym przekroczeniem budżetu albo porzuceniem projektu w połowie.
Problem nie w tym, że przepisanie od zera to zły pomysł. Problem w tym, że firmy sięgają po nie z niewłaściwego powodu - bo stary system irytuje, a nie dlatego, że rzeczywiście przestał się nadawać do dalszego łatania. Poniżej sześć kryteriów, które pomogą Ci odróżnić jedno od drugiego.
Zanim przejdziemy do kryteriów - trzy liczby z tegorocznych badań
1. Koszt utrzymania rośnie szybciej niż wartość, którą system dostarcza
Jeśli w tym roku wydajesz na łatanie systemu więcej niż w zeszłym, a system nie robi nic więcej niż rok temu - to nie jest przypadek, to trend. Dług technologiczny nie rośnie liniowo. Każda kolejna łatka nałożona na starą łatkę zwiększa koszt następnej zmiany, nawet jeśli sama zmiana jest drobna.
2. Nikt już nie potrafi bezpiecznie ruszyć kodu
Klasyczny sygnał: jedna osoba w firmie (albo u dostawcy) wie, jak działa ta konkretna część systemu, i wszystkie zmiany czekają w kolejce, aż będzie miała czas. Jeśli ta osoba odejdzie, zmiana staje się archeologią, nie programowaniem. To ryzyko biznesowe, nie tylko techniczne.
3. System stoi na technologii, której nikt już nie wspiera
Framework bez aktualizacji bezpieczeństwa od lat, serwer na systemie operacyjnym, który producent przestał wspierać, biblioteka, której autor porzucił projekt. Każda z tych rzeczy osobno to ryzyko. Razem to system, który jest jedną poważną podatnością od realnego problemu - a nikt nie wyda już do niego łatki.
4. Architektura fizycznie nie wytrzymuje wzrostu
Są rzeczy, których nie da się załatać - baza zaprojektowana pod 500 użytkowników nie obsłuży 50 tysięcy bez przebudowy fundamentów. Wzrost firmy i spadek wydajności systemu idą tu w parze, a żadna optymalizacja tego nie rozdzieli.
5. System nie potrafi połączyć się z niczym nowym
Brak API, format danych sprzed dekady, integracje robione ręcznie przez eksport do Excela i import gdzie indziej. Jeśli każde nowe narzędzie, które firma chce wdrożyć, wymaga obejścia zamiast integracji, system zaczyna hamować rozwój firmy, nie go wspierać.
6. Tempo dodawania nowych funkcji spada z każdym miesiącem
To, co rok temu zajmowało tydzień, dziś zajmuje miesiąc - a zakres zmiany jest podobny. Spadające tempo to najbardziej wiarygodny sygnał, bo nie da się go zracjonalizować jednym złym sprintem. Jeśli trend utrzymuje się przez kwartał czy dłużej, kod sam sygnalizuje, że kolejne łatki dokładają więcej komplikacji niż wartości.
Szybki podgląd: łatać czy przepisywać
Łataj
Rdzeń procesu wciąż działa
Problem jest techniczny, nie biznesowy - a system musi działać nieprzerwanie podczas zmian.
Przepisz
Logika już nie pasuje do firmy
Platforma jest bez wsparcia i bez ścieżki migracji, a koszt status quo przewyższa koszt przebudowy.
Trzecia droga
Najbezpieczniejsza droga pośrednia to modernizacja etapami zamiast jednorazowego “skoku na głęboką wodę” - wymiana systemu moduł po module, przy zachowaniu działania starego kodu w tle, aż nowy przejmie funkcję. Ten wzorzec (znany jako strangler fig) osiąga wyraźnie wyższą skuteczność niż pełny rewrite, właśnie dlatego że nie stawia całej firmy na jedną kartę na osiemnaście miesięcy.