Kent Beck: Kleine Schritte, echte Sicherheit

6 Min. Lesezeit

Er machte Feedback zum Teil der Arbeit

Der Test kommt vor der Ausrede

Kent Beck half, testgetriebene Entwicklung zu einer praktikablen Arbeitsweise zu machen. Ihr bekannter Rhythmus ist einfach: Einen Test für das nächste Verhalten schreiben, sein Scheitern sehen, gerade genug Code für einen erfolgreichen Test schreiben und anschließend die Struktur verbessern, ohne das Verhalten zu ändern. Martin Fowlers Darstellung von TDD führt die Entwicklung dieser Praxis auf Becks Arbeit an Extreme Programming in den späten 1990er-Jahren zurück.

Die Reihenfolge zählt. Ein fehlgeschlagener Test zeigt, dass er das fehlende Verhalten überhaupt erkennen kann. Ein erfolgreicher Test nach einer kleinen Änderung liefert Evidenz für genau diese Änderung. Refactoring bei weiterhin erfolgreichen Tests verbessert das Design, ohne die Vereinbarung stillschweigend umzuschreiben. Keiner dieser Schritte ist Magie. Zusammen machen sie Ungewissheit sichtbar, solange ihre Beseitigung noch günstig ist.

Nehmen wir einen internen Rechnungsprozess. Die Vorgabe lautet: „Keine Rechnung ohne Kundenreferenz versenden.“ Der bequeme Weg wäre, ein Feld im Formular zu ergänzen und drei Wochen später festzustellen, dass der Batch-Import weiterhin Rechnungen ohne Referenz erzeugt. Die bessere erste Frage lässt sich ausführen: Was geschieht, wenn der Import einen Datensatz ohne diese Referenz erhält? Diesen Fall scheitern lassen. Die Regel an der Grenze einbauen, die beide Wege nutzen. Danach Formular und Import gemeinsam prüfen.

Es geht nicht um zusätzliche grüne Häkchen. Es geht darum herauszufinden, ob die Geschäftsregel im System lebt oder nur im Sitzungsprotokoll.

Die Praktiken stützten einander

Becks Laufbahn wird gern zu einer Liste griffiger Begriffe verkürzt: JUnit, TDD, Refactoring, Extreme Programming. In seinem eigenen Rückblick betont er die Zusammenarbeit mit anderen und erklärt, wie sich diese Ideen gegenseitig stützten. JUnit machte Tests in derselben Sprache wie den produktiven Code leicht schreibbar. Tests machten kleine Designänderungen sicherer. Refactoring hielt ein wachsendes System veränderbar. Extreme Programming verband diese technische Disziplin mit Zusammenarbeit und mit Nutzern, die auf funktionierende Software reagieren konnten.

Auch die frühere Arbeit war gemeinschaftlich. In ihrem Aufsatz von 1989 beschrieben Beck und Ward Cunningham CRC-Karten: günstige Karteikarten, mit denen man über Verantwortlichkeiten und Zusammenarbeit von Objekten nachdenken konnte. Menschen konnten die Karten verschieben, ein unfertiges Design hinterfragen und ihre Meinung ohne formelle Übergabe ändern. Cunningham trug dieselbe Vorliebe für gemeinsames Verständnis später in das Wiki und die Metapher technischer Schulden. Seine Geschichte gehört neben die von Beck.

Beck unterschrieb zudem das Manifest für agile Softwareentwicklung. Diese Tatsache ist weniger nützlich als die Arbeitsweisen dahinter. Ein Team kann jede Zeremonie im Kalender abhaken und trotzdem das erste ehrliche technische Feedback bis zur Release-Woche verschieben. Der Kalender wird makellos sein. Das Release vielleicht nicht.

Kleine Schritte ermöglichen Tempo

„Kleine Schritte“ klingt nach einer Bitte, langsamer zu werden. Beck argumentiert für das Gegenteil. In seinem Vergleich von TDD und Kanban macht begrenzte parallele Arbeit Probleme früher sichtbar. Ein fehlgeschlagener Test bündelt die Aufmerksamkeit auf ein benötigtes Verhalten. Ein erfolgreicher Test zeigt, dass der Code diese konkrete Anforderung nun erfüllt. Die vorhandenen Tests prüfen, ob das Neue bereits Funktionierendes beschädigt hat.

Das verändert den Umgang mit schwierigen Anforderungen. Statt sämtliche Regeln für eine künftige Rechnungsplattform auf dem Whiteboard zu entwerfen, kann das Team einen echten Rechnungsfall nehmen, das erwartete Ergebnis ausdrücken, es umsetzen und die Buchhaltung fragen, wo der Fall falsch liegt. Das nächste Beispiel kann eine Ausnahme offenlegen. Das Design ändert sich, solange es noch klein ist.

