Das KISS-Prinzip

Anfangs der 1960er-Jahren wurde von der amerikanischen Navy ein Grundsatz für gutes Design geprägt. Unter dem Akronym «KISS» verbirgt sich die Idee, alles möglichst einfach zu halten. KISS steht für

• Keep it simple, stupid
• Keep it simple & smart
• Keep it simple & sweet
• und so weiter.

Der Grundsatz besagt, dass man das Design so einfach wie möglich halten soll. Die Vereinfachung des Designs soll verschiedene Vorteile bieten. Das Prinzip lässt sich auf unterschiedlichste Bereiche anwenden. In einer Softwareentwicklung könnte man mögliche Vorteile wie folgt auflisten:

• bessere Übersichtlichkeit
• einfacher zu bedienen
• einfacher zu warten
• verwendet weniger Ressourcen.

Einfacher ist aus diesen Gründen besser. Das KISS-Prinzip hat sich in vielen Situationen als nützliche Idee erwiesen. Die Herausforderung liegt jedoch in der Vereinfachung.

Einfacher oder vollständiger?

Wie lässt sich das KISS-Prinzip anwenden? Gibt es für die Vereinfachung auch Grenzen?

Oft kann man eine Funktion auf einen einzigen Script-Schritt reduzieren. Wer etwas erreichen will und das durch einen einzigen Script-Schritt erreichen kann – anstelle durch viele komplexe Zwischenschritte – hat etwas gut verstanden. Das wäre analog dem KISS-Prinzip. Einfacher ist besser.

FileMaker ist stark in diesen Dingen, weil es komplexe Sachverhalte oft auf einen konfigurierbaren Script-Schritt reduziert. Allerdings ist diese Vereinfachung zwar zielführend, aber nicht immer maximal deutlich. Das möchte ich anhand eines Beispiels aufzeigen.

Stufe 1: Der Minimalist

Wer etwas mit nur einem Script-Schritt lösen kann, zeigt sich als Meister. Simple is beautiful. Das hat jedoch Grenzen. Bei vielen Script-Schritten lassen sich Berechnungen einfügen. In der Script-Übersicht sind diese Berechnungen meist nicht oder nur teilweise sichtbar.

Erst ein weiterer Klick und ein weiteres Fenster zeigen, welche Berechnung im Hintergrund liegt. So funktioniert das in FileMaker. Eventuell sieht man gar nicht, dass eine Berechnung hinterlegt ist. Dann ist zwar die Funktion sehr einfach, aber die Darstellung in FileMaker verhüllt auch bestimmte Abläufe. Das hat Vor- und Nachteile, ist jedoch für die Übersichtlichkeit nicht optimal.

Stufe 2: Der Erfahrene

Eine mögliche Lösung wäre es, die Berechnung durch einen Variablen zu ersetzen und die Variable selbst der Funktion vorauszusetzen. Man kann so vorgehen, dass Berechnungen immer in Variablen stattfinden. Der Name einer Variablen kann einen Hinweis auf die Berechnung liefern. Es wird übersichtlicher. Damit gäbe es zwei Scriptschritte:

• Setze Variable (mit Berechnung)
• Benutze Variable (in der eigentlichen Funktion).

Dieses Vorgehen teilt in zwei Schritte auf, was auch in einem Schritt ginge. Der Vorteil liegt hier nicht in der «möglichst kürzesten Umsetzung», sondern eher in der Übersichtlichkeit. Wer das Script aufschlägt, sieht in der Übersicht Variable und Anwendung in zwei Schritten nacheinander. Ein Schritt mehr kann verdeutlichen, dass hier etwas berechnet wird und damit kann die Übersichtlichkeit gedient sein.

Stufe 3: Der Weise

Die Überlegungen können noch weitergehen. Es kann hilfreich sein, zusätzlich ein kurzer Kommentar zu erfassen. Viele Entwickler haben festgestellt, dass eine gut-kommentierte Softwarelösung später einfacher zu warten ist. Ein Kommentar wird demnach im Hinblick auf die spätere, einfachere Wartung angelegt. Wir haben nun drei Zeilen:

• Kommentar
• Setze Variable
• Benutze Variable (in Funktion)

Evaluation der Entwicklung

Was ist jetzt besser, die kürzere direkte Umsetzung oder die besser lesbare Variante mit einer Erklärung für später? Mit diesem Beispiel möchte ich aufzeigen, dass das KISS-Prinzip gut ist, jedoch können Gründe dafür sprechen, eine Aufgabe etwas ausführlicher umzusetzen.

Wo liegt hier der Unterschied? Der Unterschied liegt in der Bewältigung der Komplexität, aber auf zwei verschiedene Ebenen.

