Archiv für die Kategorie ‘Uncategorized’

Pattern Driven Development ist keine Lösung

Veröffentlicht: 30. Dezember 2010 von Christian Raschka in Uncategorized

„A pattern addresses a recurring design problem that arises in specific design
situations, and presents a solution to it.“ (Aus Buschmann, F., Meunier, R., Rohnert, H., Sommerlad, P., Stal, M. (1996) A
System of Patterns. John Wiley & Sons.)

Hm… ein Pattern soll uns helfen ein Problem zu lösen. Die Frage ist nur welches? Und woran erkenne ich, wenn ich denn eins habe, welches Pattern mir dabei hilft es zu lösen? Diese Fragen sind scheinbar nicht einfach zu beantworten, anders kann ich es mir nicht erklären, warum es so viel Literatur über Antipatterns gibt. Viele vermeintlich gute Muster werden sehr schnell zu Problemstellen ganzer Softwarebausteine. Denn leider gibt es in den seltensten Fällen eine optimale Lösung. Alle Lösungen (und auch die meisten Patterns) beinhalten „Kosten“. Diese werden zwar bei sinnvoller Anwendung der Muster meist durch die Vorteile aufgehoben. Doch ob und wann dieser Zustand eintritt ist nicht bekannt.

Was also passiert ist folgendes: Man nimmt sich eine Liste von „Best-Practices„, nennen wir diese in diesem Fall „Pattern-Katalog“. Wenn ich nun nach diesen Mustern entwickle kann mir doch eigentlich nichts passieren, oder doch? Leider eben schon. Und ich meine dabei nicht einmal nur das Singleton-Pattern. Viele der Lösungen sind möglicherweise zu kompliziert oder führen Abhängigkeiten ein, die es ohne Anwendung des Pattern gar nicht gegeben hätte.

Um dies zu untersuchen, hatten wir folgende Idee: Wir machen „Brain-Driven-Development“. Anstatt irgendwelche Probleme zu suchen, die dann mittels Pattern gelöst werden können, verwenden wir unseren Verstand. Zugegebenermaßen klingt dies etwas provozierend aber ich möchte erläutern, was ich damit meine.

Wir wollen eine Software erstellen, die ein bestimmtes Problem löst und dazu eine grafische Benutzeroberfläche bereitstellt. Die meisten würden an dieser Stelle wohl sehr schnell in den Raum schreien, wir brauchen dazu MVC (oder MVP, MVVM …). Aber wie kann ich das an dieser Stelle schon wissen? Die Anforderung war noch gar nicht so weit, um zu wissen, dass dies notwendig ist.

Wie wäre denn mein folgender Vorschlag: Wir lassen mal außen vor, was wir über (GUI-) Patterns wissen. Nur kurz. Und dann fangen wir an. Wir erstellen uns Schnittstellen der Aufgaben, die die GUI später anzeigen soll. Wie diese zu implementieren sind, ist uns an dieser Stelle egal. Und dann entwerfen wir die GUI. Möglicherweise brauchen wir Dummyimplementierungen der Schnittstellen damit wir vernünftig arbeiten können, aber das sollte ja kein Problem sein. Und wenn wir fertig sind, fangen wir an die Implementierung dieser Schnittstellen zu modellieren…

Was haben wir damit erreicht? Eine Trennung von Anzeigelogik und Geschäftslogik? Jawohl. Also ja doch MVC? Nein, denn es wird wahrscheinlich keine Klasse geben, die Controller heißt. Aber vielleicht ja doch. Und eventuell stellt sich hinterher heraus, dass eine Klasse die Aufgabe eines Presenters erfüllt, dann nenne ich diese um, damit andere dies auch erkennen. Und dann kommt auch der volle Nutzen von Patterns zum Tragen.

Wer also gut Software erstellen möchte, sollte nicht auf Teufel komm raus versuchen Patterns anzuwenden. Lieber sollte man versuchen, seinen Verstand einzusetzen und dann möglicherweise auch Patterns.

