W tym rozdziale
O tym podejściu opowiadam w historii przepisywania aplikacji desktopowej. Punktem wyjścia jest kod aplikacji.
W brAIn zbieramy wiedzę dziedzinową. Tutaj odtwarzamy działanie oprogramowania. W MiddleBrain łączymy te dwie rzeczy.
Middleware: najpierw model działania
Pierwszym zadaniem agentów jest wyciągnięcie z kodu opisu tego, jak działa system. Powstają pliki .md, które da się przeczytać, oraz JSON z uporządkowanymi powiązaniami, z których mogą korzystać narzędzia. Ten model jest udostępniany agentom przez middleware — warstwę pośrednią. Model opisuje system, a middleware pozwala z tego opisu korzystać podczas pracy.
Ja tłumaczę to sobie jako „spłaszczenie” kodu z 3D do 2D. To moja metafora: zamiast wchodzić w kolejne klasy i funkcje, żeby dopiero odkrywać połączenia, agent dostaje mapę działania. Może zobaczyć, jak dany fragment łączy się z resztą, i wrócić do kodu po szczegół. Nie musi przy każdym zadaniu zaczynać poznawania systemu od zera.
Przygotowanie tego modelu zajmuje czas. U nas się opłaciło, bo opis logiki można było wykorzystać przy dalszej pracy. Nie jest on przywiązany do składni .NET czy Javy. To otwiera drogę do odtworzenia działania w innej technologii. Nową implementację nadal trzeba jednak zbudować i porównać z oczekiwanym zachowaniem — sama mapa nie przepisuje aplikacji.
Gdybym dziś zaczynał podobne przepisanie, zacząłbym tak:
- Najpierw opis działania i zależności. Dałbym agentowi kod i dostępne materiały. Poprosiłbym o model oraz wskazanie, z których miejsc kodu wynika każda reguła i czego jeszcze nie rozumie.
- Potem sprawdzenie na znanym przebiegu. Wybrałbym jedną czynność użytkownika. Z ekspertem porównałbym jej opis, wynik starego systemu i to, co znalazł agent. Rozbieżności muszą wrócić do modelu.
- Dopiero wtedy nowa implementacja fragmentu. Agent korzysta ze sprawdzonego opisu, a my porównujemy wynik na tych samych danych. Przy kolejnych zmianach aktualizujemy też model, żeby nie opisywał nieaktualnego kodu.
Wróćcie do przepisywania systemu — porównanie starej i nowej wersji
Co trzeba utrzymać wraz z modelem
Model opisuje konkretną wersję kodu. Zostawcie powiązania z implementacją i testami, zaznaczcie nieopisane fragmenty i aktualizujcie opis po zmianach. W przeciwnym razie agent będzie korzystać z mapy innej wersji aplikacji.
Pliki .md opisują znaczenie i działanie; JSON pozwala narzędziu odczytywać uporządkowane powiązania. Sam format nie gwarantuje poprawności ani powtarzalnego wyniku. Opis trzeba sprawdzić z kodem i zachowaniem aplikacji. Tak samo obecność plików nie oznacza jeszcze, że działa usługa middleware.
Twórca produktu
Marcin Zelek