Documentation Driven Development

Ich hatte diese Idee über Documentation Driven Development für meine Arbeit schon vor der Zeit von LLMs. Wie in Clean Code bin ich der Meinung, dass Code hauptsächlich gelesen und verstanden werden muss, um erweitert werden zu können. Dabei geht es hauptsächlich um was passiert und warum. Und das sehe ich als gleichwertig wichtig wie der Code selbst. Diese Schicht in natürlicher Sprache macht es nochmal schneller sich im Code zurechtzufinden und schnell zu verstehen, was dieser Code tut und was die erwarteten Eingaben und Ausgaben sind, bevor man überhaupt den Code im Detail anschaut.

Docstrings: Code in menschlicher Sprache

Ich meine damit Docstrings. Ich bin ein großer Fan von Docstrings in Funktionen, Klassen und Datei-Headern. Für mich machen sie aus Code menschliche Sprache.

Documentation Driven Development bedeutet, dass Dokumentation ein Hauptartefakt neben dem Code ist, kein nachträglicher Gedanke. Du schreibst sie davor und danach. Es sind nicht nur Kommentare für die Maschine, es ist die Erklärung für den Menschen.

Der KI-Wandel: Context Engineering

Dann hat KI das zu einer viel größeren Sache gemacht. Denn jetzt, für Coding-Assistance, brauchst du Context Engineering. Also schreibe ich nicht mehr nur Docstrings, um meine Absicht festzuhalten, sondern ich halte einen ganzen docs/-Ordner für alles, was über ein Projekt dokumentiert werden muss und es verdient.

Ich nenne das Documentation Driven Development, weil es zeigt, wie alles funktioniert, was die Ideen und Entscheidungen waren. Das macht Code viel einfacher zu verstehen als nur die Zeilen Code.

Warum es sich auszahlt

Als ich es am Anfang meiner Karriere manuell gemacht habe, hat es mir gezeigt, wie gut eine Investition das ist. Wenn du Code teilst und alles schon erklärt ist, oder du nach ein paar Monaten in eine Codebase zurückkommst und direkt wieder einsteigen kannst, weil alles, was du wissen musst, bevor du den Code liest, schon da ist.

Die Zukunft

Das ist die Idee. Und vielleicht wird Code in der Zukunft nicht mehr der wichtige Teil sein. Vielleicht sind die Docs die eigentliche Arbeit eines Software Engineers, und der Code begleitet sie nur noch.

Willst du sehen, wie ich meinen docs/-Ordner tatsächlich organisiere? Das ist der nächste Post.