Der Flaschenhals in der Softwareentwicklung war nie das Programmieren, sondern das Verstehen des Problems. Über den unterschätzten ROI von Verständnis.
Echtes TTD, so wie ich es gelernt habe, erfordert, dass du immer nur die kleinstmögliche Änderung an den Unit-Tests machst. Der erste Test prüft z.B. nur, ob es eine Funktion gibt. Dann schreibst du den Code, der genau diese Anforderung umsetzt, also eine Methode, die nichts macht.
Das ist genauso, wie Robert “Bob” Martin das beschreibt, und worauf sich die Kritik von John Ousterhout ganz explizit bezieht.
Es gibt dann noch eine Beschreibung von Martin Fowler, dass in einem dritten Schritt im Anschluss daran, dass man den Test mit dem neuen Feature zum funktionieren gebracht hat, man Refactoring macht, bei dem man die Struktur des Codes wieder verbessert und etwas aufräumt.
Das ist natürlich besser als nichts! Aber Ousterhout argumentiert, dass sowohl die initiale Struktur des Codes, als auch spätere Änderungen des Codes vorab geplant und bedacht werden müssen, damit die Codebasis langfristig ihre Konsistenz behält. Viele ungerichtete, nicht geplante Änderungen an einer Codebasis führen halt früher oder später zu einem unrettbaren Durcheinander. Genauso wie es bei einer Bibliothek nicht fubktioniert, wenn man Bücher die zurück gegeben werden, einfach irgendwo in ein Regal stellt wo grad Platz ist - sie sind dann nicht mehr zu finden.
Und genau das, die Struktur des Code und seine Invarianten verstehen und diesen so ändern, dass diese implizite Struktur erhalten bleibt, kann die KI halt nicht, auch nicht bei einer mittelkleinen Codebasis. Die Struktur geht dann verloren, auch wenn die Tests vielleicht noch funktionieren.
Und das Problem ist gerade, dass funktionierende Tests eben nicht eine konsistente interne Struktur des Codes sicherstellen. Das können sie halt gar nicht.
Das ist genauso, wie Robert “Bob” Martin das beschreibt, und worauf sich die Kritik von John Ousterhout ganz explizit bezieht.
Es gibt dann noch eine Beschreibung von Martin Fowler, dass in einem dritten Schritt im Anschluss daran, dass man den Test mit dem neuen Feature zum funktionieren gebracht hat, man Refactoring macht, bei dem man die Struktur des Codes wieder verbessert und etwas aufräumt.
Das ist natürlich besser als nichts! Aber Ousterhout argumentiert, dass sowohl die initiale Struktur des Codes, als auch spätere Änderungen des Codes vorab geplant und bedacht werden müssen, damit die Codebasis langfristig ihre Konsistenz behält. Viele ungerichtete, nicht geplante Änderungen an einer Codebasis führen halt früher oder später zu einem unrettbaren Durcheinander. Genauso wie es bei einer Bibliothek nicht fubktioniert, wenn man Bücher die zurück gegeben werden, einfach irgendwo in ein Regal stellt wo grad Platz ist - sie sind dann nicht mehr zu finden.
Und genau das, die Struktur des Code und seine Invarianten verstehen und diesen so ändern, dass diese implizite Struktur erhalten bleibt, kann die KI halt nicht, auch nicht bei einer mittelkleinen Codebasis. Die Struktur geht dann verloren, auch wenn die Tests vielleicht noch funktionieren.
Und das Problem ist gerade, dass funktionierende Tests eben nicht eine konsistente interne Struktur des Codes sicherstellen. Das können sie halt gar nicht.