Wir lösen am liebsten die schwierigen Probleme

Veröffentlicht: 21. Dezember 2010 von pmischke in Uncategorized

Vor einiger Zeit las ich einen Artikel von Oren Eini, in dem er eine Architektur mit rich client und server back end vorstellt (siehe unten). In diesem Artikel findet sich folgendes Zitat:

The actual code is pretty boring. […] However, this is more important than you might think. An architect’s job, I’d argue, is to make sure that the developers in the project are as bored as possible. Most business problems are boring, and by removing technological complexities from the system, you get a much higher percentage of developer time spent working on boring business problems instead of interesting technological problems.

Hier sehe ich einen gewissen Interessenkonflikt. Zusammenfassend könnte man demnach auch sagen, dass gute Architektur zu langweiligem Code führt. Es hat aber niemand großen Spaß daran, langweiligen Code zu schreiben.

Wird die Rolle des Architekten nicht von einem Entwickler eingenommen, wäre dieser bei den Entwicklern bestimmt schnell „unten durch“. Wer lässt sich schon gerne die langweiligen Aufgaben zuschieben? Es ist fraglich, wie lange der Architekt seine Autorität aufrecht erhalten kann, bevor die Entwickler eigene Architekturen aufziehen.

Wird die Architektur hingegen von den Entwicklern selbst gemacht, ergibt sich der angesprochene Interessenkonflikt. Warum sollte ich dafür sorgen, dass meine Arbeit langweilig wird?

Ich glaube, die Lösung des Konflikts liegt im Wertesystem. Einfachheit wird in der Softwareentwicklung vielfach mit langweilig gleich gesetzt. Hohe Komplexität ist interessant, spannend und herausfordernd. Hohe Komplexität zu beherrschen,  ist unser Ding. Vielleicht sollten wir uns aber auf die positiven Aspekte von Einfachheit besinnen. Einfachheit ist verständlich, ästhetisch, genial. Weitere Plädoyers für Einfachheit finden sich bei Wikipedia und Wikiquote.

Glück auf!

Veröffentlicht: 19. Oktober 2010 von Christian Raschka in Uncategorized

Willkommen im neuen Blog für mehr Qualität und Professionalität in der Softwareentwicklung. Aber wozu brauchen wir mehr Qualität? Wir wollen „Programme“ erstellen, die dem Kunden einen Mehrwert bringen. Dazu ist es notwendig möglichst wenig Kosten zu verursachen. Es kommt also nicht darauf an, möglichst viele neue Technologien, Prinzipien oder Buzzwords zu verwenden. Dies bringt dem Kunden erstmal nichts. Und trotzdem ist es oft sinnvoll einige dieser Dinge zu benutzen, weil sie uns in einem bestimmten Kontext eventuell einen Mehrwert bringen. Dies kann gesteigerte Evolvierbarkeit oder mehr Korrektheit. Aber vielleicht auch einfach schnelleres und kostengünstiges Entwickeln. All dies muss abgewägt sein. Und  genau dies möchten wir in diesem Blog erreichen: Kritisches Auseinandersetzen und Abwägen von aktuellen Softwareentwicklungsthemen.

Wir wollen ja letztendlich Programme und Produkte fabrizieren und dazu gehört es schließlich Code auf die Straße zu bringen. Dazu haben wir verschiedene Autoren gewinnen können, die zu pragmatischem Erstellen von Software schreiben werden. Nicht regelmäßig – aber regelmäßig mit hoher Qualität. Dazu gehören:

  • Sebastian Jancke, Software-Architekt, Trainer
  • Peter Mischke, Software-Architekt, Trainer und Scrummaster
  • Christian Raschka, Software-Architekt, Trainer und Sprecher
  • Uli Schulze-Eyßing, Software-Architekt und Berater
  • Christian Strebe, Software-Entwickler

Also dann freuen Sie sich gemeinsam mit mir auf gesteigerte Produktivität und Qualität aus dem Kombinat Programmproduktion West (KPPW)!

Mit sozialistischem Gruß

Christian Raschka