TDD vs. gute Design-/Architekturprinzipien

Vor einiger Zeit gab es eine interessante Debatte zwischen Bob Martin, dem Mitbegründer des Agilen Manifests, und dem renommierten Jim Coplien über die Bedeutung guter Designprinzipien in der TDD-basierten Entwicklung. Jim hatte sehr nachdenklich stimmende Ansichten darüber, was die Leute im Namen von TDD tun und wann es zu etwas führt, bei dem es einfach unmöglich ist, irgendeine Art von Refactoring vorzunehmen, da es keine solide Design-/Architekturbasis gibt. Das führt zu folgenden Fragen:

• Ist es bei der Anwendung von TDD und Scrum wirklich möglich, sich auf ein gutes Design zu konzentrieren, wenn wir uns nur auf die priorisierte Liste der Anforderungen konzentrieren und ihre Wechselwirkungen mit anderen User Stories gar nicht erst sehen?
• Ist es wirklich möglich, eine gute Architektur/ein gutes Design zu erstellen, ohne ein großes Bild in Form von logischen Diagrammen, Klassendiagrammen (lesen Sie UML) und Einsatzdiagrammen zu haben? Vielleicht ist es bei kleinen Projekten möglich, bei denen die Komplexität der Geschäftslogik nicht allzu hoch ist. Aber die Frage ist eher für große Projekte (1-2 Millionen LOC) relevant.

Es gab einige interessante Nachfragen zu diesem Thema von verschiedenen Personen in Xebia. Ich dachte, es wäre eine gute Idee, all diese Gedanken in diesem Blog zusammenzufassen. Lars hat auf die erste Frage geantwortet:

Ja, natürlich. Warum glauben Sie, dass Sie sich nur auf die nach Prioritäten geordnete Liste der Anforderungen konzentrieren müssen? Als professioneller Programmierer sollten Sie immer vorausschauend denken (allerdings nicht zu weit voraus...), das große Ganze im Auge behalten und die Kohärenz zwischen den User Stories erkennen. Wenn Ihnen das nicht klar ist, fragen Sie Ihre Teamkollegen oder den PO. In TDD oder Scrum steht nichts von "Vergessen Sie das große Ganze". Wenn Sie TDD praktizieren, bedeutet das meiner Meinung nach nicht, dass Sie überhaupt kein Design machen.

Es gab eine interessante Antwort von Viktor Grgic:

Die Kunden sind gerade dabei zu erkennen, wie wichtig eine gute Architektur und die Rolle eines Architekten sind. Bei den meisten Projekten, an denen ich gearbeitet habe, wurde die Architektur von den Entwicklern als sekundäre Aufgabe erledigt und es war immer ein Chaos. Auch wenn sie nicht mit Scrum arbeiteten, glaube ich nicht, dass Scrum dieses Problem lösen würde. Den Entwicklern zu sagen, "behalten Sie das große Ganze im Auge", löst das Problem nicht. Meiner Erfahrung nach führt das nur zu ineffizienten Diskussionen, weil es an Wissen über alle möglichen Dinge mangelt (Geschäfts- und IT-Strategie, Standardisierung, Politik usw.). In den Diskussionen geht es darum, welche Technologie sie für die beste halten, und sie sehen z.B. kaum die Komplexität der widersprüchlichen Anforderungen. Übrigens ist Architektur in diesem Zusammenhang nicht nur technisch. All dies bedeutet nicht, dass Programmierer nicht an Design und Architektur beteiligt sein sollten. Im Gegenteil, so viel wie möglich. Außerdem ist die Definition der Architektur ein sehr dynamischer Prozess und passt gut zu den Prinzipien von Scrum und Agile.

Und es gab ziemlich gute Gedanken über die Bedeutung der Dokumentation (UML, Multimedia, Whiteboards) in der Diskussion. Ich hatte einige Gespräche mit Leuten, die mit der agilen Methodik arbeiten, und sie machten den Eindruck, als ob sie UML überhaupt nicht mögen würden. Ich konnte nicht verstehen, warum. Ich bin nach wie vor der Meinung, dass es ohne ein gutes Verständnis von Design und Architektur einfach nicht möglich ist, eine gute Anwendung von unten nach oben (Mikro-Makro) zu entwickeln. Im Wesentlichen bedeutet dies, dass Sie ohne ein Verständnis der Dynamik zwischen den Klassen keine gute Anwendung schreiben können. Es macht also keinen Sinn, zuerst einen Testfall zu schreiben und dann weiterzuentwickeln, ohne den gesamten Kontext zu verstehen. Erik Pragt schrieb:

Ich glaube nicht, dass Menschen, die mit Agile arbeiten, UML hassen. Zumindest ich nicht. Was ich allerdings nicht mag, ist die Erstellung von Upfront-Sequenzdiagrammen, die ebenfalls Teil der UML ist (hauptsächlich aus dem Grund, dass ich mir in der Regel alle möglichen unnötigen Abstraktionen ausdenke, die einfach nur toll aussehen, aber überhaupt nicht benötigt werden). Upfront- und Afterfront-Klassendiagramme sind sehr hilfreich, um das System und die Beziehungen im Domänenmodell zu verstehen, und auch ein Deployment- oder eine andere Art von Übersichtsdiagramm hilft sehr beim Verständnis des Systems.

Jan Vermeir hatte eine interessante Meinung zu Sequenzdiagrammen:

In der Kategorie "Design, das Ihnen beim Denken hilft" verwende ich auch Diagramme, um den Code bei Audits zu verstehen. Sequenzdiagramme sind hier sehr hilfreich, da sie mir einen schnellen Überblick darüber verschaffen, wie eine Komponente eine andere verwendet, was ich sehr nützlich finde. Wenn Sie Diagramme für die Dokumentation erstellen möchten, ist UML meiner Meinung nach der Standard. Für Skizzen auf weißen Tafeln können Sie aber genauso gut Rechtecke zeichnen.

Gedanken von Serge über gute Dokumentation:

Seit einiger Zeit schätze ich "gute Dokumentation" auf eine andere Art und Weise. Ich glaube nicht, dass UML besser oder schlechter ist als Skizzen. Mit Robert vL habe ich bei unserer Arbeit viel mit Multimedia zu tun gehabt. Meine Antwort auf die Frage nach "guter Dokumentation" ist also nicht UML oder Skizzen, sondern die Verwendung von Multimedia für die Geschichten, das Schreiben und die Diagramme als Referenz. Ich habe festgestellt, dass dies sehr viel effektiver ist als das beste Dokument, das je geschrieben wurde.

Bitte hinterlassen Sie uns Ihre Kommentare zu diesem Thema und was Sie allgemein über Agilität in der Praxis denken.