Un buon flusso di lavoro per Delphi è semplice. Apri la cartella del progetto, chiedi una modifica, leggi il diff ed esegui il comando di build. Arraydeck segue questo ciclo con strumenti reali, quindi ogni passaggio lascia una scheda nella chat che puoi espandere e ispezionare, dalla prima ricerca all'ultimo codice di uscita. Niente è nascosto dietro un riepilogo. Se un passaggio sembra sbagliato, interrompi il ciclo lì, rifiuta la modifica e riformula la richiesta, e i file rimangono come erano prima di quel passaggio. Gli stessi quattro passaggi funzionano su una piccola unità e su un progetto con molti form. Principianti e manutentori esperti possono iniziare con una ricerca in sola lettura, perché non modifica alcun file e mostra comunque come è strutturato il progetto.
Scegli la cartella che contiene i file .dpr e .pas come cartella di lavoro della chat. Gli strumenti per i file operano al suo interno, quindi seleziona il progetto che vuoi modificare e non una cartella padre contenente lavoro non correlato. Una cartella padre con molti progetti rende la prima ricerca più difficile da leggere e aumenta il rischio di modificare l'unità sbagliata.
Scrivi un'attività in parole semplici, come il nome di una procedura e cosa dovrebbe cambiare, e scegli Auto-run, Ask first o Plan only prima di inviarla. Le attività piccole producono diff piccoli, facili da leggere. Indica l'unità quando la conosci; l'agente può trovarla con glob, ma specificare un'unità nota restringe la prima ricerca.
Espandi la scheda edit_file, leggi ogni riga aggiunta e rimossa, quindi accetta o rifiuta la modifica. Se hai usato Plan only, leggi prima il piano e passa a Ask first per eseguirlo passo dopo passo. Un diff molto lungo significa che l'attività era troppo grande, quindi rifiutala e dividi la richiesta in due più piccole.
Lascia che Shell esegua il tuo comando di build e il tuo comando di test, e leggi il vero codice di uscita nella scheda. Una build andata a buon fine è un buon segno, ma solo i tuoi test ti dicono se il comportamento è ancora corretto. Esegui la build prima dei test e tieni aperte entrambe le schede in modo che un errore possa essere ricondotto a una singola modifica.
.6 vociGreeter.passalvatoGreeter.paslettobuild.batexit 0unit Greeter;
interface
function Greet(const Name: string): string;
implementation
function Greet(const Name: string): string;
begin
if Name = '' then
Result := 'Hello, guest'
else
Result := 'Hello, ' + Name;
end;
end.Greet accetta un nome e restituisce un saluto. Quando il nome è vuoto risponde "Ciao, ospite", altrimenti unisce il nome al testo, e Result contiene il valore di ritorno della funzione. La sezione interface dichiara la funzione, mentre la sezione implementation ne contiene il codice, che rappresenta la struttura standard di ogni unità.
I principianti che imparano Delphi chiedono spesso dove viene salvato un valore su disco. Chiedi ad Arraydeck di trovare dove viene scritta l'impostazione. L'agente esegue grep per il nome dell'impostazione nei tuoi file .pas, poi read_file apre l'unità corrispondente e la risposta appare nella chat con nomi di file e righe. Niente cambia. Apri l'unità nel tuo editor per confermare che la procedura è quella che intendevi e annota il nome del file prima di chiedere una modifica. Questa ricerca in sola lettura è un'ottima prima richiesta su qualsiasi progetto che non hai scritto tu. Annota il file e la riga prima di chiedere qualsiasi modifica, perché un nome di file e un numero di riga precisi rendono la richiesta successiva breve e il diff successivo facile da seguire per chiunque legga il tuo progetto in futuro.
Chiedi un gestore più sicuro: trova la procedura che crea un oggetto e assicurati che venga rilasciato. L'agente cerca con grep, legge l'unità e propone la modifica con edit_file, racchiudendo il codice in try ... finally ... Free. In Ask first il diff appare e niente viene scritto finché non lo accetti. Poi Shell esegue il tuo comando di build e la scheda mostra il vero codice di uscita. Esegui anche i tuoi test. Una build passata dimostra solo la sintassi, non che l'oggetto viene rilasciato in ogni percorso, quindi leggi il diff con attenzione. Esegui di nuovo i test dopo aver accettato il diff e mantieni la vecchia versione dell'unità nel tuo backup o nel controllo versione finché non sei sicuro che il gestore rilasci ancora ogni oggetto in ogni ramo.
Ecco come modernizzare le app Delphi in piccoli passaggi: rinomina una procedura poco chiara, un nome alla volta. Chiedi all'agente di rinominarla in ogni unità. Usa grep per elencare ogni punto in cui il nome appare, poi edit_file modifica ogni file e i diff mostrano ogni riga che cambia. Rinomina una volta. Rivedi tutti i diff insieme, perché una parola corrispondente all'interno di una stringa o di un commento non è sempre una chiamata, poi compila il progetto ed esegui i tuoi test prima di accettare l'ultimo file. Ripeti la rinominazione per la procedura successiva solo quando la build e i test passano, in modo che un errore sia sempre contenuto in un piccolo diff e non si nasconda in un lungo elenco di modifiche non correlate su molte unità.
La logica del triangolo di Pascal spiegata in un'unità breve è un'ottima richiesta di pratica. Chiedi all'agente di leggere il ciclo e descrivere, riga per riga, cosa contiene ogni variabile in ogni iterazione. Chiama read_file, poi risponde nella chat senza scrivere niente, quindi Plan only è sufficiente. Controlla la spiegazione eseguendo l'unità tu stesso tramite il comando di build e seguendo il ciclo su carta per 3 o 4 righe. Se l'agente e il programma sono in disaccordo, fidati del programma e riponi la domanda citando esattamente la riga. Fai lo stesso per un secondo ciclo se la prima risposta è stata utile, e chiedi una spiegazione più breve quando un paragrafo sembra lungo, perché puoi sempre richiedere più dettagli esattamente sulla riga che ti confonde.
