Factory w praktyce: przeglądy kodu, testy i porządki, na które nie ma czasu

👁 117 przeczytań

Factory najwięcej daje zespołom, w których ważna praca programistyczna czeka w kolejce, bo zawsze jest coś pilniejszego: przeglądy kodu, testy, poprawki drobnych błędów, porządki w starym kodzie. Zebrałem zastosowania, w których agenci Droid zdejmują z zespołu najwięcej pracy.

Jak zainstalować Droida i ustawić przegląd kodu, opisałem w samouczku Factory.

Od czego zacząć w zespole

Najbezpieczniejszy pierwszy krok to automatyczny przegląd pull requestów. Nie zmienia żadnego kodu, tylko dodaje komentarze, więc zespół może ocenić jakość pracy agenta bez ryzyka. Po dwóch tygodniach widać, czy komentarze są trafne. Drugim krokiem są drobne błędy z listy zaległości, zlecane pojedynczo i przeglądane jak zmiany kolegi. Dopiero potem większe zadania w trybie specyfikacji.

Ważne, żeby cały zespół znał zasady: kto zleca zadania agentowi, kto przegląda jego zmiany i jakich obszarów kodu agent nie dotyka bez zgody.

Automatyczny przegląd każdego pull requesta

Najprostsze wdrożenie i często najbardziej odczuwalne. Droid przegląda każdy pull request, zanim zobaczy go człowiek, i komentuje konkretne linie. Skupia się na błędach, a nie na stylu. Ludzki recenzent dostaje zmianę, z której wyłapano już oczywiste problemy, i może skupić się na logice i architekturze.

Przegląd przed wysłaniem

Polecenie do przeglądu lokalnych zmian pozwala programiście sprawdzić kod, zanim ktokolwiek go zobaczy. Mniej rund poprawek w pull requeście to szybsze scalenie i mniej przełączania się między zadaniami.

Poprawki drobnych błędów

W każdym projekcie jest lista małych błędów, których nikt nie ma czasu naprawić. Opisujesz błąd, Droid znajduje przyczynę i proponuje poprawkę, którą przeglądasz jak każdą inną zmianę. Zaległa lista maleje bez odbierania czasu na nowe funkcje.

Testy do kodu, który ich nie ma

Starsze moduły często nie mają testów, więc każda zmiana w nich jest ryzykowna. Droid pisze testy do istniejącego kodu, a Ty sprawdzasz, czy testują to, co naprawdę ważne. Po kilku tygodniach zmiany w starym kodzie przestają być loterią.

Migracje i większe zmiany z planem

Aktualizacja biblioteki, zmiana struktury bazy, przejście na nową wersję języka. Tryb specyfikacji najpierw bada projekt i przedstawia plan, a zespół zatwierdza go przed pierwszą zmianą. Dokumentacja Factory poleca ten tryb właśnie przy migracjach i zmianach wrażliwych na bezpieczeństwo.

Zadania w skryptach i CI

Gdy jakaś praca z Droidem się sprawdza, można ją uruchamiać bez interaktywnego okna, na przykład w potoku CI. Powtarzalne zadania, jak przegląd czy generowanie raportu o zmianach, dzieją się automatycznie przy każdym wdrożeniu.

Praca w ulubionym edytorze

Droid działa w VS Code, Cursorze, Windsurfie, edytorach JetBrains i Zed. Zespół nie musi zmieniać narzędzi, a w VS Code agent widzi otwarty plik i błędy z edytora.

Przykład: tydzień z długiem technicznym

Zespół czterech programistów ma na liście trzydzieści drobnych błędów i moduł płatności bez testów. W poniedziałek włącza automatyczny przegląd pull requestów. Każdy programista codziennie zleca Droidowi dwa drobne błędy i przegląda poprawki. W środę w trybie specyfikacji planują testy modułu płatności, a w piątek scalają je po przeglądzie. Lista błędów spada o połowę bez odwoływania prac nad nową funkcją.

Kluczowe jest to, że zespół nie odwołał pracy nad nową funkcją. Agent przejął zadania, które i tak czekały w kolejce, a ludzie zajęli się przeglądem jego zmian, co trwa krócej niż samodzielne pisanie poprawek. Warto przy tym pilnować jednej zasady: każda zmiana agenta ma właściciela w zespole, który ją przejrzał i zatwierdził. Dzięki temu nikt nie traci wiedzy o tym, co zmieniło się w kodzie.

Na co uważać

• Każdą zmianę agenta przeglądaj jak zmianę człowieka.
• Automatyczny przegląd nie zastąpi recenzenta przy decyzjach architektonicznych.
• Samodzielność agenta zwiększaj stopniowo, gdy wiesz, jak radzi sobie z projektem.

Jak sprawdzić, czy to się opłaca

Mierzcie to, co realnie boli zespół. Czas od otwarcia pull requesta do scalenia, bo automatyczny przegląd powinien go skracać. Liczbę błędów na liście zaległości na początku i po miesiącu. Pokrycie testami w modułach, które były bez testów.

Jeśli po miesiącu żadna z tych liczb się nie ruszyła, problem zwykle leży nie w narzędziu, tylko w tym, że nikt nie ma czasu przeglądać zmian agenta. Wtedy warto wyznaczyć stałą porę w tygodniu na przegląd tego, co przygotował.

Warto też zapisywać, które typy zadań agent wykonuje najlepiej. Po miesiącu zespół wie, co zlecać od razu, a co lepiej zrobić samemu, i przestaje tracić czas na próby oddania agentowi zadań, które wymagają wiedzy spoza kodu, na przykład ustaleń z klientem.

Roczny dostęp do Factory sprzedaję taniej niż w oficjalnym cenniku w sklepie kinetyka.pl.