KISS - Keep it Simple

In der IT-Welt begegnet man ständig neuen Begriffen, den sogenannten Buzzwords. Für jede Marketing-Abteilung ein gefundenes Fressen, haben sie aus der Entwicklersicht viel praktischeren Nutzen als werbewirksame Aussagen. Eine weitere dieser Abkürzungen ist das KISS Prinzip. Es steht für Keep It Stupid Simple oder auch Keep It Simple, Stupid. Frei übersetzt meint es also, gestalte Dinge möglichst schlicht und einfach. Etwas formeller ausgedrückt: So aufwendig wie nötig, so einfach wie möglich. Das ist gerade als Anfänger ein unheimlich guter Wegweiser, weshalb wir das hier näher vorstellen möchten.

KISS the frog? Keep It Simple, Stupid!

Warum also eine solch “freche” Aussage als Paradigma annehmen? Die Antwort ist vielschichtig. Gerade als Anfänger lernt man so bereits die scheinbar großen Aufgaben und Anforderungen bei der Programmierung in kleine Einheiten zu unterteilen. Ein häufiger Fehler bei Entwicklern: Die Aufgaben werden in zu großen Blöcken bearbeitet.

Jede Funktion sollte, als Richtlinie, immer nur eine Aufgabe übernehmen. Zudem gilt die Richtlinie, dass eine Subroutine nur etwa 100 Zeilen Code lang sein sollte. Wird es deutlich mehr, sollte man versuchen weiter zu unterteilen.

Ein großer Vorteil ist zudem die Geschwindigkeit, mit der man entwickeln kann. Wenn man vorab die Aufgaben fein genug aufteilt, muss man am Ende “nur” noch die geplante Struktur mit Code füllen. Das geht schneller als über “try & error”, also ausprobieren und aus Fehlern lernen. Hinzu kommt, dass jede Software bessere Strukturen bekommt, wenn man sie vorab plant.

Dementsprechend ergeben sich am Ende weniger Zeilen Quellcode, weniger komplexe Programme und auch lesbarer Code. In der Regel ist lesbarer Code auch weniger fehleranfällig. Die gesamte Software wird also robuster, wenn man versucht sie möglichst einfach zu halten. Ein weiterer Aspekt ist an der Stelle die Wartung, Pflege und die Anpassung in der Zukunft. Wenn man logische und übersichtliche Funktionen vor sich hat, kann man die besser verstehen und nachvollziehen als große Codeblöcke über mehrere hundert Zeilen.

Ein Beispielfall

Theorie ist immer geduldig. Doch wie lässt sich dieses Wissen in der Praxis anwenden? Hier ein Beispiel:

Aufgabe: Wir erstellen ein Softwaremodul, dass alle Benutzer aus der Datenbank lesen und ausgeben soll. Wir könnten also bspw. folgende Unterteilung vornehmen. Am besten wäre natürlich eine grafische Planung:

  • eine Datenbank-Klasse (DB) klingt sinnvoll!
    • connect() – eine Methode um die Verbindung zur Datenbank herzustellen
    • getData() – eine Methode zum Abruf von Daten, Rückgabe z.B. ein Array mit gefundenen Zeilen
  • eine Benutzer-Klasse (User) wäre gut
    • getUsers() – Methode zum Abruf von allen Benutzern, ruft dazu DB::getData() auf

Das ist natürlich nicht die komplette Architektur, aber ein Ansatz. Grob sind dies die Methoden und Klassen, die benötigt werden. Sicher muss irgendwie auch connect() aufgerufen werden. Der Fokus im Beispiel liegt mehr auf der Unterteilung und der genauen Zuweisung von einer Aufgabe pro Methode.

Ein Anfänger könnte aber geneigt sein einfach eine große Methode zu schreiben, in der alle Aufgaben hintereinander abgearbeitet werden.

KISS in der Praxis – Grundlegendes

Hört sich gut an? Wie so oft! Doch wie überträgt man nun genau KISS von der Theorie in die Praxis? Ganz allgemein sollte man bei der Entwicklung IMMER folgendes Schema befolgen:

  1. Probleme und Aufgabenstellungen zuerst durchdenken.
  2. Grober Entwurf vorab (Struktur auf Papier malen und/oder mit Pseudo-Code).
  3. Ableiten der Klassen, Funktionen und Methoden vorab.
  4. Erst dann implementieren (entwickeln).

Hier einige Richtlinien für Dich, mit denen der Übergang zum Programmieralltag einfacher werden sollte:

  • Bei der Entwicklung öfter hinterfragen, ob Logik in eigene Funktionen ausgelagert werden kann.
  • Bedenke: Methoden und Funktionen erledigen immer nur eine Aufgabe.
  • Methoden und Funktionen mit 100 Zeilen Code sind bereits relativ lang.
  • Klassen sollten ebenso nicht zu umfangreich werden.
  • Schreck nicht davor zurück, Code wegzuwerfen. Refactoring und Codeumbauten gehören zum Alltag

 

Schreib einen Kommentar

Your email address will not be published.