LITMIR.BIZ

Скачать книгу

wird es kaum mehr Gemeinsamkeiten geben.

      Jenseits der Werkzeuge und der durch sie vertretenen Konzepte herrscht wenig Konsens in der Softwareentwicklung. Compiler schaffen Gemeinsamkeit bei der Sprache mit ihrem fundamentalen Programmierparadigma. IDEs schaffen Gemeinsamkeit beim Aufbau von Benutzeroberflächen und der Quellcodegrundstruktur. Datenbanken schaffen Gemeinsamkeit bei der Datenorganisation.

      Wo Werkzeuge oder Konzepte unbekannt oder nicht weit verbreitet sind, herrscht deshalb im Umkehrschluss keine Gemeinsamkeit; weder in der Vorgehensweise noch in Bezug auf die Produktion oder in Architekturfragen. Die Agilitätsbewegung bemüht sich zwar; Team Foundation Server & Co bemühen sich auch; aber es ist unwahrscheinlich, dass die beiden Entwickler in ihrem Gespräch hier schon viele Gemeinsamkeiten entdecken würden. Und noch unwahrscheinlicher ist es in Bezug auf den grundsätzlichen Aufbau ihrer Anwendungen, also ihre Architektur.

      Diese Abwesenheit von Gemeinsamkeiten halte ich für überraschend und kontraproduktiv. Nach 50 Jahren Softwareentwicklungspraxis ist die Zahl der Gemeinsamkeiten zwischen zwei Anwendungen immer noch an einer Hand abzählbar. Das gibt es in keiner anderen Branche. Der Ruf nach Standards ist allerorten zu hören, von den Programmiersprachen über die Kommunikation bis zu Office-Dokumentenformaten; was den inneren Aufbau einer Anwendung angeht, verhallt er ungehört.

      Das Resultat: geringe Produktivität. Denn wo kein Konsens herrscht, ist immer erst ein Weg zu bahnen. Das kostet Ressourcen.

      Kreativer und produktiver mit Regeln

      Mehr Konsens und mehr Systematik tun Not. Softwareentwicklung sollte in mehr Aspekten klaren Regeln und typischen Lösungen folgen, die in mindestens 80 Prozent der Fälle zu ausreichenden Implementierungen führen. Die Normalisierungsregeln für relationale Datenbanken sind dafür vielleicht das beste Beispiel: Sie machen klare Vorgaben, sind leicht umzusetzen, führen zu verständlichen Strukturen und sorgen für Wartbarkeit. In den meisten Fällen sind die sich daraus ergebenden Datenbanken auch effektiv genug. Falls nicht, ist es auch kein Verrat, eine Regel auch mal zu brechen. Den grundsätzlichen Konsens beeinträchtigt das nicht. Er hilft, den Kopf für das Wesentliche, die Problemdomäne, freizuhalten.

      Ähnliches gilt auch für die Objektorientierung. Sie ist Konsens, was das allgemeine Programmierparadigma angeht. Dass zwei Entwickler für ein Problem unabhängig voneinander eine objektorientierte Sprache wählen, ist sehr wahrscheinlich. So wird es einfach, produktive Teams zusammenzustellen.

      Entwurfsmuster haben das Ziel, Gleiches auf einer höheren Abstraktionsstufe zu wiederholen. Sie definieren ein Vokabular für wiederkehrende Probleme mit probaten Lösungen. MVC und Schichten sind vielleicht die bekanntesten Beispiele. Beide sind übersichtlich und leicht verständlich, beide haben ein klares Anwendungsgebiet. Beim Vorgehensmodell könnte Scrum [1] das Zeug dazu haben, ein konsensfähiges Minimalmuster zu werden.

      Konventionen und Regeln bedeuten allerdings nicht sklavisches Befolgen. Sie sollen zunächst nur den Blick leiten und Ordnung in das Chaos bringen. Die schnelle 80-Prozent-Lösung ist ihr Zweck. Sie können selbstverständlich gebrochen werden. Denormalisierung ist nicht nur erlaubt, sondern manchmal einfach geboten. Wer allerdings eine Regel bricht, muss sich erklären. Und das ist gut so. Das schafft Bewusstsein und Verantwortungsgefühl für das, was man tut.

      Mehr Regeln machen das Leben leichter, weil sie uns Entscheidungen abnehmen. Sie schaffen sogar Spielräume. Fragen Sie einen Künstler: Der wird Ihnen sagen, dass Kreativität von Beschränkung profitiert, ja, sie geradezu braucht.

      Regeln sind auch konform mit der Philosophie der Lean Production und der Agilitätsbewegung, Entscheidungen so spät wie möglich zu treffen. Denn wer nach einer Regel handelt, der muss eigentlich noch keine "richtige" Entscheidung treffen. Er vertagt sie vielmehr, bis es ein Problem mit der Regel gibt. Da das aber qua definitionem selten der Fall ist - sonst wäre eine Regel ja keine Regel, allemal keine gute -, spart er in den meisten Fällen Zeit und Nerven.

      Regeln für den Anwendungsbau

      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

Скачать книгу