Modernizując stary system, Copilot najpierw porządkuje dowody

Kiedy po raz pierwszy przeniosłem projekt Java z ery 1.5 na nowoczesną maszynę, pierwszą rzeczą, która wyskoczyła, nie był problem z kodem, ale problem z dowodami. Niezależnie od tego, czy kompilację można odtworzyć, czy wynik testu jest taki sam, czy punkt awarii pochodzi z maszyny JVM, obrazu czy kodu źródłowego, te rzeczy określają, jak postępować wcześniej niż „rozpocząć refaktoryzację”. Największą obawą podczas modernizacji starych systemów nie jest to, że zmiany będą powolne, ale to, że nie da się powiedzieć, co stało się po zmianach.

Najpierw napraw scenę, potem kolejne działania będą miały sens. Najcenniejszą rzeczą na tym etapie nie jest dokończenie w IDE, ale pudełko, które można uruchamiać wielokrotnie: stary JDK, stare narzędzia do kompilacji, stare wejścia i stare polecenia testowe są zablokowane w Dockerze. Polecenia takie jak poniższe nie są ładne, ale działają:

docker run --rm -v "$PWD":/src -w /src legacy-jdk8 \
  sh -lc './gradlew test 2>&1 | tee logs/baseline.log'

To polecenie ma tylko jedną funkcję: utrwalenie „dzisiejszej awarii” w możliwy do odtworzenia materiał dowodowy. Bez tego każdy kolejny sukces mógłby być po prostu wynikiem wybaczających okoliczności. Rola drugiego pilota jest tutaj również bardzo jasna. Nie ma to zastąpić oceny, ale pomóc w uporządkowaniu śladów: powtarzające się błędy w długich dziennikach, ścieżki, które powtarzają się w skryptach kompilacji i kilka powtarzających się wpisów w starych testach, można najpierw wykorzystać do wstępnego sprawdzenia. Odsiewa się nie wnioski, ale mapę na początek.

Kiedy przychodzi czas, aby faktycznie pójść pod nóż, obszar zmian musi być bardzo wąski. Najłatwiejszym sposobem na unieważnienie starych projektów jest jednoczesna zmiana nazwy pakietu, kompilacji, wpisu i testowania. Ostatecznie nie można nawet stwierdzić, który krok zepsuł system. Bardziej stabilne podejście polega na tym, aby najpierw wykorzystać najmniejszą szczelinę: na przykład przykryć stare wejście warstwą adapterów, najpierw pozwolić, aby nowy łańcuch narzędzi stanął poza starym światem i wyraźnie widział strukturę, a następnie powoli się wprowadza. Copilot doskonale nadaje się do obsługi tego rodzaju prac mechanicznych: wypełniania importów, przenoszenia konfiguracji, wyodrębniania powtarzających się fragmentów i generowania tymczasowych szkieletów testowych. Pozwól modelowi zrobić te rzeczy, a wydajność będzie rzeczywiście wysoka; ale to nadal od ludzi zależy, czy ten szew należy przeciąć i jakie zachowanie zachować po przecięciu.

Również w przypadku testów łatwo dać się zwieść pozorom. Zdanie starego testu nie oznacza, że ​​modernizacja jest bezpieczna, oznacza jedynie, że pewne zachowania historyczne nie zostały jeszcze przełamane. Testy wielu starych projektów bardziej przypominają migawki behawioralne niż biznesowe specyfikacje semantyczne. Zielony jest po prostu zielony i nie można go bezpośrednio interpretować jako „zrozumienia systemu”. Jednym z najważniejszych działań podczas transformacji jest dodanie nowych, węższych granic testu do każdego małego nacięcia, tak aby test stopniowo zmieniał się z „dziedzictwa historycznego” na „aktualne ograniczenia”. Copilot może pomóc w rozbiciu starych twierdzeń, uzupełnieniu szablonów i wdrożeniu zduplikowanych powłok testowych. Jednak jaka semantyka powinna być zachowana w teście i model nie może podejmować decyzji za system.

W przypadku modernizacji archeologicznej najbardziej niezawodny podział pracy jest w rzeczywistości bardzo prosty: środowisko i kłody odpowiadają za utrwalanie faktów, Copilot jest odpowiedzialny za przenoszenie cegieł i tłumaczenie, a ludzie są odpowiedzialni za podejmowanie decyzji, którą historię należy zachować, a którą wyciąć. Kiedy już stworzymy model wyjaśniający przeszłość systemu, często domysły stają się bardziej przekonujące niż dowody; umieszczając go z powrotem w pozycji zarządzania dowodami i mechanicznej organizacji, staje się bardziej naprawdę użytecznym asystentem.