1. Die Funktionalität
   Wer ein komplexer Vorgang auf einen einzigen korrekten Script-Schritt reduzieren kann, hat die Möglichkeiten von FileMaker (oder einer anderen Entwicklungsplattform) gut erfasst. Das ist der Kern, um den es geht. Die Bewältigung der Komplexität konnte durch eine starke Vereinfachung erreicht werden.
2. Die Darstellung
   Die beiden weiteren Zeilen, die nun hinzugefügt werden (Kommentar und Variable) befassen sich nicht mehr mit der Funktionalität, sondern verbessern lediglich die Darstellung. In der Übersicht ist dadurch auf Anhieb klar, was gemeint wird (Kommentar) und wo man eine Berechnung prüfen sollte (Variable).

Es gibt so viele Meinungen zum Thema, wie es FileMaker-Entwickler gibt. Mir geht es hier nicht darum, zu entscheiden, was wichtig ist, oder wie man etwas machen «sollte». Dieser Beitrag ist bloss eine Reflexion. Heute sehe ich deshalb die drei genannte Schritten als Entwicklungsansätze:

1. Funktion (Minimalismus)
2. Variable (Erfahrung)
3. Kommentar (Weisheit)

Besonders wichtig: Der Minimalist hat gute Gründe, genau so vorzugehen, und keine Zeile zu viel zu schreiben. Wer Berechnungen sichtbar macht, hat aus seiner Erfahrung gelernt, dass dadurch die Scripts besser lesbar sind. Wer ausserdem noch Kommentare hinzufügt, hat verstanden, dass er selbst nach einem Jahr vermutlich nicht mehr weiss, warum das Script so und nicht anders geschrieben wurde. Von jedem Ansatz lässt sich etwas lernen.

Vereinfachung der FileMaker Entwicklung

Das KISS-Prinzip ist nur eines von vielen Möglichkeiten, eine Vereinfachung anzustreben. Selbstredend gibt es weitere Möglichkeiten, die FileMaker Entwicklung zu vereinfachen. Dabei stelle ich fest, dass es verschiedene Ansätze gibt. Welche Variante man bevorzugt, hängt möglicherweise vom eigenen Temperament ab oder von besonderen Anforderungen des gerade aktuellen Projektes. Welche sind die Varianten?

1. Mehr Regeln
   Einige streben Systeme an, worin alle Details der Entwicklung definiert sind. Es gibt nicht bloss «best practices», sondern man stellt ein Regelwerk auf, wonach sich der Entwickler zu richten hat. Für alles gibt es eine Definition: Wie man Dinge benennt (etwa Feldnamen, Tabellen, Layouts), wie man sie referenziert und welche Konzepte für die gesamte Applikation gelten.
   Nachteil eines Regelwerkes: Es kann ein Eigenleben anfangen und viele Ressourcen und Zeit binden.
   Bedenkenswert: Ein Regelwerk soll dem Entwickler helfen und der Entwickler soll nicht dem Regelwerk dienen.
2. Weniger Regeln
   Andere, vermutlich die meisten Entwickler, richten sich nach «best practices» und einem reduzierten Regelwerk. Ganz ohne eigene Vorgaben wird man nicht auskommen, aber der Fokus liegt nicht auf dem Regelwerk, sondern auf einer Struktur. Die Struktur soll dem Entwickler helfen, sich jetzt und auch in Zukunft zurechtzufinden. Nicht «wie» man etwas macht, sondern «wo» man etwas findet, steht zentral.
   Nachteil eines Struktur-Prinzips ist gerade die Freiheit des Entwicklers.
   Bedenkenswert: Entwickler tun gut daran, sich bewusst eine Struktur zurechtzulegen und diese konsequent zu nutzen.

Die Vereinfachung der Entwicklung hat immer etwas von einem Abenteuer. Welche Dinge sich bewähren, wird man erst im Nachhinein feststellen. Man braucht den Mut, nicht nur aus der eigenen Erfahrung, sondern auch von anderen Kollegen dazuzulernen, Fehler zu machen, und bewährte Ansätze sukzessive in die eigene Arbeit einfliessen zu lassen.

Wer lernend unterwegs ist, wird feststellen, dass man sich ändert, mit der Zeit bessere Entscheidungen trifft und rückblickend vieles etwas chaotisch gemacht hat. Es braucht Mut zur Lücke, wenn man das feststellt. Selten nämlich lassen sich die alten Fehler neu programmieren. Manchmal jedoch ist es unerlässlich. Dieser Prozess ist spannend und es gibt Methoden, den Schmerz in Grenzen zu halten. Vereinfachung ist eines dieser Methoden.

KISS: Keep it simple & smart.