Factory in der Praxis: Code-Reviews, Tests und Refactoring

👁 113 Aufrufe

Factory bringt Teams am meisten, bei denen wichtige Entwicklungsarbeit in der Warteschlange liegt, weil immer etwas Dringenderes ansteht: Code-Reviews, Tests, Bugfixes, Refactoring von altem Code. Wir haben die Anwendungsfälle zusammengestellt, bei denen Droid-Agenten dem Team die meiste Arbeit abnehmen.

Wie Sie Droid installieren und Code-Reviews einrichten, haben wir im Factory-Tutorial beschrieben.

Wie Sie im Team starten

Der sicherste erste Schritt ist das automatische Review von Pull Requests. Es ändert keinen Code, sondern fügt nur Kommentare hinzu, sodass das Team die Qualität der Agentenarbeit ohne Risiko bewerten kann. Nach zwei Wochen sehen Sie, ob die Kommentare zielführend sind. Der zweite Schritt sind kleine Bugs aus dem Backlog, die einzeln beauftragt und wie Änderungen eines Kollegen geprüft werden. Erst danach größere Aufgaben im Spezifikationsmodus.

Wichtig ist, dass das gesamte Team die Regeln kennt: Wer beauftragt den Agenten, wer prüft seine Änderungen und welche Code-Bereiche darf der Agent nicht ohne Zustimmung anfassen.

Automatisches Review jedes Pull Requests

Die einfachste Implementierung und oft die spürbarste. Droid prüft jeden Pull Request, bevor ihn ein Mensch sieht, und kommentiert konkrete Zeilen. Er konzentriert sich auf Fehler, nicht auf Stil. Der menschliche Reviewer erhält eine Änderung, aus der offensichtliche Probleme bereits herausgefiltert wurden, und kann sich auf Logik und Architektur konzentrieren.

Review vor dem Einreichen

Ein Befehl zum Review lokaler Änderungen ermöglicht es Entwicklern, Code zu prüfen, bevor ihn jemand sieht. Weniger Korrekturschleifen im Pull Request bedeuten schnelleres Merging und weniger Kontextwechsel zwischen Aufgaben.

Behebung kleiner Bugs

In jedem Projekt gibt es eine Liste kleiner Bugs, die niemand Zeit hat zu beheben. Sie beschreiben den Bug, Droid findet die Ursache und schlägt eine Korrektur vor, die Sie wie jede andere Änderung prüfen. Das Backlog schrumpft, ohne Zeit von neuen Features abzuziehen.

Tests für Code ohne Tests

Ältere Module haben oft keine Tests, sodass jede Änderung riskant ist. Droid schreibt Tests für bestehenden Code, und Sie prüfen, ob sie das Wichtige testen. Nach einigen Wochen sind Änderungen an altem Code keine Lotterie mehr.

Migrationen und größere Änderungen mit Plan

Bibliotheks-Updates, Änderungen der Datenbankstruktur, Umstellung auf eine neue Sprachversion. Der Spezifikationsmodus analysiert zunächst das Projekt und präsentiert einen Plan, den das Team vor der ersten Änderung genehmigt. Die Factory-Dokumentation empfiehlt diesen Modus speziell für Migrationen und sicherheitskritische Änderungen.

Aufgaben in Skripten und CI

Wenn eine Arbeit mit Droid sich bewährt, können Sie sie ohne interaktives Fenster ausführen, zum Beispiel in der CI-Pipeline. Wiederholbare Aufgaben wie Reviews oder die Generierung von Änderungsberichten laufen automatisch bei jedem Deployment.

Arbeit im bevorzugten Editor

Droid funktioniert in VS Code, Cursor, Windsurf, JetBrains-Editoren und Zed. Das Team muss keine Tools wechseln, und in VS Code sieht der Agent die geöffnete Datei und Fehler aus dem Editor.

Beispiel: Eine Woche mit Technical Debt

Ein Team von vier Entwicklern hat dreißig kleine Bugs auf der Liste und ein Zahlungsmodul ohne Tests. Am Montag aktivieren sie automatische Pull-Request-Reviews. Jeder Entwickler beauftragt Droid täglich mit zwei kleinen Bugs und prüft die Korrekturen. Am Mittwoch planen sie im Spezifikationsmodus Tests für das Zahlungsmodul und mergen sie am Freitag nach Review. Die Bug-Liste sinkt um die Hälfte, ohne Arbeit an neuen Features abzusagen.

Entscheidend ist, dass das Team keine Arbeit an neuen Features abgesagt hat. Der Agent übernahm Aufgaben, die ohnehin in der Warteschlange lagen, und die Entwickler kümmerten sich um das Review seiner Änderungen, was weniger Zeit kostet als selbstständiges Schreiben von Korrekturen. Dabei lohnt es sich, eine Regel einzuhalten: Jede Änderung des Agenten hat einen Verantwortlichen im Team, der sie geprüft und genehmigt hat. So verliert niemand den Überblick darüber, was sich im Code geändert hat.

Worauf Sie achten sollten

• Prüfen Sie jede Änderung des Agenten wie die Änderung eines Menschen.
• Automatisches Review ersetzt keinen Reviewer bei Architekturentscheidungen.
• Erhöhen Sie die Selbstständigkeit des Agenten schrittweise, wenn Sie wissen, wie er mit dem Projekt zurechtkommt.

Wie Sie prüfen, ob es sich lohnt

Messen Sie, was dem Team wirklich wehtut. Zeit vom Öffnen des Pull Requests bis zum Merge, denn automatisches Review sollte sie verkürzen. Anzahl der Bugs im Backlog zu Beginn und nach einem Monat. Test-Coverage in Modulen, die keine Tests hatten.

Wenn sich nach einem Monat keine dieser Zahlen bewegt hat, liegt das Problem meist nicht am Tool, sondern daran, dass niemand Zeit hat, die Änderungen des Agenten zu prüfen. Dann lohnt es sich, eine feste Zeit in der Woche für das Review dessen festzulegen, was er vorbereitet hat.

Es lohnt sich auch zu notieren, welche Aufgabentypen der Agent am besten erledigt. Nach einem Monat weiß das Team, was es sofort beauftragen kann und was es besser selbst macht, und verschwendet keine Zeit mehr mit Versuchen, dem Agenten Aufgaben zu geben, die Wissen außerhalb des Codes erfordern, zum Beispiel Absprachen mit dem Kunden.

// weiterlesenIdeogram 4.5 für Social Media & Druck: 10 Praxis-PromptsAnleitungenWelche KI für was? 50 Antworten mit Tests und PreisenAnleitungenCustomer.io in der Praxis: Onboarding, Warenkörbe, ReaktivierungAnleitungen