Einführung
Die Aritkel von Norbert Eder, Peter Bucher und Alexander Zeitler und ihre Folge-Artikel haben mich auch zum Nachdenken angeregt. Zum Nachdenken über meine aktuelle Situation als Softwareentwickler/-architekt. Was macht mich als Entwickler aus. Wo liegen meine Stärken und Schwächen. Was ist für mich erstrebenswert und warum will ich genau diese Ziele verfolgen?
Codetyping als Sport
Softwareentwicklung wird von vielen als eine Sportart angesehen. Je mehr Code ich schreibe, desto besser! Bewußt wird mir das durch die ständig neuen Releases auf Hostingplattformen wie Google Code, Codeplex, Sourceforge oder Artikelseiten wie Codeproject. Doch ist das wirklich so?
Das kann pauschal nicht beantwortet werden. Nun will ich das mal genauer unter die Lupe nehmen. Was unterscheidet den Code hinsichtlich der Quantität und der Qualität. Für mich als ambitionierten und engagierten Softwareentwickler mit starkem Drang zur Architektur stellt sich immer wieder die Frage: Wie verbessere ich meine Fähigkeiten guten Code zu schreiben? Was macht guten Code überhaupt aus? Und brauche ist das denn unbedingt? Es soll doch Spaß machen.
Aller Anfang ist ... schön
Früher habe ich in die Tasten geklopft, so dass die Töne der Anschläge jenseits der Schallmauer lagen. Ich bin kaum mit dem Denken nachgekommen. Design und Architektur haben mich damals schlichtweg nicht interessiert. Was zählte war der lauffähige Code. Mit der Zeit erfährt aber auch jeder noch so unerfahrene Neuling, dass Code mit der Zeit verwuchert und der Pflege bedarf. Aber woher kommt das? Warum passiert es mir immer wieder, das mein Code nicht gut wartbar ist?
Die Suche nach dem Ausweg
An diesem Punkt angekommen stellt sich jeder Entwickler die Frage: "Wie zum Teufel kann ich meinen Code so strukturieren, das ich ihn leichter Pflegen kann, d.h. er offen für Neuerung ist und mir das Leben aber nicht zur Qual macht". Zweifels ohne ist der Anfang immer schöner. Er kommt mir wie meine Kindheit vor. Loslaufen und entdecken. Ahh, ein Sandkasten ... las uns buddeln und Burgen bauen. Das funktioniert Anfangs gut und die Ergebnisse sind sehr zufriedenstellend. Nach einiger Zeit stellt sich der Spieltrieb etwas ein und die Frage nach Qualität drängt sich langsam in den Vordergrund. Man hat Spaß gehabt, es hat anderen Freude bereitet dich dabei vergnügt anzuschauen wie du spielst und sie haben unter Umständen einen Nutzen gehabt. Nun wollen aber Werte hergestellt werden. Dem Kern unserer heutigen modernen Gesellschaft: Der Mehrwert oder im Fachchinesisch "Added Value".
Hin zu Organisation und Verantwortung
Die Zeit des Spielens ist nun vorbei und der Entwickler sollte sich so langsam Gedanken machen, wie er seinem Brötchengeber rechtfertigen kann, was er da zusammenbaut. Ob in einem geführten Unternehmen, oder in der Selbständigkeit: Initiative und Vorbildfunktion gehören überall dazu. Ich fing damals also an mir über strukturelle Organisation meiner Selbst und meines Codes Gedanken zu machen. Habe Wochenlang Diskussionsforen, Usergroups und Blogbeiträge studiert und mir empfohlene Fachliteratur zu Gemüte geführt - das tue ich im Übrigen noch immer. Viel habe ich auch aus Beispiel-Code gelernt - positiv wie auch negativ. Beim Durchforsten der Quellen immer und immer wieder auftauchende Muster entdeckt. Ich stellte fest, das ich meinen Code leichter verwalten kann, wenn ich es schaffe, mir diese Muster zu eigen zu machen und meine Entwicklung auf Qualität und Wiederverwendbarkeit auszulegen. Damit meine ich nicht, alles mögliche für die Zukunft in eine Klasse oder ein Programm zu stecken, sondern die entstehenden Klassen so zu entwerfen, dass sie offen für einfache Erweiterungen sind.
Patterns ...
Wer sich lange genug mit dem Thema beschäftigt wird feststellen, dass diese Gedanken schon andere Menschen beschäftigt haben. Es gibt genug Größen innerhalb der Branche, die einem vormachen wie es geht um für mich mal nur einen der wichtigsten zu nennen Martin Fowler. Und das müssen wir uns zu nutze machen. Wie fange ich an das praktisch umzusetzen? Gelernt habe ich vor allem eins: Die Technologie ist zweitrangig! Was erst einmal zählt ist das Verständnis für das Themengebiet.
...and Practices
Meine 10 Jahre lange Erfahrung im Bereich C++ kann mir keiner nehmen und diese will ich auch nicht hergeben. Vielleicht auch ein Grund warum ich vor 3 Jahren anfing mich mit C# zu beschäftigen. Der Grund: Es war einfacher Abhängigkeiten losgelöst zu entwickeln. Echte Interfaces waren nicht so umständlich zu entwerfen. Die Komponentenorientierung viel einfacher. Der große Boom der SOA Architektur schwappte auf. Aber Viele haben "Service" als zu wörtlich genommen und sind beim WebService gelandet. Das ist meiner Meinung nach zu verallgemeinert und falsch verstanden worden. Wie sehe ich das ganze denn nun?
Jetzt geht's ans Eingemachte - lasset die Architektur beginnen
Wir sind am Ziel! Wer über kurz oder lang eine Applikation von mittlerem bis großem Umfang mit einer stetig steigenden Komplexität entwickeln und pflegen muss kommt an einem Thema nicht vorbei: Dependency Injection! Warum das so ist will ich in späteren Artikeln in Beispielen erklären. Ob das über die am Markt bestehenden Container-Frameworks wie StructureMap, Unity, NInject, CastleWindsor usw. gemacht wird, oder sich andere Lösungen auszudenken sind sei einmal dahin gestellt. Wichtig ist, dass sich der Entwickler über die Komplexität und deren Beherrschbarkeit Gedanken macht. Ich lege jedem, der sich mit dem Thema noch nicht auskennt den Artikel Before you use an IoC tool, some concepts to know first vom StructureMap Entwickler Jeremy D. Miller ans Herz. Hier greift er einige der wichtigsten Themen zur Komponenten- und somit Serviceorientierten Entwicklung auf. Ralf Westphal durch seine Tätigkeit als Fachautor Trainer und Referent auf Fachmessen bekannt strebt hier auch die Vereinfachung an - ich oute mich jetzt hier mal als Fan. Er versucht Architektur, die auch skalieren kann zu vereinfachen. Auch wenn ich in Newsgroup-Diskussionen nicht immer seiner Meinung bin, schätze ich sein Wissen und seine Fähigkeiten sehr.
Was kommt demnächst
Dieses Jahr ist noch zu voll gepackt für diese Themen in der privaten Freizeit. Aber was ich hier im nächsten Jahr für mich reflektieren will (aus sicht des Entwicklers), sind Prinzipien aus OOD, DDD, BDD. Objektorientiert, Daten- und Spezifikationsgetrieben!
- Wichtige Grundgedanken und Prinzipien eines modernen Entwicklungsprozesses (die auch Jeremy D. Miller in seinem Artikel aufzählt) und ihre logischen Zusammenhänge.
- Die Durchführung dieser Prinzipien mit einem Container (Unity) und Testing Frameworks
Fazit
Gedanken, die auch andersartig sein dürfen, sind gut, denn sie regen den Wissenstransfer an. Ein wichtiger Aspekt für mich beim Lernen: Reflektieren und sich durch Andersartigkeit inspirieren lassen. Andersartigkeit ist deswegen gut, weil sie es in Frage stellt ob der Alltag noch richtig ist. Sie lässt einen Nachdenken und die bisherigen Annahmen in Frage stellen. Sie ist für mich ein Innovationsmotor. Ein Leitspruch meiner alten Arbeitsstelle: "Nicht das Erzählte reicht, sondern das Erreichte zählt!" Erreichen kann man viel, erzählen noch viel mehr. Aber was ich am Ende meiner Bemühungen erreicht habe ist wichtig: Ich will eine saubere Architektur, in allen wichtigen Belangen!