Ein guter Delphi-Workflow ist überschaubar. Öffnen Sie den Projektordner, fordern Sie eine Änderung an, lesen Sie den Diff und führen Sie Ihren Build-Befehl aus. Arraydeck folgt dieser Schleife mit echten Tools, sodass jeder Schritt eine Karte im Chat hinterlässt, die Sie erweitern und prüfen können – von der ersten Suche bis zum letzten Exit-Code. Hinter einer Zusammenfassung bleibt nichts verborgen. Wenn ein Schritt falsch aussieht, stoppen Sie die Schleife, lehnen die Änderung ab und formulieren die Anfrage neu; die Dateien bleiben unverändert. Dieselben vier Schritte funktionieren bei einer kleinen Unit und bei einem Projekt mit vielen Formularen. Anfänger und langjährige Betreuer können beide mit einer schreibgeschützten Suche starten, da sie keine Datei ändert, aber dennoch zeigt, wie das Projekt strukturiert ist.
Wählen Sie den Ordner, der Ihre .dpr- und .pas-Dateien enthält, als Arbeitsordner des Chats. Die Datei-Tools arbeiten darin, also wählen Sie das Projekt, das Sie ändern möchten, und keinen übergeordneten Ordner mit unzusammenhängender Arbeit. Ein übergeordneter Ordner mit vielen Projekten erschwert die erste Suche und erhöht das Risiko, die falsche Unit zu bearbeiten.
Schreiben Sie eine Aufgabe in einfachen Worten, z. B. den Namen einer Prozedur und was geändert werden soll, und wählen Sie Auto-run, Ask first oder Plan only, bevor Sie sie senden. Kleine Aufgaben ergeben kleine Diffs, die leicht zu lesen sind. Nennen Sie die Unit, wenn Sie sie kennen; der Agent kann sie mit glob finden, aber eine benannte Unit schränkt die erste Suche ein.
Erweitern Sie die edit_file-Karte, lesen Sie jede hinzugefügte und entfernte Zeile und akzeptieren oder lehnen Sie die Änderung ab. Wenn Sie Plan only verwendet haben, lesen Sie zuerst den Plan und wechseln Sie zu Ask first, um ihn Schritt für Schritt auszuführen. Ein sehr langer Diff bedeutet, dass die Aufgabe zu groß war; lehnen Sie sie ab und teilen Sie die Anfrage in zwei kleinere auf.
Lassen Sie Shell Ihren Build-Befehl und Ihren Testbefehl ausführen und lesen Sie den echten Exit-Code auf der Karte. Ein erfolgreicher Build ist ein gutes Zeichen, aber nur Ihre eigenen Tests zeigen, ob das Verhalten noch korrekt ist. Führen Sie den Build vor den Tests aus und halten Sie beide Karten offen, damit ein Fehler auf eine Änderung zurückgeführt werden kann.
.6 EinträgeGreeter.pasgespeichertGreeter.pasgelesenbuild.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 nimmt einen Namen entgegen und gibt einen Gruß zurück. Wenn der Name leer ist, lautet die Antwort Hello, guest, andernfalls wird der Name mit dem Text verbunden, und Result enthält den Rückgabewert der Funktion. Der Schnittstellenteil kündigt die Funktion an, der Implementierungsteil enthält ihren Code – das ist das Layout jeder Unit.
Anfänger, die Delphi lernen, fragen oft, wo ein Wert auf der Festplatte landet. Fragen Sie Arraydeck, wo die Einstellung geschrieben wird. Der Agent führt grep für den Einstellungsnamen über Ihre .pas-Dateien aus, dann öffnet read_file die passende Unit, und die Antwort erscheint im Chat mit Dateinamen und Zeilen. Es ändert sich nichts. Öffnen Sie die Unit in Ihrem eigenen Editor, um zu bestätigen, dass die Prozedur die richtige ist, und notieren Sie den Dateinamen, bevor Sie eine Bearbeitung anfordern. Diese schreibgeschützte Suche ist eine gute erste Anfrage in jedem Projekt, das Sie nicht selbst geschrieben haben. Notieren Sie Datei und Zeile, bevor Sie eine Bearbeitung anfordern, denn ein präziser Dateiname und eine Zeilennummer machen die nächste Anfrage kurz und den nächsten Diff für jeden, der Ihr Projekt nach Ihnen liest, leicht nachvollziehbar.
Fragen Sie nach einem sichereren Handler: Finden Sie die Prozedur, die ein Objekt erstellt, und sorgen Sie dafür, dass es freigegeben wird. Der Agent sucht mit grep, liest die Unit und schlägt die Änderung mit edit_file vor, indem er den Code in try ... finally ... Free einwickelt. In Ask first erscheint der Diff und es wird nichts geschrieben, bis Sie ihn akzeptieren. Dann führt Shell Ihren Build-Befehl aus, und die Karte zeigt den echten Exit-Code. Führen Sie auch Ihre Tests aus. Ein erfolgreicher Build beweist nur die Syntax, nicht, dass das Objekt in jedem Pfad freigegeben wird, also lesen Sie den Diff langsam. Führen Sie die Tests nach dem Akzeptieren des Diffs noch einmal aus und bewahren Sie die alte Version der Unit in Ihrer eigenen Sicherung oder Versionsverwaltung auf, bis Sie sicher sind, dass der Handler jedes Objekt in jedem Zweig freigibt.
So modernisieren Sie Delphi-Apps in kleinen Schritten: Benennen Sie eine unklare Prozedur um, einen Namen nach dem anderen. Fragen Sie den Agenten, ihn in jeder Unit umzubenennen. Er verwendet grep, um jeden Ort aufzulisten, an dem der Name vorkommt, dann ändert edit_file jede Datei, und die Diffs zeigen jede verschobene Zeile. Benennen Sie einmal um. Überprüfen Sie alle Diffs zusammen, denn ein übereinstimmendes Wort in einem String oder Kommentar ist nicht immer ein Aufruf, bauen Sie dann das Projekt und führen Sie Ihre Tests aus, bevor Sie die letzte Datei akzeptieren. Wiederholen Sie die Umbenennung für die nächste Prozedur nur, wenn Build und Tests erfolgreich sind, damit ein Fehler immer in einem kleinen Diff sitzt und nie in einer langen Liste unzusammenhängender Änderungen über viele Units versteckt ist.
Die Logik des Pascal-Dreiecks in einer kurzen Unit ist eine faire Übungsaufgabe. Fragen Sie den Agenten, die Schleife zu lesen und Zeile für Zeile zu beschreiben, was jede Variable in jeder Durchlaufphase enthält. Er ruft read_file auf und antwortet im Chat, ohne etwas zu schreiben, daher reicht Plan only. Überprüfen Sie die Erklärung, indem Sie die Unit selbst über Ihren Build-Befehl ausführen und die Schleife für 3 oder 4 Zeilen auf dem Papier nachvollziehen. Wenn der Agent und das Programm unterschiedliche Ergebnisse liefern, vertrauen Sie dem Programm und stellen Sie die Frage erneut mit der exakten Zeile im Zitat. Machen Sie dasselbe für eine zweite Schleife, wenn die erste Antwort geholfen hat, und bitten Sie um eine kürzere Erklärung, wenn ein Absatz zu lang wirkt, denn Sie können jederzeit mehr Details genau zu der Zeile anfordern, die Sie verwirrt.
