Design Prinzipien in der Software Entwicklung

Ich möchte hier meine Design-Prinzipien vorstellen, mit denen ich meine Software entwickle. Sie sorgen meiner Meinung nach dafür, das Software leichter zu warten und weiterzuentwickeln ist.


1

Mensch über Maschine

Lesbarkeit und Verständlichkeit

Ich habe oft Code lesen müssen, der von einem Entwickler so geschrieben wurde, dass er für andere, nicht direkt Beteiligte, nur schwer zu lesen war. Um das zu vermeiden, halte ich mich stets an folgende Prinzipien:

  • Implementiere die Logik so einfach wie möglich.
  • Jede Funktion tut genau eine Sache. Diese ist durch den Funktionsnamen festgelegt.
  • Trenne fachliche und technische Implementierungen.
  • Variablen-Namen in Funktionen müssen im Kontext der Funktion verständlich sein.
  • Klassenvariablen müssen im Kontext der Klasse verständlich sein.
  • Vermeide Zustandsvariablen, im besten Fall ist eine Klasse zustandslos.
  • Vermeide Weichen. Vermeide IF-ELSE.
  • Weniger Zeilen für dieselbe Funktion sind (meistens) besser.

2

Testen

Vertrauen in die Laufzeit

Eine ungetestete Funktion ist eine technische Schuld, die mit Zinsen zurück gezahlt werden muss.
Nicht selten wird Code nicht getestet. Meist ist es der Glaube an eine Zeitersparnis. Klar benötigt der Aufbau von guten Tests Zeit, oft sind es noch einmal 50-100% auf die eigentliche Entwicklungszeit. Diese Zeitersparnis zahlt der Entwickler oder das Team aber unzählige Male zurück. Sei es bei Abstürzen zur Laufzeit, Hotfixes, um den Code doch noch irgendwie schnell zum Laufen zu bekommen oder in debugging Kaskarden.

  • Tests schaffen Vertrauen in die Laufzeit.
  • Teste jede Funktion einzeln.
  • Die Struktur des Testordners sollte der des Source-Ordners entsprechen.
  • Lege den Test zusammen mit der Funktion an.
  • Teste mindestens 2 valide Aufrufe.
  • Teste jeden Fehlerfall.

3

Konfiguration

Eine Anwendung für alle Umgebungen

Die Konfiguration von Anwendungen ist ein wichtiger Bestandteil jeder Applikation. Sämtliche Variablen, die nicht zur Anzeige für den Operator oder Anwender bestimmt sind, gehören in eine zentrale Konfigurationsdatei. Vermeiden Sie jegliche Annahmen über die Zielumgebung. So bleibt die Anwendung kompatibel mit der Zukunft.

  • Für Konfigurationsdateien sollte das JSON oder YAML Format genutzt werden.
  • Beim Start der Anwendung müssen ein oder mehrere Pfade zu den Konfigurationsdateien angegeben werden.
  • Standardwerte können in eine Default-Konfiguration eingepflegt werden.
  • Die Default-Konfig darf keine sicherheitsrelevanten Variablen beinhalten.
  • Die Default-Konfig wird eingecheckt.
  • Die Default-Konfig wird mit dem Artefakt ausgeliefert.
  • Bei der Angabe von mehreren Konfigurationsdateien werden die Dateien in der Reihenfolge gemergt, wie sie übergeben wurden.
  • Eine zentrale Klasse liest die Konfiguration, übernimmt das Mergen und liefert Variablen an die entsprechenden Laufzeitklassen.

4

Dependencies

Stabilität durch Pinning, Sicherheit durch Upgrades

  • Pinnen Sie die Major- and Minor-Version von Abhängigkeiten fest, dadurch sollte der Build zuverlässig laufen.
  • Führen Sie regelmäßig Upgrades der Minor-Version durch (bspw. alle 14 Tage), kontrollieren Sie die Lauffähigkeit des Builds und aller Tests vor dem Merge auf 'main'.
  • Warten Sie nach dem Erscheinen neuer Major-Versionen ein paar Wochen, sodass anfängliche Probleme behoben werden können.
  • Planen Sie ein Upgrade aller Major-Versionen in einem Sprint-Ticket und führen Sie notwendige Anpassungen der Applikation an ggf. neue API-Parameter durch.
  • Bauen Sie täglich Ihre Applikation automatisiert.

technische Details:

Version:

Buildtime: 01.01.1970 00:00:00

Die letzte Aktualisierung ist 55 Jahre her

© 2009 - 2025 - Hans Fischer - All rights reserved.