Best Practices sind ein grossartiger Ausgangspunkt. Sie repräsentieren die destillierte Erfahrung von Tausenden von Entwicklern, die auf dieselben Probleme gestossen sind und Lösungen gefunden haben, die für sie funktioniert haben — in ihrem Kontext, mit ihren Rahmenbedingungen. Das ist wirklich wertvoll.
Aber hier geht es schief: Entwickler bleiben bei «Es ist eine Best Practice» stehen und fragen nie «Ist es die beste Praxis für uns?» Sie behandeln Best Practices wie Regeln statt wie das, was sie tatsächlich sind — Empfehlungen von Leuten, die deine Codebase, dein Team, deine Nutzer und deine Einschränkungen nicht kennen.
Der Autoritätsfehlschluss
Wenn ich mit Engineers über Architektur oder Implementierung diskutiere, höre ich regelmässig: «Wir sollten es so machen, weil es eine Best Practice ist.» Das ist kein Argument. In der formalen Logik nennt man das einen Autoritätsfehlschluss — die Idee, dass etwas korrekt ist, weil eine Autorität es gesagt hat, und nicht wegen der Begründung dahinter.
Best Practices sind nichts anderes als Erfahrungen anderer Entwickler, die ausgedrückt haben, was für sie in ihrem Kontext Sinn ergab. Meistens wird sich ihr Kontext mit deinem überschneiden. Aber nicht immer. Und wenn nicht, ist blindes Befolgen kein Engineering — es ist Cargo-Kulting.
Die Lösung ist einfach: Jedes Mal wenn jemand «Best Practice» sagt, frag «Warum?» Wenn die Antwort «Weil die Doku es sagt» oder «Weil alle es so machen» lautet, ist das ein Warnsignal. Wenn die Antwort ein konkreter technischer Grund ist, der auf deine Situation zutrifft, grossartig — jetzt hast du ein echtes Argument, keinen Autoritätsfehlschluss.
Das Next.js-Warenkorb-Desaster
Ich habe das bei einem grossen Schweizer Retailer erlebt. Als ich dazukam, baute das Team E-Commerce-Anwendungen und hatte Next.js mit einem strikten «Server-first»-Ansatz übernommen — weil die Next.js-Dokumentation das empfahl. Alles auf dem Server rendern. Überall Server Components verwenden. Client-seitiges JavaScript minimieren.
Das Problem? Sie wandten das auf den gesamten Warenkorb- und Checkout-Flow an. Jede Warenkorb-Aktion — Artikel hinzufügen, Menge ändern, Gutschein anwenden — löste einen Server-Roundtrip aus. Der gesamte Checkout war server-gerendert.
Auf dem Papier folgte das den «Best Practices». In der Praxis war es eine schreckliche Passung. Wir bedienten nur den Schweizer Markt. Jeder Warenkorb ist einzigartig pro Nutzer — es gibt null Vorteil beim serverseitigen Caching des Warenkorb-Zustands. Der Server-first-Ansatz fügte jeder Interaktion Latenz hinzu, ohne uns etwas dafür zu geben. Kein SEO-Vorteil (Google indexiert deinen Warenkorb nicht). Kein Caching-Vorteil (jeder Warenkorb ist anders). Nur langsamere UX ohne Grund.
Es war anfangs schwer, das Team zu überzeugen. «Aber die Next.js-Doku sagt, Server Components sind der Standard» war ein echtes Argument, das ich mehrfach hörte. Der Autoritätsfehlschluss war tief verankert. Aber als wir Warenkorb und Checkout komplett auf den Client verlagerten, verbesserte sich die User Experience dramatisch. Interaktionen wurden sofort. Der Code wurde einfacher. Und wir verloren keinen einzigen Vorteil, den Server-Rendering uns angeblich gab.
Drill es auf deinen Kontext runter
Die Lektion ist nicht «Ignoriere Best Practices». Die Lektion ist: Behandle sie als Ausgangspunkt, dann drill sie auf deinen spezifischen Kontext herunter. Frag dich:
Welches Problem löst diese Praxis? Hat mein Projekt tatsächlich dieses Problem? Was sind die Trade-offs in meiner spezifischen Situation? Basiert die Empfehlung auf Annahmen, die für uns nicht gelten?
Server-seitiges Rendering ist hervorragend, wenn du SEO brauchst, wenn du Inhalte servierst, die für viele Nutzer gleich sind, wenn du schnelle initiale Seitenladezeiten auf langsamen Verbindungen willst. Es ist unnötiger Overhead, wenn du personalisierte, interaktive Inhalte hinter einer Authentifizierung renderst, die keine Suchmaschine je sehen wird.
Das Next.js-Team liegt nicht falsch. Ihre Empfehlung ist solide für die Mehrheit der Anwendungsfälle, für die sie entworfen wurde. Aber sie wissen nicht, dass dein Checkout nur für die Schweiz ist, dass dein Warenkorb immer einzigartig ist, und dass deine Nutzer auf schnellen Schweizer Internetverbindungen sind. Nur du kennst deinen Kontext. Und nur du kannst entscheiden, welche Praxis tatsächlich passt.
Manche Praktiken sind fast universell
Nicht alle Best Practices brauchen starke Kontextualisierung. Manche sind so fundamental, dass sie fast überall gelten. YAGNI über DRY — abstrahiere nicht, bis du musst — ist eine, die ich in keinem Kontext scheitern sah. Die Trennung von Smart und Dumb Components — Geschäftslogik aus UI-Komponenten raushalten — funktioniert, egal ob du eine Banking-App oder eine E-Commerce-Seite baust.
Der Unterschied? Diese Praktiken wurzeln in fundamentalen Software-Design-Prinzipien — Separation of Concerns, Vermeidung vorzeitiger Abstraktion — nicht in framework-spezifischen Empfehlungen. Je stärker eine «Best Practice» an ein spezifisches Tool oder Framework gebunden ist, desto wahrscheinlicher muss sie an deinen Kontext angepasst werden.
Baue dein eigenes Playbook
Die besten Teams, die ich geführt habe, befolgen keine Best Practices — sie haben ihre eigenen Praktiken, informiert von Best Practices, aber angepasst an ihre Realität. Sie haben sich die Zeit genommen zu verstehen, warum eine Empfehlung existiert, getestet ob sie zutrifft, und aufgeschrieben, was tatsächlich für sie funktioniert.
Das meine ich mit «Erfinde deine eigenen». Nicht dass du die kollektive Weisheit der Branche ignorieren sollst. Sondern dass du sie durch dein eigenes Engineering-Urteil verarbeiten sollst, anstatt sie als Evangelium zu akzeptieren. Lies die Doku. Verstehe die Begründung. Dann entscheide — mit Argumenten, nicht mit Autorität — ob es passt.
Die Engineers, die das tun, bauen bessere Software. Nicht weil sie schlauer sind, sondern weil sie denken statt zu folgen.