Montag, 8. Oktober 2012

Wieso gutes Softwaredesign so schwierig ist

Ein Grundsatz von dem ich absolut überzeugt bin ist: Software steht und fällt mit ihrem Design!. Die Oberfläche mag für den Benutzer das wichtigste sein, und eine schlechte Oberfläche sorgt auch dafür, dass Software nicht verwendet wird. Nun kommt das dicke ABER, denn eine gute Benutzeroberfläche lässt sich in einem guten Design auch leichter realisieren. Was für Vorteile bringt ein gutes Softwaredesign noch?
  • Leichtere Fehlerbehebung, da Fehler einfacher gefunden werden können und ihre Beseitigung keine (im Optimalfall) weiteren Fehler verursacht.
  • Leichtere Erweiterbarkeit, die Struktur flexibel ist und neue Anforderung einfach integriert werden können.
  • Leichtere Änderbarkeit von detaillierten Modulen durch wenig Abhängigkeiten.
  • Gute Wiederverwendbarkeit, da die Komponenten klar getrennt sind.
Man sieht also: gutes Design hat eigentlich nur Vorteile. Warum ist es dann so schwer dieses Umzusetzen? Die Antwort ist denkbar einfach und typisch Mensch: Die Faulheit des Entwicklers. Und ich möchte mich hier weiß Gott nicht ausschließen :) Ganz zu Beginn eines Projektes ist noch alles gut. Man hat sich ein tolles, simples, den Anforderungen entsprechendes Design überlegt und ist auch schon fleißig dabei dieses umzusetzen, da kommt der Auftraggeber und will auf einmal noch zusätzlich dies und jenes. Und achja wenn diese Funktion doch ein bisschen anders wäre.... Und das Unheil beginnt! Da man ja schon mitten in der Implementation ist versucht man die Änderungen irgendwie mit rein zu wursteln. Da wird hier halt noch auf diese Klasse zugegriffen und dort noch ausnahmsweise eine zusätzliche Abfrage implementiert. "Halt noch" und "ausnahmsweise" sind hier allerdings fatal, denn dies wird kein Einzelfall bleiben und eigentlich weiß man das auch, aber es ist nunmal jetzt gerade so viel komfortabler zu entwickeln. Dieser Prozess wir in eine endlose Schleife laufen und das wissen wir alle und je öfter dies passiert um so mehr verkümmert und erodiert das Design und die Software. (Hier spricht man auch von Softwareerosion)

Es gibt natürlich Regeln an die man sich halten kann um gutes Design zu gewährleisten, aber das größte Problem liegt hier tatsächlich an der Gewohnheit des Entwicklers. Zunächst muss man sich die richtige Einstellung aneignen um anschließend mit den richtigen Vorgehensweisen auch effektiv arbeiten zu können. Nehmen wir hier als Verbildlichung eine Küche. Die Küche ist unser Programm. Ist die Küche ordentlich, hat unser Programm eine ordentliche Architektur, eine unordentliche Küche repräsentiert hingegen ein schlechtes Design. Das Kochen ist die Implementierung. Beim Kochen wird die Küche nun unordentlich, das lässt sich nicht vermeiden. Was tun wir also? Wir räumen auf! Oftmals fehlt aber die Lust aufzuräumen und man lässt es bleiben. Dadurch vermehrt sich das Chaos bis es fast unbezwingbar ist. Wir als Entwickler müssen uns also angewöhnen die Küche immer sofort aufzuräumen statt irgendwann später. Ebenso müssen wir versuchen beim Kochen so wenig Unordnung wie möglich zu verursachen. Eine Anforderung eben schnell schmutzig implementieren, weil man ja später Aufräumen kann erhöht den Aufwand fürs Aufräumen und verringert die Motivation die Aufräumarbeiten durchzuführen.

Zusammenfassend kann man sagen: gutes Softwaredesign ist so schwierig weil wir es und schwer machen. Mit Disziplin und der richtigen Einstellung ist gutes Design einfach umzusetzen und spart Nerven und Arbeit.

2 Kommentare:

  1. Die Faulheit bzw. Bequemlichkeit des Entwicklers ist denke ich nur ein kleiner Teil des Grundes warum zur Mitte eines Softwareprojektes mehr nach dem "quick 'n' dirty" Schema gearbeitet wird...
    Ganz oft ist es auch eine Frage der Ressource Zeit und Budget, warum vom Softwarearchitekturentwurf abgewichen wird.
    Änderungen benötigen Zeit wenn man sie gut in das bestehenden Design einarbeiten will.
    Software bildet meistens Probleme der realen Welt ab, welche vorwiegend aus dem ökonomischen Sektor stammen. In sehr vielen dieser Branchen passieren sehr häufig Änderungen, welche dann in das Projekt einfließen sollen. Der Risikofaktor "Kurzfristige Änderungen" muss daher bei solchen Branchen entsprechend realistisch berücksichtigt werden. Denn mit die meisten Fehler passieren beim Risiko- und Krisenmanagement. Viele Designfehler lassen sich durch kontinuierliches aktualisieren und validieren der Anforderungsspezifikation vermeiden. Je früher ein Fehler im Design gefunden wird, desto günstiger ist seine Behebung.

    AntwortenLöschen
  2. Ja, du hast Recht, Änderungen benötigen mehr Zeit wenn man das Design anpasst, als wenn man sie "quick'n'dirty" umsetzt. Allerdings ist es im Nachhinein aufwändiger diese zu beheben. Und wenn man das Design flexibel genug entwirft können auch kurzfristige Änderungen zeitnah umgesetzt werden ohne das Design dabei zu verschlechtern. Diese Änderungen sind ja zumeist auch nicht absolut aus der Luft gegriffen und durchaus zu berücksichtigen, bzw. die Möglichkeit der häufigen Änderung kann berücksichtigt werden und somit das Design an den kritischen Stellen besonders leicht Änderbar gemacht werden.

    AntwortenLöschen