Thomas Gerlach

Zwei Leitsätze meiner Programmierung

Im Laufe eines Berufslebens sammelt wohl jeder Programmierer seine zum Teil ganz persönlichen Erfahrungen, die schließlich zu einem Repertoire an Vorlieben und Abneigungen bezüglich Programmiertechniken und Vorgehensweisen führen. Wie schön wäre es doch für Auftraggeber im voraus zu erfahren, was das potentiell neue Mitglied des Entwicklerteams antreibt.

Redundanzfreiheit

Tu nie etwas zweimal. Redundanz ist eines der zuverlässigsten Indizien für schlechtes Design.

Redundanz ist in der Softwareentwicklung in unterschiedlichen Formen anzutreffen:

  • Es gibt algorithmische Redundanz, der man mit Mitteln der Wiederverwendung begegnen kann. Mindestens die Hälfte aller Programmierparadigmen und Architekturmuster beschäftigt sich im Grunde genommen mit Wiederverwendung. Ob klassische Zerlegung von Funktionalitäten in wiederverwendbare Module, Klassen und Libraries, ob beidseitig lose Kopplung mittels Interfaces, Dependency Injection oder SOA, vieles was Softwarearchitektur angeht, beschäftigt sich mit der Frage, wie Systeme aus Einzelteilen neu komponiert werden können.
  • Des weiteren gibt es aber auch deklarative Redundanz, bei der viel Code geschrieben werden muss, obwohl die inhaltliche Information nur sehr wenig enthält. Als Beispiel sei OR-Mapping genannt. Dieser deklarativen Redundanz kann durch generative Ansätze, wie z.B. Codegeneratoren oder Codeinjizierung begegnet werden.
  • Sich wiederholende Tätigkeiten sind ebenfalls eine Form der Redundanz. Sollte ein Programmierer dreimal hintereinander das gleiche tun, ist es zumindest Wert darüber nachzudenken, den Ablauf zu automatisieren. Eine typische sich wiederholende Handlung ist z.B. der Test von Programmkomponenten. Darum sind automatisch ausführbare Tests so hilfreich. Sie sparen nicht nur Projektzeit, sie steigern auch die Qualität der Software, weil in der Regel erst die Automatisierung die nötige Testintensität ermöglicht. Außerdem gilt für den Test das Gleiche wie für Programmcode: Der Test selbst muss getestet werden. Ein automatischer Test muss nur einmal entwickelt und geprüft werden. Ein vielfach manuell durchgeführter Test kann leicht fehlerhaft durchgeführt werden.

Automatische Validierung

Betrüge nie Deinen Compiler

Man darf die Vorteile nicht unterschätzen, die sich aus automatischer Validierung von Quellcode ergeben, wie sie z.B. von Compilern vorgenommen wird. Darum ziehe ich eine Compiler-prüfbare typsichere und 'enge' Definition von Schnittstellen in jedem Fall einer vermeintlich 'weiten' gummi-flexiblen Definition von Schnittstellen vor. Beispielsweise sind "object[]" Parameter und String-Identifier zu vermeiden. Gemeint ist nicht, Schnittstellen unflexibel zu gestalten, sondern die korrekte Nutzung der Schnittstelle zur Codierzeit automatisch validierbar zu gestalten.