Przez lata pracy z oprogramowaniem zauważyłem, że prawa rządzące budownictwem i programowaniem są zaskakująco podobne. Stary dom i stary system informatyczny starzeją się niemal w ten sam sposób. Najpierw pojawiają się drobne poprawki, potem prowizoryczne naprawy, następnie kolejne dobudówki, aż w końcu nadchodzi moment, w którym ktoś zadaje pytanie:
„Remontować czy wyburzyć i budować od nowa?”
W świecie IT to pytanie wraca regularnie.
Fundamenty mają znaczenie
Każdy program kiedyś był nowoczesny. Tak samo jak każdy budynek był kiedyś nowy. Problem pojawia się po latach:
- zmieniają się wymagania,
- dochodzą nowe przepisy,
- użytkownicy oczekują więcej,
- technologia idzie naprzód.
Program, który w 2010 roku był idealny, w 2026 może przypominać kamienicę z popękanymi instalacjami i dobudowanymi przez lata prowizorkami.
Największy problem polega na tym, że wiele systemów rozwija się bez planu architektonicznego. Kolejne funkcje są „doklejane”, poprawki robione „na szybko”, a tymczasowe rozwiązania zostają na lata.
W pewnym momencie koszt utrzymania zaczyna przewyższać koszt stworzenia czegoś nowego.
Dług technologiczny jak zagrzybienie ścian
W budownictwie można przez lata malować ściany, ale jeśli fundamenty są wilgotne, problem będzie wracał. W programowaniu podobnie działa dług technologiczny.
Objawia się on między innymi:
- powielonym kodem,
- brakiem dokumentacji,
- starymi bibliotekami,
- zależnościami, których nikt już nie rozumie,
- bazą danych rozbudowywaną bez spójnej koncepcji,
- procedurami „tymczasowymi”, które działają od dziesięciu lat.
Na pierwszy rzut oka system może działać poprawnie. Ale każda zmiana staje się coraz droższa i bardziej ryzykowna. Programiści zaczynają bać się dotykać pewnych fragmentów kodu. Tak jak ekipa remontowa boi się ruszyć ścianę, bo nie wiadomo, co się zawali.
Czy zawsze warto burzyć?
W świecie IT często pojawia się pokusa:
„napiszmy wszystko od nowa”.
Brzmi atrakcyjnie. Nowa technologia, nowy interfejs, świeża architektura. Problem w tym, że przepisywanie systemu od zera bardzo często kończy się katastrofą.
Dlaczego?
Bo stary system przez lata zgromadził ogromną ilość wiedzy biznesowej:
- nietypowych wyjątków,
- specyficznych procesów,
- zachowań użytkowników,
- obejść problemów,
- integracji z innymi systemami.
Część tej wiedzy istnieje wyłącznie w kodzie.
To trochę jak ze starym budynkiem. Na papierze wygląda źle, ale po dokładnych oględzinach okazuje się, że fundamenty są solidne, a część konstrukcji można uratować.
Kod ma przewagę nad betonem
I tutaj pojawia się największa różnica między budownictwem a oprogramowaniem.
Budynek trudno rozebrać fragmentami bez wpływu na całość. Kod daje znacznie większe możliwości.
Można:
- wymieniać moduły etapami,
- modernizować bazę danych stopniowo,
- przepisywać pojedyncze usługi,
- oddzielać stare komponenty od nowych,
- tworzyć warstwy pośrednie,
- migrować użytkowników krok po kroku.
Dobrze prowadzona modernizacja przypomina generalny remont prowadzony bez zamykania całego obiektu.
To często najlepsza droga dla systemów biznesowych, które muszą działać każdego dnia.
Najdroższy jest chaos
Nie każdy stary system jest zły. Widziałem aplikacje napisane kilkanaście lat temu, które nadal działają stabilnie i są łatwe w utrzymaniu. Widziałem też nowe projekty, które po dwóch latach nadawały się do przebudowy.
Wiek systemu nie jest największym problemem.
Największym problemem jest brak architektury i brak konsekwencji.
Jeżeli przez lata:
- przestrzegano standardów,
- dbano o bazę danych,
- dokumentowano zmiany,
- pilnowano jakości kodu,
- unikali przypadkowych rozwiązań,
to nawet stary system może być wartościowy.
Nie wszystko trzeba zaczynać od zera
W branży IT często zachwycamy się nowością. Nowe frameworki, nowe języki, nowe architektury. Tymczasem wiele firm działa dzięki systemom rozwijanym od dekady lub dłużej.
I bardzo często bardziej opłaca się mądry remont niż spektakularne wyburzenie.
Bo prawdziwą wartością systemu nie jest sam kod. Wartością jest wiedza biznesowa, którą ten kod zawiera.
Dlatego przed decyzją o napisaniu wszystkiego od nowa warto zadać sobie pytanie:
Czy naprawdę nie ma tu ściany nośnej, którą warto zachować?