Don’t Give Up

In meinen mehr als 20 Jahren als Softwareentwickler hatte ich meist die Möglichkeit, Frameworks und Tools aufzubauen, die von anderen Entwicklern innerhalb meines Unternehmens verwendet wurden.

Eine Grundlage für ein Framework zu schaffen, das die Unternehmensstruktur am besten unterstützt, startet nicht bei Null, sondern ist eine Kombination aus mehreren ausgereiften Open-Source-Produkten.

Ein Problem aus zu tüfteln, ist die schönste Erfahrung beim Entwicklen. Und man hat ständig Probleme zu lösen ;-). Und wenn Sie einmal das Rätsel gelöst haben, ist die Programmierung unkompliziert und schnell umsetzbar.

Als Framework-Entwickler gibt es kein „kneifen: Ok, hier sind einige kleinere Probleme, aber egal wir leben mit einem Workaround. Stattdessen muss man tief in die Details eintauchen und das Probleme grundsätzlich lösen. Aufgeben ist dabei keine Option. Oft ist das wirklich hart und fühlt sich wie ein lang anhaltender Schmerz an. Aber that’s life: Manchmal muss ein Hacker das tun, was ein Entwickler tun sollte. Daher braucht ein Framework-Entwickler eine gute Ausdauer und Hartnäckigkeit.

Folge deinem eigenen Weg

Erfinden Sie  das  Rad nicht neu. Es gibt universell einsetzbare Frameworks für alle Bedürfnisse. Verwenden Sie diese Produkte, um ein spezielles Problem zu lösen und abstrahieren Sie von der gewählten Technologie, damit Sie diese in Zukunft gegen eine bessere Lösung bei Bedarf austauschen können.

Sicherlich klingt das ein wenig abstrakt und kompliziert, aber wenn man Flexibilität im Sinn hat, wird es einen durch den  Open-Source-Dschungel führen. Wie gesagt, es geht mehr darum bestehende Lösungen miteinander zu verbinden. Der applicative Code sollte komplett frei von einer bestimmten Techologie bleiben. Das Glue-Framework muß man selber entwicklen – denn es bildet ja die eigene Organisation ab – allerdings muß es so schlank wie möglich bleiben. Mit dem Surround Framework gehen ich da einen „universellen Weg“.

Modelling is Key

Wenn man einen Haufen Technologien im persönlichen Open-Source-Frameworks-Zoo verwendet, verliert man sich manchmal und weiß nicht wie ein komplexes System mit minimalem Aufwand zu implementieren ist.

Meiner Meinung nach ist das Schwierigste, was man als Entwickler lernen muß, das Modellieren. Vergessen Sie die UML, bei der nur Klassen- und Sequenzdiagramme wirklich benutzt  werden. Vergessen Sie auch BPMN  (mit Cammunda gibt es da allerdings eine wirklich schöne Workflow-Engine).

Ich meine, modellieren Sie Ihre „Domän Objekte“ analog am Whiteboard, so einfach und mächtig wie möglich. Zeichnen Sie Ihr System als einen Graphen, um die Nachrichten zwischen den einzelnen Komponenten zu identifizieren. Modellieren sie diese „Modell Snippets“ als „hierachischen Klumpen“, denn die meisten Systeme sind auf die eine odere andere Art hierarchisch.

Auch sollte man die fachiliche Domäne immer wieder neu modellieren, das trainiert die Modellierungs Fähigkeit ungemein. Über die Jahre habe ich in geschäftlichen und privaten frameworks meinen Surround Ansatz immer weiter entwicklet, zuletzt in einem Meta Modell für eine modell getriebene Workbench bei lsTelcom AG. Hat man die Zusammenhänge im Kopf, so kann man das bisschen „Model Code“ schnell auf der grünen Wiese umsetzen. Ist was schickes gelungen, kommt dies auch einfach in das „alte Modell“.

Dies ist wirklich der schwierigste Teil des Software-Engineerings, man muss es einige Jahre üben, bevor man „swingt“. Ein gutes Objektmodell macht alles einfach, ein schlechtes – oder „gar keins“ – wird Ihnen während der gesamten Produktlebensdauer Probleme bereiten.

Die Modellierung unterstützt Funktionalität, Flexibilität und Qualität. Es ist Ihre Aufgabe als Frameworker, alles im Gleichgewicht zu halten….

Andere Sichtweise