Philosophie

Hier erfahren Sie, welche Schlüsse ich aus meinen bisherigen Erfahrungen gezogen habe und wie ich diese in meinen IT-Projekten umsetze.


Testbarkeit von Anfang an

Aufgrund meiner langjährigen Entwicklungtätigkeit habe ich aus erster Hand erfahren, wie wichtig gute automatisierte Unit Tests sind. Damit man überhaupt gute Unit Tests schreiben kann, muss man diese von Anfang an inm Software-Design berücksichtigen. Mittlerweile bin ich ein großer Befürworter von Test-Driven-Design (TDD) geworden. In meinen Programmen setze ich dazu eine Kombination aus folgenden Techniken ein:

  • Dependency Injection in Verbindung mit IoC-Containern
  • Mocking Frameworks
  • Unit Testing Tools

Da ich hauptsächlich in C# und Delphi entwickle, habe ich mir für beide Sprachen die entsprechenden Kenntnisse angeeignet und in etlichen Projekten erfolgreich angewendet.


SOLID Principles / Deklaratives Programmieren

Für mich gehören die SOLID Principles zu den elementaren Entwicklungsgrundsätzen. Über die Jahre habe ich gemerkt, wie wichtig es ist, verständlichen Code zu schreiben. Lieber ein paar Sekunden länger darüber nachgedacht, wie man eine Methode, Klasse oder Variable benennt, als "mal schnell eben" irgendeinen Namen vergeben. Ich freue mich immer, wenn ich in einem Projekt auf guten, weil leicht verständlichen, Code stoße. Ich bin sicher, erfhrene Entwickler wissen genau, was ich damit meine.

Mit LINQ haben C# Programmierer die Möglichkeit bekommen, vieles deklarativ zu programmieren. Ich setze LINQ sehr gerne ein, weiß aber auch, dass man es damit übertreiben kann. Immer dann, wenn man etwas länger darüber nachdenken müsste, was ein LINQ Statement eigentlich macht, war es wohl zu viel des Guten.


Refactoring gehört einfch dazu

Kein Programmierer dieser Welt schreibt perfekten Code - und schon gar nicht im ersten Anlauf. Daher ist es unablässig, dass man seinen Code immer wieder etwas umbaut, wenn man sieht, dass es an einer Stelle "hakt". Lässt man es dagegen so, wie es ist, geht man im wahrsten Sinne eine Schuld ein. Das ist im Einzelfall vielleicht nicht so schlimm, aber je öfter man das macht, desto größer wird die Schuld und es kann zu spürbaren Problemen kommen. Auch hier bin ich sicher, dass erfahrene Programmierer genau wissen, was ich meine. Daher empfehle ich, Refactoring nicht als separate Aufgabe zu planen, sondern es im täglichen Ablauf aufgehen zu lassen. Man programmiert, man refactored, man programmiert, man refactored, usw. Nur wenn fundamentale Umstellungen notwendig sind, sollte man es separat im Projektplan aufnehmen.


Produktionsbetrieb im Auge

Viele Projekte werden sehr viel später und teurer als geplant beendet. Oftmals liegt es daran, daß sich zu spät überlegt wird, welche zusätzlichen Anforderungen das System in der eigentlichen Produktivumgebung erfordert. Daher achte ich früh auf mögliche Auswirkungen im Livebetrieb, um unangenehme Überraschungen zu vermeiden.


Wartbarkeit sicherstellen

Viele Entwickler programmieren planlos vor sich hin, um möglichst schnell eine lauffähige Version präsentieren zu können. Dabei vernachlässigen sie die Dokumentation des Codes / Designs völlig oder fertigen nachträglich aus dem Gedächtnis unbrauchbare Dokumente an.

Den Preis zahlen Sie als Auftraggeber, denn schlecht dokumentierte Programme sind ein erhebliches Projektrisiko. Denken Sie nur an etwaige Änderungen, die mit Sicherheit irgendwann kommen werden.

Bei meinen Projekten ist der Code zu jeder Zeit dokumentiert, um die beschriebenen Gefahren zu vermeiden.


Nutzer früh einbeziehen

Wer auch immer ein IT-System entwickeln will, dem rate ich, seine späteren Nutzer sehr früh in die Design- und Entwicklungsphase mit einzubeziehen.

Die Erfahrung zeigt, daß die notwedige Akzeptanz und Identifikation wesentlich größer sind, wenn Nutzer das Gefühl haben, sie haben mitgewirkt.


Orthogonal programmieren

Bei einem guten IT-System stehen die verwendeten Module orthogonal aufeinander. Das bedeutet, wenn ein Modul geändert wird, daß im Idealfall nur ein davon abhängiges Modul angepaßt werden muß. Oftmals findet man aber Systeme, bei denen etliche Kreuzabhängigkeiten existieren, die kaum zu überschauen sind.

Daher lege ich sehr viel Wert auf Orthogonalität bei meinen Designs und Projektberatungen.


Spät optimieren

Viele Entwickler begehen den Fehler, zu früh in der Entwicklung zu optimieren. So wird Zeit in einen Bereich des Codes investiert, der später vielleicht gar kein Problembereich für die Gesamtperformance ist.


Intuitive Benutzerführung

Man trifft immer wieder Entwickler, die graphische Benutzerfrontends so planen, wie sie am einfachsten zu programmieren sind. Stattdessen sollten sie sich lieber die Zeit nehmen, herauszufinden, wie man die Bedienung für den Benutzer vereinfachen könnte.

Weil dies in der Regel schwieriger zu programmieren ist, macht man sich nicht die Mühe. Da für mich die Nutzer die wichtigsten Kunden sind, gehe ich gerne diese »Extra-Meile«.


Keine Spielereien

Was Projekte oft teuer werden läßt, ist der Drang nach vielen Features. Es wird nicht analysiert, ob alle diese Funktionen tatsächlich benötigt werden.

Meine Erfahrung zeigt mir, daß man am besten mit den wichtigsten Funktionen beginnt und dann ein wenig mit dem System arbeitet. Man erkennt auf diese Weise sehr schnell diejenigen Features, die tatsächlich gebraucht werden.