Rot-Grün-Wut?

Ich habe stets festgestellt, dass „Red-Green-Refactor“ eine der bewährten Methoden ist, die aus dem Extreme Programming und der testgetriebenen Entwicklung übernommen wurden. Red Das bedeutet, dass Sie einen Test schreiben, der nachweist, dass das von Ihnen gewünschte Verhalten nicht vorliegt, d. h., der Test schlägt fehl und wird daher rot angezeigt. Green bedeutet, dass der Test bestanden ist; Sie wissen also, dass Sie fertig sind, wenn der Test, der zuvor fehlgeschlagen ist, nun erfolgreich ist.

In dieser Hinsicht hat sich nichts geändert. Selbst wenn Sie in rasendem Tempo programmieren, können Sie weiterhin testgetriebene Entwicklung betreiben. Das funktioniert tatsächlich gut – sowohl für KI als auch für Menschen. Bitten Sie die KI zunächst um einen Plan; anstatt dann nach einer Implementierung zu fragen, könnten Sie nach einem fehlgeschlagenen Test fragen, der zeigt, dass das erforderliche Verhalten fehlt. Als Nächstes bitten Sie um eine Implementierung, die den Test bestehen lässt, und schon sind wir am Ziel. Test erfolgreich -> ausliefern.

Ich kann mir vorstellen, dass ein Team, das auf diese Weise arbeitet, in sehr kurzer Zeit eine Menge Software produzieren kann. Wenn KI uns alle zu 10X-Entwicklern macht, dann würde ein Team aus vier Entwicklern in einem Monat 40 Monate Software produzieren, nicht wahr? Wenn man mal ganz grob im Kopf nachrechnet, käme man vielleicht sehr schnell auf 20.000 Zeilen Code. Vielleicht in einem Monat oder einer Woche? Die Zahlen spielen eigentlich keine Rolle.

Denken Sie einmal an die Projekte zurück, an denen Sie in der Vergangenheit gearbeitet haben. Was geschah normalerweise, nachdem die ersten paar tausend Zeilen Code geschrieben waren? Zu diesem Zeitpunkt sind möglicherweise bereits zwei oder drei Monate vergangen, in denen Sie im Schneckentempo ohne KI programmiert haben. In diesen zwei Monaten haben Sie gelernt, worum es bei dem Problem, das Sie lösen, wirklich geht, und Sie stellen vielleicht fest, dass sich einige der Entscheidungen, die Sie zu Beginn getroffen haben, nun als nachteilig erweisen. Möglicherweise fehlt es an Testabdeckung (Demos, Termine – „das korrigieren wir später“), die Struktur der Codebasis muss möglicherweise überarbeitet werden, und Sonar mahnt Sie eindringlich, all die Code-Duplikate und Ähnliches zu beheben.

An dieser Stelle kommt die Refaktorisierung ins Spiel. Die entscheidende dritte Praxis im Ansatz „Rot, Grün, Refaktorisieren“. Wenn ein Teil der Software funktioniert, verbessern Sie ihn, indem Sie die von Ihnen erstellte Lösung im Kontext des bereits vorhandenen Codes betrachten und Änderungen vornehmen. Auf der Mikroebene ändern Sie den soeben hinzugefügten Code, um ihn zu optimieren und ihn besser und übersichtlicher zu gestalten. KI ist hierfür äußerst nützlich: Setzen Sie Ihre Claude-Code-Sitzung zurück und bitten Sie das System, die Änderungen im aktuellen Zweig zu kommentieren und Verbesserungen vorzunehmen. Das sollte die kleinen Fehler, Duplikate, Inkonsistenzen und Ineffizienzen beseitigen, die sich häufig in jede Codebasis einschleichen.

Es gibt jedoch auch die Makroebene. Wenn Sie genügend kleine Änderungen vornehmen, muss die Gesamtstruktur irgendwann grundlegend überarbeitet werden, um neuen Entwicklungen und Erkenntnissen Rechnung zu tragen. Bei KI-generiertem Code verhält es sich nicht anders: Viele kleine Änderungen führen letztendlich zu einem großen Durcheinander – nur dass dies schneller geschieht, da wir nun schneller mehr Code erzeugen können. An diesem Punkt ist eine Refaktorisierung in größerem Umfang erforderlich: Man muss die Architektur betrachten, entscheiden, was geändert werden muss, um neue Funktionen zu integrieren, und dann den Code anpassen, um ihn zukunftssicher zu machen.

Diese Refactorings sind zeitaufwendig, insbesondere wenn Sie Ihren Code nicht als „Black Box“ betrachten, sondern stattdessen Verantwortung für das übernehmen möchten, was generiert wurde.

Ich bin mir noch immer nicht sicher, was die beste Lösung für dieses Problem ist. Derzeit führen wir in dem Team, dem ich angehöre, lediglich Code-Reviews für jeden Pull-Request durch. Wir können den Pull-Request schneller als zuvor erstellen, und dann verlangsamen wir den Prozess gewissermaßen; wir schauen uns an, was wir haben, und verbessern den gesamten Code, nicht nur das, was uns gerade spontan eingefallen ist. Oder wir verfassen eine neue Story, um das Ergebnis zu optimieren. Oder wir erkennen, wo wir in naher Zukunft möglicherweise Verbesserungen vornehmen müssen.

Führen Sie eine Refaktorisierung im großen Maßstab durch.

Und was diese Sonar-Warnungen angeht: Geben Sie sie einfach der KI und sehen Sie zu, wie sie verschwinden. Wie von Zauberhand.

P.S.: Beim Verfassen dieses Beitrags wurde keine KI verletzt.