Od lat zajmuje mnie rozkład. Jędrne, gładkie ciała obumierają w zmarszczone, poplamione truchła. Imperia pełne chwały i potęgi rozpadają się na symetryczne zgliszcza gruzu, obmywane deszczem i spiekane słońcem. Lśniące atomowym blaskiem gwiazdy zapadają się w parujące oddechem wymarłych światów czarne dziury. Nic nie jest wolne od rozkładu, bo panta rhei kai ouden menei. Również to, co spod naszych palców wyrasta – oprogramowanie.
Kod oczywiście jest doskonały, cyfrowy, nie poddaje się entropii. Tak samo jak nie poddaje się jej choćby Odyseja Homera. Tyle, że stworzony dawno temu program, jak i wieki temu spisana Odyseja nie żyją w próżni. Powstały dla odbiorców. I tak jak dziś inni są Europejczycy od Greków sprzed tysiącleci, tak samo ewoluuje ekosystem, w którym przychodzi egzystować oprogramowaniu.
Choć jest właściwie jeszcze gorzej. Programy bowiem powstają latami. Rozwijane są nowe funkcjonalności, aktualizowana jest ich integracja ze światem zewnętrznym, czasami wręcz zmianie ulegają technologie, z jakich aplikacje się składają.
I tu pojawia się rozkład. I błędne koło.
Na początku program tworzy się szybko. Stąd pewnie zachwyt wielu początkujących programistów (oraz gorycz doświadczonych). Im więcej kodu, tym więcej zmartwień, jak i w przysłowiowym lesie więcej drzew im głębiej. Zaś im więcej ludzi w projekcie tym już piekło jest wybrukowane…
Pierwsi programiści w projekcie często są bardzo doceniani. Siadają, piszą, działa. Można wdrażać na produkcję albo pokazać klientom lub przełożonym. Sukces. Za ten sukces zwykle są nagradzani. Awansują albo są kierowani do kolejnych nowych projektów. Ci mniej lubiani trafiają zaś do projektów już istniejących. Im niżej w hierarchii dziobania tym do starszych i bardziej zapleśniałych.
Sęk w tym, że bodźce kształtujące zachowanie są zwykle rozłożone niekorzystnie. Tworzy to koszmarne zjawiska i prowadzi do wspomnianego błędnego koła. Błędnego koła tworzenia, próchnienia i burzenia.
Programiści tworzący projekty greenfield (nowe, od zera) nie zmagają się z konsekwencjami swoich czynów. Mogą pisać co chcą, jak chcą, byle wytrwać z rok, czy dwa, do odkorkowania szampana i wdrożenia projektu. Mogą eksperymentować, ale też nagradzani będą ci, którzy jak najszybciej i jak najtaniej zaimplementują zestaw podstawowych funkcjonalności. Bodźce więc są proste – pisz szybko, byle jak (choć nie za bardzo), używaj nowych technologii, które ładnie wyglądają w CV, a jak napiszesz to oczekuj, że trafisz do nowego projektu albo poszukaj go na rynku pracy. Co dalej z kodem? Pal licho, nie twój interes.
Programiści utaplani w błocie legacy z kolei mają małe albo wręcz żadne – w zależności od stopnia rozkładu – szanse na poprawienie sytuacji. Jeśli projekt jest jeszcze względnie nowy, mogą próbować coś ratować, ale nie mogą uciekać od tworzenia nowych funkcjonalności. W każdym wypadku wypadną gorzej od pierwotnych twórców – będą zawsze pisać wolniej. Dlatego, że twórcy narobili bałaganu, w którym teraz trzeba się odnaleźć albo dlatego, że kodu jest więcej i jest trudniej nawet jak jest schludnie albo też jest średnio i trzeba posprzątać, więc również robi się to wolniej, niż na początku. Bodźce są takie, że najlepiej nic nie sprzątać i nie usprawniać, bo za to chwały nie będzie. Więc zwykle się nie sprząta. Tym bardziej, że biznes również tym sprzątaniem nie jest zainteresowany – kosztuje to, skutki bałaganu nadejdą za rok, dwa, pięć, gdy już ich nie będzie, a poza tym trzeba klepać nowe ficzery, bo to przynosi zysk.
Finalna faza rozkładu oprogramowania to legacy dojrzałe. Taka gorgonzola cremoso. Już nie tylko pleśń zielonymi żyłkami przecina nam kod jak w Matriksie, ale też sama struktura jest miękka i z lekka galaretowata. Poprawić nic się nie da, jak nie da się skleić szklanki. Można ją tylko – cytując klasyka – pogryźć i połknąć. I to też robią całymi dniami deweloperzy skazani na opiekę paliatywną nad projektami u progu śmierci. Bug za bugiem, debug za debugiem, w beznadziei dnia codziennego. Nikt nie porywa się tam na zmiany. Zmienić można co najwyżej pracę, ale i o to trudno, bo pracuje się przecież w starych technologiach, a i zapomniało się już nawet jak pisać przyzwoicie, patrząc przez dłuższy czas na starcze wynaturzenia – zrakowiałe struktury danych, zdegenerowane algorytmu i ułomne, antyczne narzędzia o finezji cepa bojowego, ewentualnie wekiery…
Programowanie w ostatniej fazie czeka na decyzję. Na decyzję o przepisaniu go od nowa. I tak zamyka się błędne koło – projekt dostają programiści z ładnym CV, którzy zawsze robią greenfieldy, potem ci mniej bohaterscy, którzy utrzymują systemy wieku średniego, aż w końcu trafia on znów do pielęgniarzy i pielęgniarek, którzy ostatnim ticketem zamkną mu oczy i wyślą na wieczny odpoczynek do krainy wiecznych pętli.
Tyle, jeśli chodzi o diagnozę. Pytanie – co z receptą? Nie umiem sobie do tej pory na nie odpowiedzieć. Wydaje się, że większość systemów informatycznych kończy właśnie w taki sposób i jest to jakimś naturalnym biegiem w cyklu życia oprogramowania. A wy, znacie jakieś alternatywy?
To przykre, że ktoś nie przykłada się do jakosci. Myślę, że to konsekwencja braku zmierzenia się swoim kodem po czasie. Taki ktoś nie ma okazji żeby wyciągnąć wnioski. Czasu niestety zawsze będzie za mało, biznes będzie naciskał i ciął budżet. Zresztą nawet mając nieograniczony czas nie da się napisać rozwiązania uniwersalnego. W końcu przyjdzie zmiana która wywróci całość do góry nogami. Pozostaje tylko zacisnąć zęby i refaktoryzować.