Wir haben da erstmal ein Framework geschrieben ...

Wenn ich in ein Projekt komme, bei dem ich zuerst diesen Satz höre, bekomme ich regelmäßig eine Gänsehaut. Warum?

Für ein erfolgreiches Projekt ist es wichtig, sich zuerst einmal damit zu beschäftigen, was mit dem Projekt bewirkt werden soll. Man muß das Vokabular der fachlichen Anforderung lernen und herausarbeiten, welche Eigenschaften der zu erstellenden Software den eigentlichen Wert für den Kunden ausmachen. Nachdem das verstanden ist, werden riskante Technologien betrachtet.

Wird aber damit begonnen, ein Framework zu erstellen, bedeutet das immer nur das eine: Angst vor den fachlichen Anforderungen. Diese sind unklar und nicht verstanden. Anstelle dem Kunden solange zu fragen oder sich aus anderen Quellen zusätzliche Information zu besorgen, die die Anforderungen klären würden, zieht man sich auf das Feld zurück, von dem man meint, etwas zu verstehen. Es werden reihenweise Entwurfsmuster zusammengebastelt, bis etwas entsteht, daß deutlich zeigt, welche technologischen Interessen die Ersteller haben, aber der Lösung des eigentlichen Problems nur im Wege steht.

Hier zeigt sich auch die dunkle Seite der Entwurfsmuster. Viele scheinen heutzutage der Meinung zu sein, daß nur hinreichend viele Entwurfsmuster aneinandergereiht werden müssen, um eine sinnvolle Architektur zu erreichen. Natürlich ist die Kenntnis von Entwurfsmustern extrem hilfreich. Nur darf das Muster nicht am Anfang stehen, sondern muß das Ergebnis sein. D.h. ich beginne mit einer Anforderung, betrachte mir eine mögliche Umsetzung, erkenne eine unerwünschte Kopplung und dann fällt mir ein, daß es ein Entwurfsmuster gibt, mit dem sich die Kopplung elegant auflösen läßt.

Gute Frameworks entstehen nie auf der grünen Wiese. Die besten werden aus erfolgreichen Projekten "geerntet" (die Formulierung habe ich von Erik Dörnenburg, ThoughtWorks geklaut). Wenn eine Architektur sehr gut geraten ist, lohnt es sich manchmal, anschließend das technische Framework von der konkreten Fachlichkeeit zu befreien und für die Wiederverwertung aufzubereiten.

Dies kann auch im kleinen erfolgen. Wenn ein Projekt viele technisch ähnliche Dinge (Masken, Schnittstellen ...) zu implementieren hat, sollte zuerst eine konkret realisiert werden und dann bei der nächsten darauf geachtet werden, daß nichts mit Kopieren und Einfügen übernommen wird, sondern gemeinsam nutzbare Teile entstehen. Das geeignete Framework entsteht so ganz von alleine.

Es ist jedenfalls ein sicherer Weg ins Desaster, wenn man ein Framework baut, daß alle Fragen beantwortet, die niemand gestellt hat, während man die eigentliche Frage noch nicht kennt.