Tools 4 faster Code-Reviews
🇬🇧 click here for the english version of this article
Seit Coding Agents den Code schreiben, haben Softwareentwicklungs-Teams ein neues Hauptproblem: den Code-Review-Engpass. Ich meine ausdrücklich Teams, nicht einzelne Entwickler mit ihrer One-Man-Show. Auch andere Teams bei uns berichten davon. (Tendenziell sind die Teams inzwischen ohnehin zu groß – aber das ist ein anderes Thema.)
Der Code-Review-Engpass
Der Engpass hat zwei Ursachen.
Ursache 1: Reviews waren für kleine Änderungen gemacht
In Teams ist es seit Langem üblich, jeden Merge Request (MR) gegenseitig zu reviewen. Früher umfasste ein MR maximal einige zehn bis hundert Zeilen. Diese Menge konnte man in etwa einer Stunde prüfen: Man las jede Zeile und suchte nach Fehlern und anderen Unschönheiten.
Ursache 2: Agenten erzeugen Merge Requests mit tausenden Zeilen
Heute haben Merge Requests oft 1.000 oder 5.000 Zeilen. Mit dem alten Prinzip funktioniert das nicht mehr. Kein Entwickler kann sich tagelang konzentrieren und jede einzelne Codezeile auf Fehler prüfen.
Lösungsansatz: Review durch Coding Agents
Die beste Lösung, die ich bisher kannte: Der Coding Agent macht das Code-Review selbst. Dazu erstellt man Skills. Diese beschreiben genau, welche Arten von Fehlern der Agent an welchen Stellen suchen soll.
Das funktioniert eigentlich ganz gut. Es bedeutet aber: Der Entwickler schaut sich den Code gar nicht mehr selbst an. Er startet nur noch den Review-Agenten und übernimmt dessen Ergebnis.
Viele Entwickler fühlen sich damit noch sehr unwohl. Sie wollen die Verantwortung auf keinen Fall zu hundert Prozent an die Coding Agents abgeben.
Und solange der Auftraggeber vom Team verlangt “Verantwortung” für die “Code Ownership” zu übernehmen, sollten die Teams das vielicht auch (noch) nicht ganz an die Coding Agents delegierten, egal wie gut deren “Review” -Skills sind.
Die Idee von Victor Rentea: Änderungen verdichten und visualisieren
Victor Rentea ist sicher einer der besten Speaker (und Trainer?) in der Java-Community. Er hat viele sehr gute und unterhaltsame YouTube-Videos zu allen möglichen Software-Themen gemacht hauptsächlich im Java-Umfeld. Inzwischen hat auch er den Fokus auf Java aufgegeben und spricht zu Recht vor allem über KI gestütze SWEntwicklung – und die ist bekanntlich eher sprachunabhängig.
In einem neuen Video stellt er eine Idee vor, die ich extrem spannend finde:
Verdichte die Code-Änderungen und visualisiere sie so, dass du als Entwickler auch große Änderungen in kurzer Zeit überblicken kannst. Dann kannst du selbst entscheiden, ob die Änderungen okay sind oder nicht.
Dazu hat er eine ganze Reihe von Tools gebaut. Im folgenden Video stellt er sie vor:
Er geht recht schnell über die einzelnen Ideen hinweg. Ich schaue mir das Video darum gerade zum wiederholten Mal an, um alle Details zu verstehen.
Passend zum Video gibt es eine Demo-Seite. Dort sieht man das Konzept live an einem beispielhaften Merge Request:
Mein erster Versuch: das API-Diff
Um die Ideen wirklich zu verstehen, muss ich konkret damit arbeiten. Das Konzept besteht aus sieben oder acht Grundpfeilern. Ich habe mir gestern einen davon herausgegriffen, in das aktuelle Projekt meines Teams versuchsweise eingebaut und ein bisschen damit experimentiert: das API-Diff.
- Demo des API-Diffs: https://victorrentea.github.io/human-review/demo/review.html#api
Ich muss sagen: Ich bin begeistert!
Ausblick: Bleeding Edge
Bei den anderen Grundideen sagt Victor Rentea selbst, dass manches noch unausgegoren ist. Er ruft die Zuhörer auf, an der Weiterentwicklung der Tools mitzuarbeiten. Aus meiner Sicht ist das wirklich Bleeding Edge – und genau deshalb lohnt es sich, jetzt damit anzufangen.