Modernizacja starego kodu wymaga najpierw archeologii

Najtrudniejszą rzeczą w starym kodzie nigdy nie jest stara składnia, ale stare czasy. Projekt jest wypełniony build.xml, starym JDK, starym frameworkiem testowym i starymi metodami pakowania. Na pierwszy rzut oka wygląda to jak kilka stosów akt, ale w rzeczywistości są to warstwy historycznych założeń ułożone jedna na drugiej. Sam kod jest tylko najbardziej zewnętrzną warstwą. Tym, co tak naprawdę blokuje realizację, często jest to, czy założenia te nadal istnieją, czy można je odtworzyć i czy stare zachowanie zostanie utracone po zmianach.

Dlatego „archeologia” poprzedza „transformację”. Najpierw spójrz na plik kompilacji, następnie na zależności, następnie na działające środowisko, a na końcu na testy. Kolejności nie można odwrócić. Plik build.xml nadal tam jest, ale plik pom.xml nie istnieje. Takie sygnały wystarczą, aby wskazać, że projekt żyje w epoce Mrówki; Pierwszym dowodem jest to, czy kod można skompilować, czy można uruchomić testy i czy produkt można odbudować. Najbardziej użyteczną częścią modelu nie jest natychmiastowe pisanie nowego kodu na podstawie starego kodu, ale identyfikacja tych dowodów na podstawie stosu fragmentów.

Najpierw należy także przypiąć otoczenie. Stary kod często zawiera stare maszyny JVM, stare kontenery i stare założenia architektoniczne. Wrzuć go bezpośrednio na dzisiejsze maszyny, zwłaszcza w środowisku obejmującym wiele architektur, a w przypadku wystąpienia problemów łatwo będzie dodać nowy szum: czy kod jest z natury uszkodzony, czy też przyczyną problemów jest emulacja, tworzenie kopii lustrzanych i łańcuchy narzędzi? Jeśli na tym etapie nie uda się nawet osiągnąć „tego samego kodu można stabilnie odtworzyć w tym samym środowisku”, wszelkie późniejsze działania modernizacyjne będą jedynie domysłem.

Wartość sztucznej inteligencji na tym etapie jest jasna: może pomóc w tłumaczeniu na poziomie znaku i struktury. Konwersja Anta na Gradle, konwersja starych skryptów kompilacji do teraz możliwej do utrzymania formy, przeniesienie kilku powtarzalnych plików XML i szablonów do bardziej przejrzystej lokalizacji to wszystko, co jest dobrym kandydatem do pozostawienia modelom. Jest szybki, gotowy do prób raz po raz i nie jest zbyt trywialny. Ale to nie nadaje się do sędziowania. Które ostrzeżenia można zachować jako pierwsze, które testy tak naprawdę kłamią, które moduły należy w pierwszej kolejności odciąć, a które klasy należy jedynie spakować i dostosować. Ostatecznie o tym muszą jeszcze decydować ludzie.

Testowanie to najłatwiejszy sposób na oszukanie ludzi. Zaliczenie testów w starym projekcie nie oznacza, że ​​system jest zrozumiały, może jedynie oznaczać, że niektóre stare zachowania zostały po prostu opakowane w obecne środowisko. To poczucie „całkowicie ekologicznego” jest niebezpieczne, ponieważ często maskuje większy problem: test weryfikuje szczegóły implementacji z określonej epoki, a nie semantykę biznesową, którą należy zachować obecnie. Jeśli naprawdę chcesz reformy, pierwszą rzeczą, którą musisz zrobić, to odrzucić te testy od „dekoracyjnego poczucia bezpieczeństwa” i ponownie ocenić, co chronią.

Dlatego najbardziej stabilnym sposobem dla tego typu projektu jest zwykle nie przepisywanie go za jednym razem, ale najpierw utworzenie kapsuły czasu, aby naprawić stare środowisko, stare zachowania i stare zależności, a następnie usunąć ją wzdłuż najwęższych pęknięć. Najpierw zapewnij powtarzalność systemu, następnie przekaż powtarzalną pracę sztucznej inteligencji do tłumaczenia, a następnie usuń granice warstwa po warstwie. Jeśli porządek jest niewłaściwy, model przyspieszy stary projekt i wepchnie go w głębszy chaos; jeśli kolejność będzie prawidłowa, model będzie niczym naprawdę przydatny asystent archeologa, odpowiedzialny za przenoszenie cegieł, czyszczenie kurzu i porównywanie dowodów, uwalniając ludzi od brudnej roboty i pozostawiając osąd w ich rękach.