• Völlige Neuentwicklung

Bei absoluter Design / Architekturfreiheit macht es Sinn, vor der Implementierung alternative Architekturen zu erarbeiten und deren Vor- und Nachteile- zu diskutieren. Vielleicht kann ich ArchitekturSpikes? dazu sagen. Als Ergebnis habe ich dann eine geeignete Architektur in den Händen, bei XP gibt's hier bereits ausführ- und test-barer Code.

• Frameworks

Frameworks sind quasi die Inkarnation der TechnologieAufVorrat?. Hier treten eine Reihe von Problemen auf: Woher bekomme ich die Anforderungen? Wie weiß ich, welchen Komponenten ich im Rahmen von Refactorings ändern oder löschen darf etc.?

Andererseits kann ein Framework auch als Krone jeglicher Refactoring Bemühungen verstanden werden. Jeder Code, den ich über mehrere Projekte wiederholt benötige, ziehe ich in ein Framework ... -- mj

Es wird behauptet, dass bestimmte Projekttypen (z.B. Framework-Entwicklung), die eine hohe Stabilität der Schnittstellen erfordern, für XP nicht geeignet wären. Ist das richtig?

Ja, ich denke das gilt für alle Projekte mit hoher Modul- / Componenten-tiefe. Je mehr mitarbeitende Teams von einer Schnittstellenänderung betroffen sind, desto teurer werden die Auswirkungen der Änderung. -- mj

Aber stellt denn XP nicht gerade sicher (durch den Wert Einfachheit und die Praktiken EinfachesDesign und GnadenlosesRefaktorisieren), daß Änderungen an einem Framework keinen grossen Schaden bei den Teams, die es benutzen, entstehen läßt? Ich habe die Erfahrung gemacht, daß testgetrieben entwickelte Schnittstellen sehr stabil sind und eine nachträgliche Änderung recht einfach und günstig sowohl von den Framework-Entwicklern wie -Nutzern durchgeführt bzw. verkraftet werden kann. --bs

Die Nutzer-Teams interessieren sich i.A. nur für die Schnittstelle ... Framework-interne Einfachheit hilft hier nicht. Auch Tests nutzen nur, solange die zu testende Schnittstelle sich nicht ändert. Das testgetriebene Design macht Schnittstellen aber tatsächlich stabiler, vor Veröffentlichung wurde die Schnittstelle zumindest einmal benutzt :-). Allerdings ist dieser Effekt nicht signifikant.

Zusammenfassend bin ich zu der Meinung gekommen, dass man Entscheidungen auf spätere Zeitpunkte zu verschieben nur sehr vorsichtig und geziehlt einsetzen sollte. Schnittstellenstabilität ist immer noch ein Ziel, das ich mit viel Analyse- & Designvorleistung zu erreichen versuche.

An vielen anderen Stellen bewährt sich der XP Ansatz aber :-) -- mj

Da widerspreche ich aber in mehreren Punkten: Framework-interne Einfachheit hilft besonders und gerade den Anwendern, da sie letztendlich den Nutzen daraus ziehen. Und auch die Schnittstelle wird einfach gehalten und somit leicht benutzbar. Wenn sich die Schnittstelle ändert, ändern sich auch die Tests, somit nutzen Tests die gesamte Lebenszeit des Frameworks über. Und was die Veröffentlichung angeht: KurzeReleaseZyklen stellen sicher, daß das Framework schnell einsetzbar und durch Feedback immer weiter bzgl. der Benutzbarkeit und Alltagstauglichkeit optimiert wird. Ich sehe diese Punkte als sehr signifikant. Warum nun genau meinst Du, daß XP bei Frameworkentwicklung nicht einsetzbar sei? --bs

Okay, Framework-interne Einfachheit hilft ... als Framework Anwender schau ich mir die Implementierung nicht an ... solange alles funktioniert. Was der Anwender sich anschauen muss, sind Philosophie und die bereitgestellten Mechanismen, die sollten möglichst einfach, orthogonal und logisch sein. Eine einfache Implementierung hat nur Einfluss auf die höhere Qualität & Wartbarkeit, also nur indirekt etwas mit dem Anwender zu tun.

Andererseits scheint mir, dass eine einfache Implementierung auch zu einer einfachen Schnittstelle führt. -- ip

Ich stimm Dir da zu, allerdings ist eine einfache und orthogonale Schnittstelle für mich eine selbstverständliche Vorraussetzung. Allerdings kann hinter einer schönen Schnittstelle auch völliger Murks implementiert sein (ich hab gerade so ein Fall, Refactoring auf einem Pascal-Ein Modul-15 Methoden-10T Zeilen-Moloch, da fange ich mit den Schnittstellen an ...) -- mj

Wenn sich die Schnittstelle ändert, ändern sich auch die Tests - was helfen mir die Tests dann für die Schnittstellenstabilität ?

KurzeReleaseZyklen - Schnell einsetzbar ist bei einem FrameWork? nicht unbedingt die Priorität. Vielmehr muss mit den Benutzern, die sich in die Ideen eines Frameworks eingearbeitet haben pfleglich umgegangen werden. Kein Benutzer macht n (mit beliebig kleinem n) Signaturänderungen pro Jahr mit! Für eine Veröffentlichung ist also eine gewisse Reife des Frameworks notwendig um die geistigen Investitionen der Nutzer zu erhalten.

