Un bon workflow Delphi est concis. Ouvrez le dossier du projet, demandez un changement, lisez le diff et lancez votre commande de compilation. Arraydeck suit cette boucle avec des outils réels : chaque étape laisse une carte dans le chat, que vous pouvez développer et inspecter, de la première recherche au dernier code de sortie. Rien n’est caché derrière un résumé. Si une étape semble incorrecte, vous arrêtez la boucle, rejetez le changement et reformulez la demande ; les fichiers restent tels qu’ils étaient avant cette étape. Les mêmes quatre étapes fonctionnent sur une petite unité ou sur un projet avec de nombreuses formes. Débutants et mainteneurs expérimentés peuvent commencer par une recherche en lecture seule, car elle ne modifie aucun fichier et montre toujours comment le projet est structuré.
Choisissez le dossier contenant vos fichiers .dpr et .pas comme dossier de travail du chat. Les outils de fichiers fonctionnent à l’intérieur, donc sélectionnez le projet que vous souhaitez modifier et non un dossier parent contenant des travaux non liés. Un dossier parent avec de nombreux projets rend la première recherche plus difficile à lire et augmente le risque de modifier la mauvaise unité.
Écrivez une tâche en mots simples, comme le nom d’une procédure et ce qui doit changer, et choisissez Auto-run, Ask first ou Plan only avant de l’envoyer. Les petites tâches donnent de petits diffs faciles à lire. Nommez l’unité si vous la connaissez ; l’agent peut la trouver avec glob, mais une unité nommée restreint la première recherche.
Développez la carte edit_file, lisez chaque ligne ajoutée et supprimée, puis acceptez ou rejetez le changement. Si vous avez utilisé Plan only, lisez d’abord le plan et passez à Ask first pour le réaliser étape par étape. Un diff très long signifie que la tâche était trop grande : rejetez-le et divisez la demande en deux tâches plus petites.
Laissez Shell exécuter votre commande de compilation et votre commande de test, et lisez le vrai code de sortie sur la carte. Une compilation réussie est un bon signe, mais seuls vos propres tests vous disent si le comportement est toujours correct. Lancez la compilation avant les tests, et gardez les deux cartes ouvertes afin qu’une erreur puisse être tracée jusqu’à un seul changement.
.6 entréesGreeter.passauvegardéGreeter.paslubuild.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 prend un nom et retourne une salutation. Lorsque le nom est vide, il répond « Bonjour, invité », sinon il joint le nom au texte, et Result contient la valeur de retour de la fonction. La section interface annonce la fonction, et la section implémentation contient son code, qui est la structure de toute unité.
Les débutants qui apprennent Delphi demandent souvent où une valeur est enregistrée sur le disque. Demandez à Arraydeck de trouver où le paramètre est écrit. L’agent exécute grep pour le nom du paramètre dans vos fichiers .pas, puis read_file ouvre l’unité correspondante et la réponse apparaît dans le chat avec les noms de fichiers et les lignes. Rien ne change. Ouvrez l’unité dans votre propre éditeur pour confirmer que la procédure est bien celle que vous souhaitiez, et notez le nom du fichier avant de demander une modification. Cette recherche en lecture seule est une bonne première demande sur n’importe quel projet que vous n’avez pas écrit vous-même. Notez le fichier et la ligne avant de demander toute modification, car un nom de fichier et un numéro de ligne précis rendent la demande suivante courte et le diff suivant facile à suivre pour quiconque lira votre projet après vous.
Demandez un gestionnaire plus sûr : trouvez la procédure qui crée un objet et assurez-vous qu’il soit libéré. L’agent recherche avec grep, lit l’unité et propose le changement avec edit_file, en enveloppant le code dans try ... finally ... Free. Dans Ask first, le diff apparaît et rien n’est écrit jusqu’à ce que vous l’acceptiez. Ensuite, Shell exécute votre commande de compilation, et la carte affiche le vrai code de sortie. Lancez également vos tests. Une compilation réussie prouve uniquement la syntaxe, pas que l’objet est libéré dans chaque chemin, donc lisez lentement le diff. Relancez les tests une fois après avoir accepté le diff, et gardez l’ancienne version de l’unité dans votre sauvegarde ou votre système de contrôle de version jusqu’à ce que vous soyez sûr que le gestionnaire libère bien chaque objet dans chaque branche.
Voici comment moderniser les applications Delphi par petites étapes : renommez une procédure peu claire, un nom à la fois. Demandez à l’agent de le renommer dans chaque unité. Il utilise grep pour lister chaque endroit où le nom apparaît, puis edit_file modifie chaque fichier, et les diffs montrent chaque ligne qui bouge. Renommez une fois. Révisez tous les diffs ensemble, car un mot correspondant dans une chaîne ou un commentaire n’est pas toujours un appel, puis compilez le projet et lancez vos tests avant d’accepter le dernier fichier. Répétez le renommage pour la procédure suivante uniquement lorsque la compilation et les tests passent, afin qu’une erreur soit toujours contenue dans un petit diff et ne se cache jamais dans une longue liste de modifications non liées à travers de nombreuses unités.
La logique du triangle de Pascal expliquée dans une courte unité constitue une demande d’entraînement appropriée. Demandez à l’agent de lire la boucle et de décrire, ligne par ligne, ce que contient chaque variable à chaque itération. Il appelle read_file, puis répond dans le chat sans rien écrire, donc Plan only suffit. Vérifiez l’explication en exécutant vous-même l’unité via votre commande de compilation et en suivant la boucle sur papier pour 3 ou 4 lignes. Si l’agent et le programme sont en désaccord, faites confiance au programme et posez à nouveau la question en citant exactement la ligne. Faites de même pour une seconde boucle si la première réponse a aidé, et demandez une explication plus courte lorsqu’un paragraphe semble long, car vous pouvez toujours demander plus de détails sur exactement la ligne qui vous pose problème.
