Indikatoren für schlechtes Design / Softwarearchitektur

Wie der Titel bereits verrät, geht es in diesem Artikel um Indikatoren, an denen man schlechte Softwarearchitektur erkennen kann. Generell sollte man aber zuvor das Lasten-/Pflichtenheft des Projektes gelesen haben, um sich überhaupt ein Urteil erlauben zu können. Denn nicht jeder Auftraggeber verlangt oder legt wert auf: Wartbarkeit, Flexibilität oder Erweiterbarkeit. Die folgende Grafik veranschaulicht die 7 wichtigsten Indikatoren:

Starrheit

Software hat die Tendenz sich Änderungen zu widersetzen. Es fehlt der Weitblick bei der Planung und das führt dazu, dass jede kleine Änderung eine Flut von weiteren Änderungen nach sich zieht. Somit sinkt die Produktivität im Projektverlauf und führt zum ständigen redesignen der Anwendung.

Zerbrechlichkeit

Ein häufiges Problem von älteren Programmen ist die Zerbrechlichkeit. Selbst eine kleine Änderung im Quellcode führt dazu, dass an anderen Stellen Fehler auftreten, die konzeptuell nicht mit der eigentlichen Änderung zusammenhängen. Es muss damit gerechnet werden, dass das Programm aufgrund einer kleinen Modifikation nicht mehr funktioniert oder startet. Die Folge ist, dass man notwendige Restrukturierungsmaßnahmen nicht mehr umgesetzt werden.

Beim Auftreten dieses Indikators wurde von der IT-Abteilung die so genannte „Jedi“-Technik entwickelt. Dabei wird mit Hilfe der Macht dem System Owner/Anwender/etc. eingeredet: „Du willst diese Änderung nicht haben!“

Unbeweglichkeit

Je nach Möglichkeiten der Programmiersprache lassen sich Programme oder Programmteile in verschiedene Module aufteilen. Identifiziert man ein nützliches und brauchbares Modul, gestaltet es sich oft schwierig dieses Modul von anderen Modulen zu trennen. Dies führt dazu, dass der Quellcode nicht wiederverwendet, sondern kopiert wird. Diese Redundanzen erhöhen extrem den Wartungsaufwand und werden oftmals nicht dokumentiert.

Zähigkeit

Meist gibt es mehrere Varianten ein Problem zu lösen oder eine Erweiterung vorzunehmen. Davon sind einige designkonform und andere wiederum nicht. Diese nicht mit dem Design vereinbare Änderungen bezeichnet man als „Hacks“ oder „kludge“. Wenn es also schwieriger ist, eine konforme Lösung zu implementieren, spricht man von einem zähen Design. Mehrere Hacks verschlechtern die Wartbarkeit und erhöhen die Komplexität der Software.

Eine weitere Form der Zähigkeit tritt im Workflow der Entwicklung auf. Dauert das Kompilieren der Software sehr lange, scheuen sich die Entwickler davor Änderungen vorzunehmen, die eine Neuübersetzung der Software zur Folge haben. Einen ähnlichen Effekt bewirkt eine zu komplexe Versionsverwaltung oder eine schlechte IDE.

Kompliziertheit

Der erste Indikator „Starrheit“ fordert vom Entwickler/Architekten weitblickend zu entwerfen/programmieren. Übertreibt man diesen Ratschlag, ist der Aufbau der Software komplizierter als es die Komplexität der Aufgabe erfordert. Dabei wird haufenweise zusätzliche Flexibilität eingebaut, um auf zukünftige Änderungen vorbereitet zu sein. Dies verkompliziert das Design, ohne zur Problemlösung beigetragen zu haben. Es muss also mehr Code gewartet werden als nötig.

Ein Beispiel aus der Praxis: Wie wahrscheinlich ist es, dass kleine grüne Männchen auf der Erde landen und brauchen diese eine Lebensversicherung? Und was machen wir, wenn sie rot oder blau sind?

Unnötige Redundanz

Die selben Konzepte bzw. Anforderungen werden an unterschiedlichen Stellen im Design oder Entwurf redundant ausgearbeitet. Die einfachste Form entsteht durch Copy- und Paste-Programmierung. Die Folge ist, dass vorhandene Abstraktionen nicht erkannt und als solche herausgearbeitet werden. Somit muss eine Änderung an mehreren Stellen konsistent durchgeführt werden.

Unverständlichkeit

Die verschiedenen Einheiten und Ebenen der programmierten Software sind schwer zu durchschauen. Schlechte Namensgebung und ungünstige Strukturierung erschweren die Einarbeitung in die Software und damit die Überarbeitung / Erweiterung. Bestehende Konzepte und Konventionen werden vergessen oder weg gelassen.