Das Marie Kondō Software Design Principle

Marie Kondō ist eine durch ihre Serie und Bücher sehr bekannt gewordene Beraterin, die einem hilft, die Wohnung und das Leben allgemein zu entrümpeln. Die wohl bekannteste Philosophie Kondōs ist:

If it doesn’t spark joy, get rid of it.

Damit ist gemeint: Wenn dir ein Kleidungsstück, oder ein Gegenstand im Allgemeinen, keine Freude bereitet, wenn du darüber nachdenkst, dann schmeiß es einfach weg.

Natürlich lässt sich dieser Ansatz auch auf viele andere Bereiche im Leben anwenden. Unabhängig von Marie Kondō hat sich zum Beispiel auch der Klemmbaustein-Fan Held der Steine zu dieser Theorie als Lebensmotto ausgesprochen:

Wenn etwas keinen Spaß mehr macht, ändere es.

Ich selber versuche ebenfalls, nach diesem Motto mein Leben zu gestalten. Das klappt nicht immer gut, weil es wesentlich einfacher gesagt ist, als getan, aber im Großen und Ganzen sorgt es wie ich finde für ein besseres allgemeines Lebensgefühl.

Aber was hat das alles jetzt mit einem Software Design Principle wie etwa DRY, KISS oder SOLID zu tun?

Ganz einfach:

If this class/method/line doesn’t spark joy, get rid of it.

Lass’ mich erklären: Die eben erwähnten Design Principles sind sehr wichtig, um langfristig guten und erweiterbaren Code umsetzen zu können. Immer wieder sehe ich, wie man direkt auf die Nase fällt, wenn man sie außer Acht lässt. Damit will ich übrigens nicht sagen, dass ich perfekt darin bin, sie immer umzusetzen! Und natürlich kann man sich darüber streiten, ob diese Prinzipien immer so sinnvoll sind. Diese, und Design Patterns im Allgemeinen, haben nämlich bei zu starker Anwendung den Nachteil, dass sie Dinge überkomplizieren.

Ähnlich wie die Normalformen bei einer relationalen Datenbank im Großen und Ganzen sehr sinnvoll sind und eingehalten werden sollten, so sieht man doch in der realen Welt recht schnell, dass das doch nicht immer ganz zielführend ist. Manchmal würde ein Anwenden dieser Normalformen dazu führen, dass Queries extrem lang, komplex und unperformant werden. Als guter Entwickler sollte man daher wissen, wann man diese Prinzipien anwendet und wann man sie lieber aufmerksam ruhen lässt. Diesen Mittelweg zu finden, macht für mich einen Senior Developer aus.

Dass das nicht einfach ist und nicht mal eben so gelernt werden kann, sondern durch viele Jahre Erfahrung kommt, ist denke ich selbsterklärend. Und wie gesagt, ich bin hier in keinster Weise perfekt. Deswegen versuche ich mir, mit dem Marie Kondō Prinzip hier zu helfen. Und das sieht dann etwa so aus:

Wenn ich eine Klasse, Methode oder Zeile habe, die sich nicht schön anfühlt, versuche ich mir anzusehen, was man verbessern könnte. Aber was meine ich mit “nicht schön anfühlen”? Meine primären Metriken sind hier (teilweise unterbewusst) die Anzahl an Methoden in einer Klasse, die Anzahl an Parametern einer Methode oder die Anzahl an Zeilen in einer Methode selbst. Weniger ist hier immer mehr.

Wenn eine Klasse viele Methoden oder Eigenschaften hat, verstößt sie meist gegen das Single Responsibility Principle (das S in SOLID), da sie vermutlich mehr als nur eine Sache tut. Und das spürt man auch, wenn man die Klasse verwenden möchte: Entweder muss man um sie zu verwenden sehr viele Abhängigkeiten hinzugeben, die mit der Lösung des eigentlichen Problems nichts zu tun haben, ein Aufruf der Klasse hat viele Nebeneffekte oder man verarbeitet nur einen Teil der Rückgabe. All das “doesn’t spark joy”. Joy sparkt Code für mich dann, wenn jede Zeile genau das tut, was sie soll, wenn sie sich nicht mit unnötiger Fehlerbehandlung, Dependency Injection oder Filtern abgibt, wenn sie keine fünf Bedingungen prüft oder vier unterschiedliche Fälle gleichzeitig abhandelt.

In einem solchen Fall versuche ich (an einem guten Tag), die Stelle zu refactorn. Das Ziel ist es, die Klasse oder Methode so aufzuteilen, dass sie jeweils nur eine Sache macht, und das simpel und elegant. Mein Richtwert: Wenn ich im Programmfluss mehr als zwei Ebenen tief bin, läuft etwas falsch. Damit meine ich: Eine Schleife (1. Ebene) und darin ein if (2. Ebene) ist in Ordnung. Darin noch einmal eine Schleife, ein if oder ähnliches ist zu viel. Schon fühlt es sich nicht mehr joyful an.

Meistens hilft hierbei das Auslagern in extra Methoden und das Anpassen des Programmflusses. Das hat nicht nur zur Folge, dass man damit mehr oder weniger automatisch das Open-closed Principle (das O in SOLID) umsetzt, sondern auch, dass der Code wesentlich einfacher zu lesen ist, da man sich nur die Namen der Methoden durchlesen muss, und direkt versteht, worum es geht.

Ich hoffe, dass durch diese Ausführung und ohne konkretes Beispiel klar geworden ist, was ich unter dem Marie Kondō Software Design Principle verstehe. Ich sehe es als gute Erweiterung der bestehenden Design Principles und als guten Richtwert, der einem hilft, im Zweifelsfall die richtige Entscheidung zu treffen und das richtige Pattern zu verwenden. Wenn ihr eine Meinung dazu habt, freue ich mich, sie auf Twitter zu hören.

Zu guter Letzt ein Real-Life-Beispiel eines Projekts, bei dem ich die Anwendung des Prinzips zu seiner Vollendung sehen kann (leider aber nicht von mir ;D): Das Laravel Framework. Ich bitte euch an dieser Stelle eventuelle Vorbehalte gegenüber der Sprache oder das Framework an sich außen vor zu lassen und einfach mal in den Code zu tauchen. Dabei ist es eigentlich völlig egal, welche Klasse ihr unter src/ auf macht, eine lange Methode mit vielen Zeilen und tiefen Verschachtelungen wirst du (vermutlich) nicht finden. Und obwohl du vermutlich keine Ahnung davon hast, wie dieses Framework funktioniert, wirst du dich trotzdem recht schnell in der Codebase zurechtfinden, einfach weil die Methoden sinnvolle Namen haben und genau beschreiben, was sie tun.

Photo von Francesco Paggiaro von Pexels