Vorwort

Programmiersprachen sind abstrakter geworden. Frameworks wie J2EE und.NET bieten eine immer umfangreichere Funktionalität und steigern die Produktivität erheblich. IDEs werden intelligenter und agieren als Hintergrund-Compiler. Patterns und Best Practices finden sich überall. Wenn doch alles für uns arbeitet, warum ist die Software-Entwicklung dann immer noch so kompliziert? Sicher kann man eine einfache Webanwendung in einer Stunde erstellen, aber darum geht es hier nicht. Hier geht es um Unternehmensanwendungen, die aus Tausenden von Klassen zusammengesetzt sind und mit denen Finnen wie eBay, Amazon.com, Saleforce.com und andere Unternehmen mit Hunderttausenden oder gar Millionen von Kunden betrieben werden.

Ich glaube, das Problem ist leicht zu verstehen, aber seine Lösung ist äußerst schwierig. Interessanterweise haben beide mit "Tooling" zu tun. Lassen Sie mich das erklären. Ich verwende Emacs jetzt seit fünfzehn Jahren und stellte erst kürzlich auf eine IDE um. Fragen Sie einen Emacs-Benutzer, warum er dieses Programm verwendet, nennt er Ihnen wahrscheinlich die folgenden Gründe: Geschwindigkeit, Leistungsfähigkeit und Flexibilität Aber erst als ich vor einigen Jahren begann, IDEs (natürlich mit Emacs-Bindungen) zu verwenden, begriff ich, dass sie meine Arbeit kaum verlangsamten, dafür aber mein Verständnis des Kontextes meiner Entwicklungsaufgabe verbesserten und zusätzlich Hilfe boten. Anders ausgedrückt: Wenn ich heute in Java programmiere, wissen die IDEs über Java Bescheid und bieten Codeergänzung an, können Klassen importieren und, was am besten ist, Syntaxfehler erkennen, ohne dass das Programm kompiliert werden muss. Doch der eigentliche Coup ist das Refactoring. Da wir unseren Code immer wieder refaktorisieren, ist es ein echter Segen, der IDE die ganze mühselige Arbeit zu überlassen, die mit einer simplen Umbenennung einer Methode verbunden ist. Und das gehört gerade mal zum Entwicklungsteil. IDEs unterstützen auch das Paketieren und Deployment, da sich ein großer Teil von J2EE und.NET um das Paketieren und Entpacken eines Bündels von Dingen dreht. Schließlich überzeugten mich alle diese Fähigkeiten davon, dass IDEs doch "gar nicht so dumm" (vielleicht sogar ein wenig intelligent) waren, und eine gewisse Ahnung von meiner Arbeit hatten.

Doch es war wie bei vielen Dingen: Je mehr Sie bekommen, desto mehr wollen Sie haben. Und da ich Architekt und Mitverfasser von Core J2EE-Patterns bin, frustrierte mich die Tatsache immer mehr, dass alle diese so genannten intelligenten Funktionen wirklich nur auf den Code und nicht die Architektur, das Design und die Patterns abzielten. Heute werden Werkzeuge angeboten, mit denen Sie bestimmte Sachen vorschreiben können. So können Sie etwa in einem J2EE-Umfeld mit Werkzeugen ausdrücken, dass Sie ein Pattern eines Front Controllers erstellen wollen, der mit einem Business Delegate spricht, und sich das entsprechende Skelett generieren lassen. Aber ich kenne kein Werkzeug, mit dem ein Architekt seinen Entwicklern die Patterns Front Controller, Business Delegate und Session Facade vorschreiben könnte, und das dann den Entwicklern die richtigen Patterns im richtigen Teil des Projektes vorschlägt, das Änderungen entdeckt, die ein Pattern verletzen, und das möglihe Korrekturen vorschlägt. Soweit ich weiß, gibt es dafür den folgenden Grund: Einige Werkzeuge eignen sich für das Entwerfen, andere unterstützen das Codieren, aber kein Werkzeug vereinigt diese beiden Aufgaben. Und das ist genau der Punkt, an dem Software Factories ins Spiel kommen.

