Factory in pratica: code review, test e refactoring automatici

👁 117 letture

Factory offre il massimo valore ai team in cui il lavoro di programmazione importante resta in coda perché c’è sempre qualcosa di più urgente: code review, test, correzione di piccoli bug, refactoring del codice legacy. Abbiamo raccolto le applicazioni in cui gli agenti Droid tolgono più lavoro al team.

Come installare Droid e configurare la code review automatica l’abbiamo descritto nel tutorial di Factory.

Da dove iniziare nel team

Il primo passo più sicuro è la code review automatica delle pull request. Non modifica alcun codice, aggiunge solo commenti, quindi il team può valutare la qualità del lavoro dell’agente senza rischi. Dopo due settimane si vede se i commenti sono pertinenti. Il secondo passo sono i piccoli bug dalla lista del backlog, assegnati uno alla volta e revisionati come le modifiche di un collega. Solo dopo si passa a task più grandi in modalità specifica.

È importante che tutto il team conosca le regole: chi assegna i task all’agente, chi revisiona le sue modifiche e quali aree del codice l’agente non può toccare senza autorizzazione.

Code review automatica di ogni pull request

L’implementazione più semplice e spesso la più percepibile. Droid revisiona ogni pull request prima che la veda un essere umano e commenta righe specifiche. Si concentra sugli errori, non sullo stile. Il reviewer umano riceve una modifica da cui sono già stati individuati i problemi evidenti e può concentrarsi sulla logica e sull’architettura.

Review prima dell’invio

Il comando per revisionare le modifiche locali permette al programmatore di controllare il codice prima che qualcuno lo veda. Meno cicli di correzioni nella pull request significa merge più veloci e meno context switching tra i task.

Correzione di piccoli bug

In ogni progetto c’è una lista di piccoli bug che nessuno ha tempo di correggere. Descrivi il bug, Droid trova la causa e propone una correzione che revisioni come qualsiasi altra modifica. La lista arretrata si riduce senza sottrarre tempo alle nuove funzionalità.

Test per codice che non ne ha

I moduli più vecchi spesso non hanno test, quindi ogni modifica è rischiosa. Droid scrive test per il codice esistente e tu verifichi se testano ciò che è davvero importante. Dopo qualche settimana le modifiche al vecchio codice smettono di essere una lotteria.

Migrazioni e modifiche importanti con un piano

Aggiornamento di una libreria, modifica della struttura del database, passaggio a una nuova versione del linguaggio. La modalità specifica prima analizza il progetto e presenta un piano, e il team lo approva prima della prima modifica. La documentazione di Factory raccomanda questa modalità proprio per migrazioni e modifiche sensibili alla sicurezza.

Task in script e CI

Quando un certo lavoro con Droid funziona bene, puoi eseguirlo senza finestra interattiva, ad esempio nella pipeline CI. Task ripetitivi come review o generazione di report sulle modifiche avvengono automaticamente ad ogni deployment.

Lavoro nell’editor preferito

Droid funziona in VS Code, Cursor, Windsurf, editor JetBrains e Zed. Il team non deve cambiare strumenti, e in VS Code l’agente vede il file aperto e gli errori dell’editor.

Esempio: una settimana con il debito tecnico

Un team di quattro programmatori ha in lista trenta piccoli bug e un modulo pagamenti senza test. Lunedì attiva la code review automatica delle pull request. Ogni programmatore assegna quotidianamente a Droid due piccoli bug e revisiona le correzioni. Mercoledì pianificano in modalità specifica i test del modulo pagamenti e venerdì li integrano dopo la review. La lista dei bug scende della metà senza cancellare il lavoro sulla nuova funzionalità.

La chiave è che il team non ha cancellato il lavoro sulla nuova funzionalità. L’agente ha preso in carico i task che comunque aspettavano in coda, e le persone si sono occupate della review delle sue modifiche, che richiede meno tempo che scrivere le correzioni da soli. Vale la pena rispettare una regola: ogni modifica dell’agente ha un proprietario nel team che l’ha revisionata e approvata. Così nessuno perde la conoscenza di ciò che è cambiato nel codice.

A cosa fare attenzione

• Revisiona ogni modifica dell’agente come una modifica umana.
• La review automatica non sostituisce il reviewer nelle decisioni architetturali.
• Aumenta gradualmente l’autonomia dell’agente, quando sai come se la cava con il progetto.

Come verificare se conviene

Misurate ciò che realmente pesa sul team. Il tempo dall’apertura della pull request al merge, perché la review automatica dovrebbe ridurlo. Il numero di bug nella lista del backlog all’inizio e dopo un mese. La copertura dei test nei moduli che ne erano privi.

Se dopo un mese nessuno di questi numeri si è mosso, il problema di solito non sta nello strumento, ma nel fatto che nessuno ha tempo di revisionare le modifiche dell’agente. In quel caso vale la pena stabilire un momento fisso della settimana per la review di ciò che ha preparato.

Vale anche la pena annotare quali tipi di task l’agente esegue meglio. Dopo un mese il team sa cosa assegnare subito e cosa è meglio fare da soli, e smette di perdere tempo a provare ad affidare all’agente task che richiedono conoscenze esterne al codice, ad esempio accordi con il cliente.

// continua a leggereAutomatizzazione con AI: strumenti, costi e scenari praticiMagazineCustomer.io in pratica: onboarding, carrelli e retentionGuideAutomatizzare i social media con AI: da idea a post programmatoGuide