Читать книгу Zukunftssichere Architektur - Ralf Westphal - Страница 7

Zurück zu den beiden Softwareentwicklern im Gespräch. Mit welcher Konvention würde es dem einen leichter fallen, im Team des anderen mitzuarbeiten? Mehr Konsens in Bezug auf den grundlegenden Aufbau von Software wäre da sicherlich eine große Hilfe.

Eine "Konsensklammer" gibt es schon (Abbildung 1): Plattform und fundamentales Programmierparadigma. Beide Entwickler sind sich auch einig über die Art der Applikation und die Codekategorisierung durch Schichten. Benutzerschnittstelle, Domänenlogik oder Infrastrukturzugriff sind so allgemein, dass diese grobe Einteilung von Code für jede Applikation gelten kann.

[Abb. 1] Konsens herrscht im Fundamentalen und sehr Allgemeinen. Dazwischen liegt allerdings eine weitgehend konventionsfreie Zone.

Konsens im Fundamentalen, Konsens im Allgemeinen. Aber dazwischen klafft eine Lücke, die ressourcenfressende Entscheidungen fordert, weil Konventionen fehlen. Sie zu schließen, würde vielen Entwicklern helfen, sich wieder mehr auf das Wesentliche konzentrieren zu können und produktiver zu arbeiten.

Es geht um einen vergleichsweise kleinen Schritt über die Objektorientierung hinaus. Um etwas, das auf der Objektorientierung aufbaut, deren Werte also nicht negiert; was in Theorie und Praxis verständlich ist. Die Praxis ist sogar sehr wichtig - in Form von Konventionen für die Codierung, weil ansonsten der mühevolle Transfer theoretischer Überlegungen in die Coderealität wieder die Produktivität senkt.

Regeln, welche die festgestellte Lücke verkleinern, sollen einerseits anleiten-, also Unsicherheit nehmen -, andererseits Eigenverantwortung betonen. Konzepte sollten dabei von Werkzeugen unterstützt werden, wo es geht, andererseits aber natürlich weitgehend herstellerneutral sein.

Als Analogie mag der Hausbau dienen. Da gibt es nicht nur grundlegende Konventionen, was die Baumaterialien angeht, und allgemeinen Konsens über die Einteilung eines Hauses in Fundament, Wände und Dach. Die Gemeinsamkeiten zwischen Häusern - auch ganz unterschiedlicher Art - gehen viel weiter. Jedes Haus hat Wasseranschluss und führt Rohre in verschiedene Räume; jedes Haus hat Anschluss ans Elektrizitätsnetz und führt elektrische Leitungen in alle Räume; jedes Haus hat eine Heizungsanlage und führt Heizungsrohre in alle Räume. Ab einer bestimmten Höhe hat jedes Haus Aufzüge, die alle Stockwerke bedienen und dazu ihre Schächte und den Antrieb.

So viele Gemeinsamkeiten, so viele Konventionen - und doch so viel Freiheit. Denn was Sie in den einzelnen Räumen tun, ist Ihnen freigestellt; welche Geräte Sie an die elektrischen Leitungen anschließen, entscheiden Sie. Die Gemeinsamkeiten im Hausbau betreffen eine Infrastruktur, die dazu dient, sich in den Räumen zu entfalten. Sie sollen sich keine Gedanken mehr darüber machen müssen, wie Sie es hell, warm, sauber und bequem haben könnten.

Die Konventionen sorgen dafür, dass ein Haus Bedürfnisse verschiedener Kategorien erfüllen kann. Sie schaffen sozusagen schon die Bedingungen für die Möglichkeit von Dienstleistungen, die zum Beispiel mit Wasser oder Elektrizität zusammenhängen. Welche Dienstleistungen das dann sind, ist egal. Strom und Wasser kommen über Standardanschlüsse ins Haus. Aus den Leistungen, die diese Standards unterstützen, können Sie dann frei wählen.

Genau darum geht es beim Plädoyer für mehr Konventionen bei der Softwareentwicklung: Sie sollen es leichter haben, "Dienstleistungen" in Ihrem "Softwarehaus" zu installieren und zu verbinden. Oder sogar noch grundlegender: Sie sollen überhaupt erst einmal in Dienstleistungen denken - Services statt Verkabelung. Welche Services jedoch, ist egal. Wählen Sie nach Belieben und machen Sie sich keine Sorgen über die Verbindungen. Für die Verkabelung und die Anschlussfähigkeit sorgen die Prinzipien und Technologien des erweiterten Konsens.

Insofern geht es mir nicht um ein Application Framework mit Konventionen für Persistenz, Sicherheit, Benutzerschnittstelle und so weiter. Das wären schon konkrete Dienstleistungen. So verständlich es ist, Arbeit sparen zu wollen, indem Sie sich auf solche Vorgaben einlassen - der Unterschied zwischen Konvention und Korsett ist fließend. Und je höher das Abstraktionsniveau einer Konvention, desto eher stören Sie sich an ihren Beschränkungen. Kompensieren können Sie das dann nur durch eine Einengung Ihrer Bedürfnisse, zum Beispiel im Hinblick auf die Art der Anwendung oder des Bedienmodells.

Wenn Sie also flexibel bleiben und dennoch Produktivitätsgewinn aus mehr Regeln ziehen wollen, dann müssen Sie die Konventionenlücke aus Abbildung 1 schrittweise von unten her schließen.