Softwaredesign #1 - Von Küssen, KISS und Schönheit. Size doesn't matter? KISS - Keep it short and simple!

  • Wie muss ich meine Software aufbauen? Wie garantiere ich den Fortbestand meiner Software für die Ewigkeit? Ist das so oder so eleganter? Diese und viele weitere Fragen wollen wir im Folgenden klären.

    Hey Leute,


    ich möchte euch in den folgenden Wikiartikeln ein wenig zur Hand gehen und euch helfen, das Design eurer Software zu überdenken und vielleicht auch in Zukunft zu verbessern. Es gibt eine Menge Richtlinien und Prinzipien anhand derer man versuchen kann, seine Software so dynamisch und elegant wie möglich umzusetzen. Aus diesem Haufen an Prinzipien möchte ich versuchen, ein paar grundlegende Dinge herauszuarbeiten und für kurz und knackig zu präsentieren. Wie immer sind meine Werke nicht perfekt und ich freue mich immer, wenn Leute mit mehr Erfahrung als ich dazu beitragen möchten, mehr aus dem was ich bereits vorgegeben habe herauszuholen.



    Keep it short and simple (KISS)

    Es geht hier (leider) nicht ums Küssen. Bei Kiss geht es viel mehr darum, den Überblick über euren Code zu nutzen, um ihn kurz und einfach zu halten. Manchmal kommt der Punkt an dem auch ich Software nicht verstehe. Man sieht sich den Code an und denkt: Ganz schöner Schinken, den auf ein Brötchen, dann etwas... das könnte etwas dauern bis ich den verstehe. Das liegt manchmal nicht einfach an der Komplexität eines Algorithmus, sondern daran wie unnötig kompliziert er umgesetzt wurde. Ab und zu wird mir gesagt, ich sei nicht fortgeschritten genug, ich behaupte dass jeder Code den man nicht durch überlegtes und intensives Lesen verstehen kann ein Haufen Scheiße uncool ist. In diesem Sinne:


    Zitat

    Keep it short and simple


    Sehr wörtlich übersetzt:Halte es kurz und simpel.


    Man kann das natürlich kritisieren. Auch wenn Interesse an der generellen Rezession der Applikation relativ primitiver Methoden komplementär zur Favorisierung adäquater komplexer Algorithmen existiert, wer macht etwas freiwillig schwieriger als es sein muss. Wenn man jedoch etwas darüber nachdenkt, ertappt man sich vermutlich selbst oft dabei, es unnötig kompliziert zu machen. Manchmal denkt man sich » Das wär doch voll cool und sieht fortgeschritten aus «. Oder man hatte einfach nicht die Zeit, sich mit Refactoring zu beschäftigen und zu merken, dass das eigentlich viel einfacher geht. Manchmal mag auch die Lösung gar nicht das Ziel sein, je nachdem welche Anforderungen man hat. Nach Matthias Geirhos kann man sich folgende Fragen stellen und der Lösung einen Spiegel vorhalten:

    1. Ist die Anforderung präzise genug? Oder hat meine Lösung etwa etwas, das gar nicht gefordert war?
    2. Ist die Lösung überhaupt wichtig genug um Zeit hinein zu investieren ( beachte premature optimization )?
    3. Ist die Lösung in wenigen Schritten einem Aussenstehenden verständlich zu machen?
    4. Ist die Lösung so designed, dass ich selbst von mir sagen kann, dass ich sie jederzeit, auch noch in Jahren bis ins Detail verstehe?


    Auch erklärt er, die einfachere Lösung hätte verführerische Vorteile:

    1. Die einfachere Lösung ist leichter zu bedienen.
    2. Die einfachere Lösung ist schneller verständlich und benötigt weniger Erklärungen und Schulungen im Umgang.
    3. Die einfachere Lösung macht die Leute glücklicher, eine komplexere stiftet oft Verwirrung und Unglück.
    4. Die einfachere Lösung ist einfacher zu überblicken und zu testen.
    5. Die einfachere Lösung ist leichter wiederverwendbar und wartbar.


    Auf dem Weg zur einfachen Lösung muss man jedoch eine ganze Menge an Stolpersteinen überwinden. Man steht sich oft selbst im Weg. Es soll perfekt sein, meine Lösung soll die Perfektion darstellen, einen Olymp aus Harmonie und Schönheit. Doch was ein Entwickler als wunderschön empfindet, wenn er sich sein Konstrukt ansieht, kann für jeden anderen die Hölle sein.


    Zum Schluss ein Zitat von Albert Einstein gefolgt von einem von Blaise Pascal:

    Zitat

    So einfach wie möglich, aber nicht einfacher.


    Entschuldigen SIi, dass ich Ihnen einen langen Brief schreibe, für einen kurzen habe ich keine Zeit?


    Was soll euch das jetzt sagen? Ganz einfach: Keep it short and simple. Nehmt euch die Zeit, eure Lösung zu überdenken. Refactoring ist kein Hexenwerk und man darf sich damit beschäftigen, es geht bei eurem Code niemals nur um euch. Wenn ihr es schon nicht für euch tut, dann bitte für alle anderen. Es darf auch ruhig mal schwer sein, eine Lösung zu verbessern. Nehmt euch jedoch in Acht. Es ist ein Prinzip. Erzwingt es nicht, ähnlich wie bei Design Pattern. Denn, wie Donald Knuth in Computer Programming as an Art beschrieb:

    Zitat

    The real problem is that programmers have spent far too much time worrying about efficiency in the wrong places and at the wrong times; premature optimization is the root of all evil (or at least most of it) in programming.


    Ich hoffe ich konnte euch das erste Design Prinzip näher bringen. KISS.


    Mit freundlichen Grüßen

    Nathalie


    Einzelnachweise
    1. Matthias Geirhos, Entwurfsmuster - Das umfassende Handbuch

Teilen