Unsere Architekturphilosophie: Modular denken, flexibel bleiben

Stellen Sie sich vor, Sie haben Ihre Telefonnummer auf zehn verschiedenen Notizzetteln, in mehreren Kontaktlisten und Formularen notiert. Bekommen Sie eine neue Nummer, müssen Sie jede einzelne Stelle finden und ändern – und übersehen garantiert eine, sodass jemand Sie weiterhin unter der alten Nummer erreichen will. Im Programmieren passiert genau das, wenn dieselbe Funktion an mehreren Stellen doppelt geschrieben wird.

Ein Alltagsbeispiel: Eine Website hat zwei Login-Buttons, einen in der Navigation und einen auf der Startseite. Wird die Login-Logik für jeden Button separat programmiert, entsteht doppelter Code. Tritt nun ein Fehler beim Login auf, muss er an zwei Stellen gleichzeitig behoben werden: doppelte Arbeit, doppeltes Fehlerpotenzial.

Die DRY-Lösung: Die Login-Funktion wird einmal geschrieben und von beiden Buttons gemeinsam genutzt. Änderungen oder Fehlerbehebungen sind dann nur noch an einer einzigen Stelle nötig. Das spart Zeit, reduziert Fehler und macht den Code wartungsfreundlicher.

Komplizierter Code ist nicht automatisch besserer Code. Das KISS-Prinzip erinnert Entwickler daran, Lösungen so einfach wie möglich zu gestalten, ohne unnötige Verschachtelungen, Umwege oder überflüssige Schritte.

Ein anschauliches Beispiel aus dem Alltag: Um herauszufinden, ob eine Zahl gerade ist, könnte man kompliziert vorgehen: die Zahl durch zwei teilen, das Ergebnis zwischenspeichern, prüfen, ob dabei ein Rest übrig bleibt, dieses Ergebnis erneut ablegen und erst danach die endgültige Antwort zurückgeben, fünf Schritte für eine eigentlich einfache Frage. Einfacher geht es mit einer einzigen, klar verständlichen Prüfung: Bleibt bei der Division durch zwei kein Rest, ist die Zahl gerade. Beide Varianten kommen zum exakt gleichen Ergebnis, aber die zweite ist auf einen Blick verständlich.

Warum ist das wichtig? Code wird viel öfter gelesen als geschrieben. Einfacher Code spart nicht nur beim Schreiben Zeit, er spart vor allem beim späteren Lesen, Prüfen und Anpassen Zeit. Das gilt besonders, wenn neue Teammitglieder eingearbeitet werden oder wenn Code nach Monaten wieder angefasst wird.

„Naming is hardest in programming“, dieser Satz kursiert unter Entwicklern als halb scherzhafter, halb ernster Hinweis auf eine alltägliche Herausforderung: Dinge sinnvoll zu benennen.

Clean Code geht über Rechtschreibung hinaus: Es geht darum, dass jede Variable, jede Funktion und jede Datei so benannt ist, dass ihr Zweck sofort klar wird, ganz ohne Kommentar oder Erklärung. Eine Funktion namens ist_gerade sagt sofort: „Diese Funktion prüft, ob eine Zahl gerade ist.“ Eine Funktion namens x sagt: gar nichts.

Clean Code umfasst außerdem konsistente Einrückung, klare Strukturierung und das Vermeiden von unnötigen Abkürzungen. Das Ziel: Code soll sich lesen wie ein gut geschriebener Text, auch für jemanden, der ihn zum ersten Mal sieht.

Separation of Concerns (auf Deutsch: Trennung der Zuständigkeiten) ist vielleicht das anspruchsvollste der vier Prinzipien. Die Grundidee: Jeder Teil des Systems soll genau eine klar definierte Aufgabe haben, und verschiedene Aufgaben sollen sauber voneinander getrennt sein.

Ein Vergleich aus dem Alltag: Stellen Sie sich eine Firma vor, in der Buchhaltung, Personalwesen und IT alle in denselben Aktenordner ablegen. Auf den ersten Blick spart das Platz, aber spätestens beim Suchen nach einer bestimmten Akte entsteht Chaos. Klare Zuständigkeiten und getrennte Ablagesysteme machen das Unternehmen effizienter.

Genauso verhält es sich in der Softwarearchitektur: Wenn unterschiedliche Aufgabenbereiche sauber getrennte Zuständigkeiten haben, statt an einer Stelle vermischt zu werden, bleibt das System übersichtlich, leichter erweiterbar und einfacher zu warten. Bei Geovision setzen wir dieses Prinzip konsequent um, von der Datenbankstruktur bis zur Aufteilung einzelner Programmfunktionen.