Modernizujcie system po kawałku

Najpierw nazwijcie problem: trudne zmiany, koszt utrzymania, zależności czy brak wiedzy. Dopiero potem zdecydujcie, czy usprawniacie kod, wymieniacie fragment, czy przepisujecie większą część.

Moja droga: z aplikacji desktopowej do chmury

Kupiliśmy kod źródłowy systemu desktopowego, czyli aplikacji działającej na komputerze użytkownika. Chcieliśmy przenieść ją do chmury i przy okazji zmienić technologię z .NET na Javę. Kod mieliśmy, więc moja pierwsza myśl była prosta: może AI po prostu go przepisze?

W naszych próbach modele nie radziły sobie z tym wystarczająco dobrze. Dziś też nie oparłbym całego takiego projektu na poleceniu „przepisz ten system”. Może niedługo będzie inaczej — ale wtedy musieliśmy wybrać drogę, którą dało się przejść.

Poszliśmy klasycznie: ekspert opisywał działanie, zaglądaliśmy do kodu źródłowego i przepisywaliśmy system krok po kroku. To było długie i drogie. Dostęp do kodu nie oznaczał, że od razu rozumieliśmy wszystkie reguły i powiązania.

Teraz podszedłbym do tego inaczej. Przekonało mnie podejście z middleware. Najpierw agenci opisują logikę i zależności systemu w plikach .md i JSON. Powstaje model, po którym mogą się poruszać, zamiast za każdym razem odtwarzać działanie z kolejnych kawałków kodu.

Dla mnie to był moment „wow”: agenci mogli patrzeć na system jako całość i powiązać analizowany fragment z resztą. Wykorzystaliśmy to podejście przy realizacji Szacuna i sprawdziło się u nas bardzo dobrze.

Więcej o middleware i o tym, co nazywam „spłaszczeniem” kodu

Mój wniosek: zanim poprosicie AI o nową wersję systemu, sprawdźcie, czy potrafi odtworzyć jego działanie, reguły i zależności. Sam nowy kod nie pokaże wam, czego zabrakło po drodze.

Zlecacie przepisanie? Sprawdźcie, co naprawdę możecie przejąć

Zanim obecny albo nowy wykonawca zacznie zmiany, sprawdźcie kontrolę nad kodem, domeną, kontami i środowiskami. Wskażcie, kto po waszej stronie rozumie system oraz potrafi go wdrożyć i utrzymać. U nas własny zespół potrafił już rozwijać kod, a nadal potrzebowaliśmy wykonawcy przy środowiskach. Dlatego rozdzielam te dwie umiejętności.

Przygotujcie exit plan, czyli sposób zakończenia współpracy zapisany w umowie: listę przekazania obecnego systemu, terminy, odpowiedzialności i warunki odbioru. Ustalcie też zasady dokumentowania nowego rozwiązania. Ustalcie, kto utrzymuje działającą wersję podczas modernizacji i kto przejmie ten obowiązek po zmianie. Przepisanie kodu samo nie usuwa zależności od wykonawcy.

Zobacz moje pięć lekcji ze współpracy z software house’em i listę do uzupełnienia

To te same ramy co przy nowym projekcie, uzupełnione o przejęcie istniejącej wiedzy i ciągłość działania.

Zabezpieczcie obecne zachowanie

Zacznijcie od rozpoznania jednego obszaru oraz sprawdzenia luk w dokumentacji systemu. Zapiszcie przykładowe dane wejściowe i oczekiwane wyniki, połączenia z innymi systemami oraz to, czego nie wolno przerwać. Dodajcie testy zachowania, które pozwolą porównać wersje.

Nie każde stare zachowanie jest wymaganiem. Osoba znająca produkt rozstrzyga, co zachowujecie, co jest błędem, a co nadal wymaga wyjaśnienia. Agent nie powinien utrwalać błędu tylko dlatego, że znalazł go w kodzie.

Porównajcie trzy możliwości

Na podstawie sprawdzonego opisu systemu [źródła i wersja] porównaj usprawnienie obecnego kodu, wymianę fragmentu oraz przepisanie. Chcemy usunąć [konkretny problem]. Uwzględnij reguły dziedziny, dane, połączenia z innymi systemami, koszt, utrzymanie i bieżącą pracę zespołu. Podaj za i przeciw, niewiadome i dowody potrzebne do decyzji. Zaproponuj najmniejszy etap, sposób porównania zachowania i powrotu do poprzedniej wersji. Nie zaczynaj migracji ani nie zmieniaj produkcji.

Przenieście jeden fragment i porównajcie wynik

Wybierzcie fragment, którego wymiana rozwiąże wskazany problem. Otwórzcie starą i nową wersję na tych samych danych testowych. Zapiszcie porównanie przy zadaniu:

Każdą różnicę rozstrzygnijcie z osobą odpowiedzialną za produkt lub regułę: poprawa błędu, uzgodniona zmiana czy problem do naprawienia. Zapiszcie decyzję. Nowy kod i nowe testy mogą być zgodne ze sobą, a mimo to rozmijać się z potrzebą użytkownika.

Dołączcie kartę do rozmowy i wypełnijcie jej część „Modernizacja”. Są tam pola na porównanie wersji, dane, warunek przełączenia i powrót. Przed zmianą zapisu danych ustalcie też, co stanie się ze zgłoszeniami dodanymi już w nowej wersji. Samo uruchomienie starego kodu może ich nie obsłużyć. Sposób wycofania przećwiczcie na kopii danych dopuszczonej do testów, zanim przełączycie użytkowników.

Pokażcie demo starego i nowego przebiegu. Po poprawkach wykonajcie potrzebny refaktor, testy i niezależny przegląd. Zapiszcie różnice oraz decyzje, zamiast oznaczać cały obszar jako gotowy po jednej udanej próbie.

Wynik etapu: potwierdzone zachowanie, sprawdzone dane i możliwość wycofania odpowiednia do zmiany. Opis stanu obecnego i docelowego ma być rozróżniony w istniejącej dokumentacji. Wyłączenie starego elementu wymaga osobnej decyzji po spełnieniu ustalonych warunków.