Kategorien
Documentation Driven Development
Vielleicht hat ja der eine oder andere schon mal von dieser Art zu entwickeln gehört. Eigentlich bedeutet Documenation Driven Development (DDD) nur, dass man die Dokumentation von dem, was man entwickeln will vorher verfasst. Genau wie beim Test Driven Development (TDD) wird man gezwungen sich bereits vor der ersten Zeile Code Gedanken zu seiner Lösung zu machen und was vielleicht noch wichtiger ist man macht sich Gedanken über das Problem, das gestellt wurde. Wie oft habe ich schon Kollegen dabei erwischt, wie sie bereits eine geraume Zeit programmiert haben, um dann zu merken, dass der Lösungsansatz, den sie fahren wollten gar nicht klappen kann.
Vorteile von DDD:
- Methoden werden nicht zu komplex. Wenn etwas nicht erklären kann, dann ist die Chance groß, dass etwas an dieser Funktion nicht stimmt.
- Dokumentationsqualität. Arbeitet man mit DDD, so hat man natürlich zu jeder Zeit eine hervorragende Dokumentation vorzuweisen
- Code Reviews können bereits auf der Code Dokumentation ausgeführt werden. Fehler können also im Team viel früher gefunden werden und somit ist die Behebung an der günstigen Stelle möglich.
- Featuritis. Bei der Verwendung von DDD wird man sich zweimal überlegen, ob man ein Feature implementiert, nur weil es einem gerade einfach erscheint.
Nachteile von DDD:
- Zeitraubend. Viele Entwickler werden diese Art zu entwickeln als sehr zeitintensiv ansehen, da man viele Zeilen Doku schreiben muss, bevor auch nur die erste Zeile Programmcode entwickelt wird.
Natürlich muss ich noch dazusagen, dass ich nie wirklich mit dieser Technik gearbeitet habe. Trotzdem finde ich den Ansatz sehr interessant und werde vielleicht in Zukunft mal ein wenig rumexperimentieren und die Stärken und Schwächen genauer untersuchen. Als Ersatz für TDD würde ich aber DDD nie nehmen, da ich denke, dass mit dem Test First Ansatz nicht nur der Code strukturierter wird, sondern auch die Fehlerrate niedriger ist. Eine Kombination aus beidem kann dagegen einen Versuch wert sein.
