Jeśli agent potrafi zmienić kod, uruchomić testy i przygotować poprawkę do przeglądu, pojawia się następne pytanie: jak zorganizować cały proces, żeby te działania regularnie kończyły się użytecznym oprogramowaniem? Tym właśnie zajmuje się idea software factory, czyli fabryki oprogramowania.
Co proponuje Zach Lloyd
Inspiracją do tego tekstu jest wystąpienie Zacha Lloyda z Warp o samodoskonalących się software factories. Autor przewiduje, że coraz większa część pracy inżyniera będzie polegać na projektowaniu procesu, w którym agenci realizują kolejne etapy tworzenia oprogramowania. Omawia drogę od zgłoszenia, przez specyfikację, implementację i weryfikację, aż po wdrożenie i obserwację działania. Pozostawia w niej miejsca na ocenę człowieka.
Ważny jest też wątek uczenia się procesu na poprawkach: uwagi z przeglądów mogą prowadzić do lepszych instrukcji i automatyzacji. To nie oznacza automatycznego trenowania od nowa samego modelu. Wystąpienie łączy tę wizję z otwartym rozwijaniem produktu i znaczeniem dystrybucji, marki oraz społeczności.
To perspektywa twórcy narzędzia dla programistów oraz prognoza kierunku zmian. Podawane w wystąpieniu horyzonty czasowe nie dowodzą, że każdy zespół osiągnie taki poziom automatyzacji w podobnym terminie. Poniżej rozwijamy własny przykład zastosowania tej idei i kryteria, według których warto ją oceniać.
Fabryka zaczyna się od warunków odbioru
W dobrze zaprojektowanym procesie da się odpowiedzieć na trzy pytania: co ma powstać, po czym poznamy poprawny wynik i kto może dopuścić zmianę do użytkowników. Agent potrzebuje tych odpowiedzi tak samo jak osoba dołączająca do projektu.
Weźmy przykładowy system rezerwacji. Klient zgłasza, że po ponownym kliknięciu przycisku powstają dwie rezerwacje tego samego terminu. Samo polecenie „napraw duplikaty” pozostawia dużo swobody. Można zablokować przycisk, odrzucić każde ponowne żądanie albo zmienić zapis w bazie. Te rozwiązania mają różne skutki, zwłaszcza przy problemach z siecią.
Proponowana specyfikacja powinna ustalić, że ponowienie tej samej operacji zwraca jej istniejący wynik, a dwie różne osoby nie mogą skutecznie zarezerwować ostatniego wolnego miejsca. Powinna też określić zachowanie po utracie połączenia i sposób pokazania wyniku w interfejsie. Dopiero wtedy można sensownie ocenić implementację.
W takim układzie specyfikacja staje się wspólnym punktem odniesienia dla autora kodu, osoby oceniającej zmianę i testów. Jeżeli każda z tych stron przyjmie inne znaczenie słowa „duplikat”, dodatkowa automatyzacja tylko szybciej ujawni rozbieżność.
Kod i testy mogą pomylić się w ten sam sposób
Agent może przygotować test, który potwierdza jego własną interpretację zadania. Taki test bywa poprawny technicznie, a mimo to nie sprawdza rzeczywistego problemu. W naszym przykładzie kliknięcie przycisku dwa razy w jednej przeglądarce nie odtwarza jeszcze dwóch jednoczesnych zapisów z różnych urządzeń.
Dlatego zaproponowalibyśmy osobne scenariusze dla ponowienia żądania po przerwaniu połączenia, równoczesnych rezerwacji i braku uprawnień do cudzej rezerwacji. Oczekiwane wyniki należy wyprowadzić z uzgodnionych zasad produktu. Osoba wykonująca przegląd powinna móc odtworzyć błąd i zobaczyć, że poprawka go usuwa.
Automatyczny przegląd kodu może pomóc znaleźć problem, ale sam również ma ograniczenia. GitHub wskazuje, że agent może przeoczyć błędy, zgłosić nieistniejącą usterkę lub zaproponować niepoprawny czy podatny kod. Zaleca ocenę oraz testowanie wyników i uzupełnienie automatycznej analizy przeglądem człowieka. GitHub — ograniczenia agentów.
W proponowanym procesie zakres kontroli zależałby od skutków błędu. Zmiana opisu przycisku i migracja danych rezerwacji nie powinny wymagać identycznej ścieżki odbioru. W drugim przypadku potrzebne są między innymi kopia danych, sprawdzenie migracji na reprezentatywnym zbiorze i plan postępowania po niepowodzeniu.
Kontekst projektu musi być dostępny
Przydatnym punktem startowym jest repozytorium, w którym nowa osoba potrafi uruchomić aplikację, znaleźć zasady biznesowe i wykonać najważniejsze testy. Dla agenta równie istotne będą krótkie instrukcje: gdzie znajduje się logika rezerwacji, kto może zmieniać jej stan i z jakimi usługami system się komunikuje.
Proponujemy zapisywać przede wszystkim decyzje, których nie da się łatwo odczytać z samego kodu. Na przykład: dlaczego rezerwacja wstępna wygasa, co stanowi potwierdzenie płatności oraz jaki wynik powinno dać ponowienie operacji. Długi dokument powtarzający nazwy plików będzie mniej użyteczny niż krótki opis tych reguł.
Informacje przekazywane do narzędzi powinny być dobrane do zadania. Do odtworzenia błędu rezerwacji można przygotować dane testowe zamiast pełnej bazy klientów. Dostęp do sekretów i produkcji powinien wynikać z roli w procesie; możliwość edycji kodu nie wymaga automatycznie uprawnienia do wdrożenia.
O uporządkowaniu zależności przed implementacją pisaliśmy też w artykule „Zanim powstanie kod”. Agent nie usuwa potrzeby rozumienia architektury. Zwiększa znaczenie tego, czy da się ją jasno objaśnić i sprawdzić.
Przejście testów nie kończy dostarczania zmiany
Poprawka musi jeszcze trafić do działającej aplikacji. Powtarzalny proces budowania i wdrażania pozwala wiedzieć, która wersja została sprawdzona oraz jak wrócić do poprzedniej. Materiały Google SRE opisują również wdrożenia kanarkowe: ograniczone udostępnienie nowej wersji i ocenę jej zachowania przed rozszerzeniem zasięgu. Google SRE — bezpieczne wdrażanie zmian.
W przykładzie rezerwacji obserwowalibyśmy nie tylko to, czy serwer odpowiada, ale też czy rezerwacje się zapisują, czy nie przybywa konfliktów i czy użytkownicy otrzymują potwierdzenia. Sam poprawny status strony nie wykryje utraty istotnej operacji.
Plan powrotu wymaga uwagi, gdy zmiana dotyczy danych. Cofnięcie plików aplikacji może nie odwrócić wykonanej migracji. Właśnie dlatego sposób wdrożenia powinien być częścią oceny zmiany, a nie improwizacją po zakończeniu pisania kodu.
Mierz dostarczoną wartość i koszt poprawek
Liczba wygenerowanych linii ani otwartych propozycji zmian nie odpowiada na pytanie, czy zespół pracuje skuteczniej. DORA opisuje miary dostarczania oprogramowania obejmujące czas od zapisu zmiany w repozytorium do produkcji, częstotliwość wdrożeń, powrót po nieudanym wdrożeniu, udział awarii oraz wdrożeń naprawczych. Zaleca ocenę w kontekście konkretnej aplikacji, bez sprowadzania skuteczności do jednej liczby. DORA — miary procesu dostarczania.
Do oceny pilotażu z agentem dołożylibyśmy prosty zapis nakładu pracy:
| Co zapisać | Po co |
|---|---|
| Czas osoby przygotowującej zadanie i sprawdzającej wynik | Żeby zobaczyć, czy oszczędność na implementacji nie przechodzi w dodatkowy nadzór. |
| Koszt narzędzi i wykonania zadania | Żeby porównać pełny koszt zaakceptowanej zmiany. |
| Liczbę powrotów do poprawy z podaną przyczyną | Żeby odróżnić niejasną specyfikację od błędu implementacji lub brakującego środowiska. |
| Wynik uzgodnionego scenariusza użytkownika | Żeby sprawdzić, czy zmiana rozwiązała problem, od którego zaczęliśmy. |
Porównanie powinno dotyczyć podobnych zadań i uwzględniać nieudane próby. Wybranie łatwej poprawki dla agenta i trudnej integracji dla człowieka nie da uczciwego obrazu. Mała próbka pozwoli zauważyć problemy procesu, ale nie uzasadni obietnicy, że każde następne zadanie będzie o określony procent szybsze.
Zacznij od jednego powtarzalnego rodzaju pracy
Dobrym kandydatem do pilotażu może być wąska poprawka z jasnym wynikiem, np. dodanie walidacji jednego formularza wraz ze sprawdzeniem komunikatu błędu. Na początek warto wybrać zadania, dla których zespół potrafi samodzielnie ocenić rezultat i zna sposób przywrócenia poprzedniego zachowania.
Po każdej próbie zapisz, co zatrzymało pracę. Brak danych testowych wymaga przygotowania danych. Niejasna reguła wymaga decyzji produktowej. Przeoczony błąd może wymagać lepszego scenariusza sprawdzającego. Nie każdą przeszkodę rozwiązuje dłuższa instrukcja dla modelu.
Naszym zdaniem najciekawsza część software factory to możliwość potraktowania sposobu tworzenia programu jako systemu, który również projektujemy i ulepszamy. Taki system ma sens wtedy, gdy pomaga dostarczać potrzebne funkcje w przewidywalny sposób. Nadal ktoś musi rozumieć problem klienta, ocenić kompromisy i odpowiadać za działający produkt.
Jeżeli planujesz oprogramowanie dla swojej firmy, zacznij od procesu, który chcesz usprawnić, i kryteriów dobrego wyniku. Dopiero na tej podstawie warto dobierać zakres aplikacji oraz stopień automatyzacji jej rozwoju.