Hier geraten Unternehmen in Schwierigkeiten, die behaupten, sie würden „nur einen Prozess automatisieren“. Eine Tabelle wird zur Integration. Die Integration wird zum Kundenversprechen. Plötzlich trägt das Unternehmen Verantwortung für Softwareverhalten, auch wenn auf der Budgetzeile niemals „Softwareprodukt“ stand. Schnelles Feedback ist dann eine betriebliche Notwendigkeit, keine Vorliebe der Entwickler.

Eine grüne Testsuite ist kein Freibrief

Auch testgetriebene Entwicklung kann zum Theater werden. Teams testen Implementierungsdetails, blenden die riskante Integration durch Mocks aus und feiern ein grünes Dashboard. Eine Testsuite, die die falsche Rechnungsregel zuverlässig bestätigt, bleibt falsch.

Beck beschrieb selbst eine Entscheidung, einen Fehler ohne automatisierten Test zu beheben und die Änderung auszuliefern, weil allein das Schreiben dieses Tests stundenlange Recherche erfordert hätte. In seinem Bericht hing die Wahl vom Produkt und vom gerade benötigten Feedback ab. Das ist hilfreicher als ein Gebot, jeden denkbaren Fall auf dieselbe Weise zu testen.

Nutzen Sie die kleinste Prüfung, die die nächste wirkliche Frage beantwortet. Manchmal ist das ein Unit-Test. Manchmal ein Integrationstest, ein Gespräch mit der Person, die Rechnungen abgleicht, oder ein vorsichtiger Versuch im Produktivbetrieb. Entscheidend ist, Frage und Evidenz nah beieinander zu halten. Wiederherstellbarkeit bleibt wichtig, wenn Tests die Wirklichkeit nicht vorwegnehmen können.

KI macht die Feedbackschleife wertvoller

Ein KI-Coding-Agent kann in Minuten einen plausiblen Rechnungsprozess erzeugen. Das spart Tipparbeit. Er entscheidet nicht, ob jede Rechnung eine Kundenreferenz braucht, ob alte Importe ausgenommen sind oder wer darüber bestimmen darf. Eine schnellere Umsetzung verteilt eine ungeklärte Entscheidung nur auf mehr Code.

Becks Ansatz hält menschliches Urteil in der Schleife. Ein konkretes Verhalten festlegen. Sehen, dass das aktuelle System daran scheitert. Einen Entwickler oder Agenten eine kleine Änderung machen lassen. Das Ergebnis prüfen. Die Struktur verbessern, solange die Evidenz noch verfügbar ist. Dann die nächste Frage stellen. Dieselbe Disziplin, die große spekulative Entwürfe bremst, verhindert, dass KI-generierter Code aus einer geratenen Anforderung fünf integrierte Vermutungen macht.

Ein Prompt mit „nutze TDD“ ist deshalb noch kein Sicherheitssystem. Tests sind besser als Anweisungen für KI-Coding-Agenten, wenn sie tatsächliche Erwartungen ausdrücken und gegen die Änderung laufen. Jemand muss die Erwartungen auswählen, fehlende Fälle bemerken und das System verständlich halten.

Die Führungsentscheidung

Ein CTO kann verlässliche Releases nicht fordern und gleichzeitig nur sichtbare neue Funktionen belohnen. Müssen Entwickler jeden Test als Verzögerung rechtfertigen, verschieben sie die Prüfungen. Kann das Team sein Design nicht ohne politischen Sonderprozess ändern, schützt es ein schlechtes Design. Das vermeintliche Tempo ist ein Kredit, der beim nächsten Vorfall fällig wird.

Schaffen Sie einen kurzen Weg von der Geschäftsfrage über ein ausführbares Beispiel zur funktionierenden Änderung. Halten Sie die Menschen mit Kenntnis der Ausnahmen während der Umsetzung erreichbar. Lassen Sie Tests bei jeder Änderung laufen und geben Sie Raum, die Struktur zu verbessern, wenn sie Reibung erzeugt. Fragen Sie, was das Team diese Woche gelernt hat, nicht wie viele Tickets es verschoben hat.

Becks Lehre war nie, dass jede Änderung für immer winzig bleiben muss. Ein Team verdient sich die Fähigkeit zu folgenreichen Änderungen, indem es durch häufige Evidenz Vertrauen aufbaut. Dieses Vertrauen entsteht in kleinen, ehrlichen Schritten.

Quellen

• A Career Accounting, Kent Beck
• TDD is Kanban for Code, Kent Beck
• To Test or Not to Test? That’s a Good Question, Kent Beck
• A Laboratory for Teaching Object-Oriented Thinking, Beck und Cunningham
• Test Driven Development, Martin Fowler
• Autoren des Agilen Manifests