Interview mit Alex Lagarde über Mylyn Intent

"Als Entwickler verbringt man die meiste Zeit damit, den Code anderer Leute zu verstehen."

Im Titelthema des brandneuen Eclipse Magazins 3.2013 beschäftigen wir uns ausführlich mit dem Bereich „Eclipse & ALM“. Unter anderem finden Sie Artikel zu EGit/JGit, ALM Toolchain, Testing, Eclipse Lyo, Scrum versus Kanban, Collaboration, Smart Ecosystem. Passend zum Themenfeld ALM präsentieren wir hier auf JAXenter das Interview mit Alex Lagarde (Obeo) über Mylyn Intent. Alex erklärt, wie, wo und warum Dokumentieren in den alltäglichen Arbeitsablauf eines Entwickers aufgenommen werden sollte. Denn schließlich wollen wir nicht Stunden damit vergeuden, den schlecht dokumentierten Code eines Ex-Kollegen zu verstehen, oder?

Alex Lagarde (Obeo)

Eclipse Magazin: Quellcodedokumentation zählt wahrlich nicht zu den beliebtesten Aufgaben eines Entwicklers. Was sind die gängigsten Gründe – oder Ausreden – für eine unterlassene Dokumentation?

Alex Lagarde: Die heutige mangelnde Bereitschaft, Software zu dokumentieren, lässt sich mit der massiven Ablehnung von Unit Testing in den neunziger Jahren vergleichen: Man sieht darin keinen Sinn, weil man viel Zeit aufwendet und der Enduser keinen direkten Nutzen daraus zieht.

Dass Dokumentation oft für nutzlos gehalten wird, hängt meiner Ansicht nach auch mit dem Agilen Manifest zusammen, das „funktionierende Software über umfassende Dokumentation“ stellt. Dabei wird diese Aussage oft missverstanden, wie ich finde: Damit wird einfach nur gesagt, dass die beste Dokumentation der Welt keine Ausrede sein kann, wenn es einem Projekt nicht gelingt, gute Software auszuliefern.

Außerdem macht der Mangel an Tools, um Dokumentation zu durchstöbern oder zu aktualisieren, alle Aufgaben, die mit Dokumentation zu tun haben, langwierig und mühsam. Jeder Entwickler, der schon einmal eine Codedokumentation auf dem neuesten Stand halten musste, wird das genauso sehen: Dokumentation zu aktualisieren ist eine ziemliche Last. Wer nimmt sich schon die Zeit, Hunderte von Seiten Dokumentation zu durchforsten, um genau die Stelle zu finden, an der man Änderungen am Code einträgt? Und hinterher zu prüfen, ob die Dokumentation noch konsistent ist? Niemand! Deswegen ist Dokumentation vermeintlich nutzlos, weil sie nicht die Änderungen wiedergibt, die man an der Software vorgenommen hat. Früher oder später wird ihr niemand mehr trauen und sie kein Mensch mehr lesen. Die Designentscheidungen, die das eigene Team gemacht hat, werden so in Vergessenheit geraten – auch wenn man sehr viel Zeit damit verbracht hat, diese Entscheidungen zu dokumentieren.

Eclipse Magazin: Mit welchen Argumenten würdest du einen Entwickler davon überzeugen, seinen Code auch dann zu dokumentieren, wenn er unter hohem Zeitdruck steht?

Alex Lagarde: Um noch einmal das Beispiel Testing aufzugreifen: Was hat die Leute letztendlich davon überzeugt, dass das Schreiben von Tests genauso wichtig ist wie das Schreiben von Code? In erster Linie der Kontext: Man sollte sich bewusst machen, dass Dokumentation wichtig ist, und man sollte die Probleme verstehen, die eine lückenhafte oder nicht-synchronisierte Dokumentation verursacht.

Zum Glück sind wir nicht die einzigen, die sagen, dass Dokumentation sogar in agilen Prozessen wichtig ist: Kurt Solarte von IBM spricht von der Wichtigkeit Agiler Dokumentation und der „maintenance documentation gap“, Scott Ambler spricht von „Agile/Lean Documentation“ und definiert eine Reihe von Best Practices für das Updaten von Dokumentation, Andreas Rüping hat ein Buch über Agile Dokumentation geschrieben. Die Leute fangen also an, sich für die Verbesserungen – im Prozess und im Tooling – zu interessieren, die jetzt möglich sind und Dokumentationsupdates effizienter machen. Dazu sage ich nur: „Agil“ bedeutet keineswegs „kurzsichtig“. Das erste Ziel eines Teams ist es, Software zu entwickeln, das zweite sollte es sein, sich für das nächste Projekt zu rüsten, „aufs nächste Spiel vorzubereiten“, wie [Alistair] Cockburn sagen würde. Ja, Dokumentation kann innerhalb eines Teams Wissen bewahren und Entwickler davon abhalten, alles neu zu erfinden, wenn einige Mitglieder das Team verlassen und neue hinzukommen. Wenn man über die eigene Tätigkeit als Entwickler nachdenkt, wird man feststellen, dass man die meiste Zeit damit verbringt, den Code anderer Leute zu verstehen. Würde man nicht eine Menge Zeit sparen, wenn man eine aktuelle Dokumentation zum Code zur Hand hätte, den man gerade untersucht? Und warum sollte man sie nicht für die eigene Software schreiben? Wenn Dokumentation eine Zeitverschwendung ist, sind Tests nichts anderes. Sie erfordert zwar Mühe, ist aber eine enorme Zeitersparnis, wenn die Software weiterentwickelt wird.

Nochmal zurück zum Beispiel Testing: Es waren nicht die theoretischen Diskussionen, die die Leute von der Wichtigkeit von Tests überzeugten – es war das aufkommende Tooling (z. B. JUnit), mit dem man zügig Tests schreiben konnte. Und hier kommt Intent ins Spiel.

Kommentare

Schreibe einen Kommentar

Deine E-Mail-Adresse wird nicht veröffentlicht.