Trotzdem ist es sehr wichtig, möglichst früh Feedback von realen Anwendern über die Benutzbarkeit des Frameworks zu erhalten - auch und gerade um Probleme möglichst früh beheben zu können und später notwendige Änderungen zu minimieren. Nach meiner Erfahrung sollte sich eigentlich fast immer eine Benutzergruppe finden lassen, die im frühen Kontakt mit der Schnittstelle mehr Vor- als Nachteile sieht.

Jain, einerseits hast du recht, andererseits nicht. Ich weiss nicht, ob du die OpenSource Diskusionen mitverfolgt hast, aber ein Ergebniss war, dass man mit der Ressource Tester und freiwillige Nutzer sorgsam umgehen muss. Der Deal ist, ich biete Funktionalität und Stabilität der Anwenderkreis bietet Feedback und evtl Mitarbeit. So verhält es sich meiner Erfahrung nach auch im kommerziellen Umfeld, nur kann ich mir mit Geld in gewissem Mass Aufmerksamkeit kaufen. Desshalb ist es eine Gratwanderung wieviel solche Änderungen ich machen kann, ohne den Goodwill der Nutzer zu verlieren.

Das Ergebniss dieser Gratwanderung ist übrigens der Grund wesshalb ich von grüne Wiese Frameworks nichts halte. Frameworks sollten nach meinem Dafürhalten aus dem täglichen Gebrauch extrahiert / refactored werden, nur dann ist der Code schon oft eingesetzt und getestet worden, bevor er in einem Framework fixiert wird. -- mj

XP sagt, späte Entscheidungen werden nicht exponential teurer, also sollte eine Entscheidung möglichst spät fallen, um jetzt nur das Nötigste zu tun. Bei Frameworks muss die Entscheidung über die Schnittstelle aber früh fallen und wenn eine Neuentscheidung nötig ist, wird das sehr teuer. -- mj

Das Argument kann ich nur begrenzt nachvollziehen. Durch die starke Entkopplung des Designs, das Konzentrieren auf die wichtigsten Funktionalitäten und die frühe Konfrontation mit den Benutzern sollte sich der Kern eines Frameworks doch eigentlich gerade *durch* die XP-Praktiken schnell stabilisieren und dennoch leicht erweiterbar sein. Umso länger es dauert, bis ein Feature tatsächlich in der Implementierung genutzt wird, umso wahrscheinlicher wird es doch gerade, dass später Korrekturen vorgenommen werden müssen, oder?

Wo liefert XP eine starke Entkopplung vom Design ? Ich dachte das Design passiert natlos beim Entwickeln ??

Ich entkopple das Design und setze zur Implementierung natürlich XP ein (wenn irgend möglich). Wenn die Schnittstelle wackelt haben die Benutzer mehr Arbeit und ich muss mir Ihren Goodwill dabei irgendwie erhalten -- das sind die Kosten (nicht immer nur Geld aber umrechenbar ?).

Kannst Du ein Beispiel dafür geben, wie eine "JustInTime" getroffene Entscheidung über die Schnittstelle in einem konsequent geführten XP-Projekt sehr teuer werden würde? -- ip

Ja, aber dann müsste ich dich danach umbringen :-))

Im Ernst, das ist ein Bauchgefühl, das ich aber begründen kann.

Wenn ein Framework extern genutzt wird ist das kein XP-Projekt mehr. Die Hersteller und Benutzer eines Frameworks sitzen und entwickeln getrennt. Ein Refactoring beim Framework (beim Hersteller) kann nicht mehr alle Codeinstanzen (beim Benutzer) mit umfassen. Infolgedessen sind verschiedene Frameworkversionen im Einsatz und müssen seperat gewartet werden (Wartung um den Goodwill zu erhalten ...). Die Kommunikation ist nicht mehr so einfach und findet meist in Schriftform statt, so können schneller Missverständnisse passieren. Das sind so die Nachteile die mir jetzt auf Anhieb einfallen.

Meine ganze Argumentation ziehlt auf extern genutzte Frameworks. Für interne Frameworks hast eher du recht, aber auch zwischen internen Abteilungen gibt es immer noch den Goodwill-Faktor :-) -- mj

Kannst Du etwas genauer ausführen, in welcher Form und in welchem Umfang Du das tust? Wir befinden uns nämlich teilweise in der Situation, eine API für unsere Kunden zur Verfügung stellen zu müssen und bin mir noch nicht ganz schlüssig, wie damit umzugehen ist. Bin für jeden Hinweis dankbar... :-) -- ip

Hmmm ... testgetriebene Architektur im kleinen Team :-), d.h.

*Wir machen eine Framework-Architektur

*Wir testen nicht erst beim Implementieren sondern schon davor. Wir haben zwei Architekten und einen Tester (vielleicht währe auch hier ein Paar angebracht). Tester und Architekten haben gemeinsamen Zugriff auf den Kunden und kommunizieren auch untereinader viel. Die Tester überlegen sich Anwendungszenarien als Testfälle und versuchen pessimistisch-creativ Lücken in der Architektur aufzudecken. Dann stellen die Architekten Ihr(e) Modell(e) vor und gemeinsam werden die Testfälle damit durchgespielt und bewertet ob die Architektur passt. Solltest du über einen KundeVorOrt verfügen, gehört natürlich genau der ins Testteam :-)

*PairArchitekturing?, zu zweit gibt's deutlich mehr Qualität. -- mj

Das Ergebnis ist eine reifere Architekur und eine klare Abschätzung wo die Risiken stecken. Im nächsten Schritt werden dann die Risiken mit Spikes (sowas kommt aber auch schon während der Architektur vor, um pessimistische Tester zu überzeugen) eliminiert (so die Theorie).

• FrameworkVeröffentlichung
• WardsWiki:ExtremeFrameworks