“Rule of three” oder “Je einfacher, desto besser”

Softwareentwicklung ist eine komplexe Tätigkeit, bei der es leicht ist, sich in Details zu verlieren. Eine Gewohnheit, die unter Entwicklern weit verbreitet ist, ist das vorzeitige Implementieren von Strukturen, die vielleicht später nützlich sein könnten. Doch was auf den ersten Blick wie eine vorausschauende Planung erscheint, entpuppt sich oft als Hindernis für die Produktivität und Wartbarkeit des Codes. In diesem Blogbeitrag werfen wir einen Blick auf diese Entwickler-Gewohnheit, die Risiken, die sie mit sich bringt, und wie man durch einfachere Ansätze bessere Ergebnisse erzielen kann.

Die Gewohnheit: Alles coden, was jemals noch benötigt werden könnte

In der Softwareentwicklung ist Struktur alles. Eine gut durchdachte Architektur kann Projekte stabilisieren und langfristig wartbar machen. Wenn jedoch ein neues Feature entwickelt wird und nicht perfekt in die bestehende Infrastruktur passt, verspüren viele Entwickler den Drang, sofort eine generelle Lösung zu schaffen. Statt einfach nur die benötigte Klasse zu implementieren, wird oft ein Interface definiert, das die Klasse abstrahiert. Mit dieser Generalisierung entstehen schnell Interface-Hierarchien, abstrakte Klassen und komplexe Abzweigungen.

Das Ziel dabei ist klar: zukünftige Erweiterungen sollen einfach integriert werden können, und die Codebasis soll flexibel bleiben. Doch oft endet man mit einer übermäßig komplizierten Struktur, die in alle denkbaren Richtungen abstrahiert und generalisiert ist – selbst dann, wenn es dafür aktuell keine konkreten Anforderungen gibt.

Warum das problematisch ist

Das eigentliche Problem dieser Vorgehensweise liegt darin, dass solche vorauseilenden Strukturen oft auf Annahmen basieren, die sich als falsch herausstellen. Wenn das neue Feature sich nicht etabliert oder wenn die erwarteten Erweiterungen ausbleiben, bleibt der Entwickler auf einer komplexen Architektur sitzen, die unnötigen Ballast darstellt. Diese Komplexität erschwert nicht nur das Debugging und die Wartung, sondern führt auch dazu, dass das Projekt unnötig aufgebläht wird.

Ein weiteres Problem ist, dass der „Sweet Spot“ oft nicht getroffen wird. Dieser liegt irgendwo zwischen zu wenig und zu viel Struktur. Anstatt pragmatisch und agil zu arbeiten, verliert man sich in theoretischen Konstrukten, die den eigentlichen Fortschritt hemmen. Die Entwicklung wird langsamer, und die Flexibilität, die ursprünglich angestrebt wurde, schlägt in Unübersichtlichkeit und Starrheit um.

Wie man es besser macht: Die „Rule of Three“ anwenden

Ein Ansatz, der hier Abhilfe schaffen kann, ist die von Martin Fowler vorgeschlagene „Rule of Three“. Diese Regel besagt, dass man eine generelle Struktur erst dann implementieren sollte, wenn mindestens drei konkrete Anwendungsfälle dafür existieren oder absehbar sind.

Anstatt direkt zu Beginn Interfaces und Abstraktionen zu schaffen, sollte man zunächst auf einfache, direkte Lösungen setzen. Wenn sich im Laufe der Entwicklung zeigt, dass tatsächlich mehrere Anwendungen für eine Struktur erforderlich sind, kann man diese dann gezielt implementieren. Auf diese Weise bleibt der Code schlank und klar, und man vermeidet unnötige Komplexität, bevor sie tatsächlich benötigt wird.

Warum das besser ist

Die Anwendung der „Rule of Three“ hat viele Vorteile. Erstens bleibt der Code dadurch einfacher und wartbarer. Anstatt den Fokus auf potenzielle zukünftige Anforderungen zu legen, konzentriert man sich auf das Hier und Jetzt. Das spart nicht nur Zeit, sondern auch Ressourcen, die besser in die tatsächliche Entwicklung gesteckt werden können.

Zweitens ermöglicht dieser Ansatz eine agilere Arbeitsweise. Wenn sich Anforderungen ändern – was in der Softwareentwicklung häufig der Fall ist – ist man flexibler und kann schneller reagieren. Die Gefahr, dass man sich in unnötiger Komplexität verliert, wird deutlich verringert.

Schließlich fördert die „Rule of Three“ ein besseres Verständnis für die tatsächlichen Bedürfnisse des Projekts. Anstatt Annahmen über die Zukunft zu treffen, lässt man das Produkt organisch wachsen. Wenn dann wirklich Bedarf an Generalisierungen besteht, sind die Anforderungen klarer und die Lösung präziser.

Fazit

Die „Rule of Three“ ist mehr als nur ein Refactoring-Prinzip – sie ist eine Philosophie, die dazu beiträgt, unnötige Komplexität zu vermeiden und den Fokus auf das Wesentliche zu richten. Softwareentwicklung ist nicht nur eine Frage der Technik, sondern auch der richtigen Balance. Weniger ist oft mehr, und einfache Lösungen führen oft zu den besten Ergebnissen.

Wie reduzieren Sie Komplexität in Ihrer Entwicklung?

Ihre Fragen dazu beantwortet unser Head of DevOps gerne:
Kai Rumrich, kai.rumrich@schwarzer.de, Jetzt anrufen: +49 6131 / 30 292 34