Wenn Sie den Terminus Software Factory zum ersten Mal lesen, sind Sie vielleicht skeptisch, weil Sie annehmen, dass die Software-Entwicklung so sehr den Charakter einer Warenproduktion annehmen soll, dass sie nicht mehr kreativ ist, und dass Entwickler auf Handlanger reduziert werden, die mechanische Aufgaben erledigen. Aber das stimmt nicht. Heutige Fabriken stellen eine Umgebung her, in der die niedrigen Aufgaben automatisiert sind, und Arbeiter die Freiheit haben, sich auf die kreativen Aufgaben zu konzentrieren.

Eine primitive materielle Fabrik besteht möglicherweise nur aus Werktischen, Stühlen, Rohstoffen, Werkzeugen und natürlich Arbeitern. Doch in einer hoch entwickelten Fabrik wie einem Automobilwerk finden Sie autonome Roboter, die Teile von hoch automatisierten Materialverteilersystemen aufnehmen und mit unglaublicher Geschwindigkeit zu Endprodukten zusammensetzen. Sie wurden von Ingenieuren entworfen, um viele langweilige, geisttötende Tätigkeiten zu automatisieren.

In einer hoch entwickelten Kraftfahrzeugfabrik ist alles darauf abgestimmt, den Zusammenbau von Fahrzeugen zu optimieren, um Autos höchster Qualität zu den niedrigstmöglichen Kosten zu produzieren. Eine Kraftfahrzeugfabrik ist dafür optimiert, Autos, nicht Halbleiter oder Schuhe zu produzieren - das heißt, sie ist spezialisiert. Doch auch wenn eine Fabrik wahrscheinlich darauf optimiert wurde, eine bestimme Klasse von Autos zu bauen, kann sie eine große Vielfalt verwandter Modelle erzeugen, die jeweils viele verschiedene Kombinationen von Eigenschaften in sich vereinigen. Worum also geht es? Es geht darum, dass Fabriken Umgebungen sind, die gezielt für einen Kontext geschaffen wurden: nämlich spezifische Produkte herzustellen. Und genau darum geht es auch bei Software Factories. Mit Einrichtung und Werkzeugen soll eine Umgebung geschaffen werden, die im Hinblick auf einen bestimmten Typ von Anwendungen mit einer spezifischen Architektur optimiert ist, um die entsprechenden Anwendungen leichter, schneller und effizienter erstellen zu können.

Das Schöne an diesem Buch ist, dass die Autoren Praktiker sind und aus Erfahrung sprechen. Es handelt sich also nicht nur um eine gute Idee, sondern um einen gut durchdachten Ansatz, der gegenwärtig in vielen verschiedenen Umgebungen angewendet wird. Das Buch ist deshalb so faszinierend, weil es bei Software Factories nicht um Assistenten oder Property Sheets geht, sondern um Architektur- und Designspezifikationen, die den Kern des Entwicklungsprozesses bilden. Ob es sich um Vorschriften oder Anleitungen und Validierungen handelt, spielt keine Rolle; sie sind vorhanden und überdauern die gesamte Entwicklung und das Deployment. Das bedeutet, dass Architekten Patterns, Frameworks, DSLs (Domain Specific Languages, dt. Domainspezifische Sprachen) und die von den Autoren so genannten Software Factory Schemas definieren können, um die Entwicklung zu steuern und den Werkzeugeinsatz zu ermöglichen. Dies führt zu ganz neuen "Spielregeln". IDEs sind nicht mehr nur Allzweck-Software-Werkzeuge, die kaum mehr als die elementare Syntax verstehen, sondern architekturgesteuerte kontextbewusste Superwerkzeuge für spezifische Anwendungsbereiche, die Entwicklern helfen, komplexe Systeme zu verstehen und mit bewährten Patterns mit wohlbekannten Eigenschaften schnell zu konstruieren.

Für mich sind Software Factories das nächste "große Ding" und nicht nur eine weitere Mode auf dem Jahrmarkt der Software-Entwicklungsmethoden. Durch Einbindung der Kenntnisse über Architektur und Design ist das neue Paradigma der Software Factories auf dem Weg, revolutionäre Produktivitätsgewinne bei der Software-Entwicklung zu ermöglichen.

Lesen Sie dieses Buch und wenden Sie die gewonnenen Informationen an, um an der Zukunft der Software-Entwicklung teilzuhaben.

- John Crupi
Sun Distinguished Engineer, Mitautor,
Core J2EE Patterns: Best Practices and Design Strategies