Ich habe nun seit 14 Jahren den Code anderer Leute angeschaut, als Senior Softwarearchitekt in einem mittelständischen Fintech-Unternehmen, und ich kann dir genau sagen, wann ich aufgehört habe, ein Verfechter von sauberem Code zu sein: Es war um 2:47 Uhr an einem Dienstag im März 2019, als unser Zahlungssystem zusammenbrach, weil jemand drei Tage damit verbracht hatte, ein perfekt funktionierendes Modul so umzustrukturieren, dass es jeder einzelnen Regel in Uncle Bobs Buch folgte. Die Ironie? Der Fehler wurde während der "Bereinigung" eingeführt.
💡 Wichtige Erkenntnisse
- Regel, die ich befolge #1: Funktionen sollten eine Sache tun (aber ich definiere "eine Sache" anders)
- Regel, die ich befolge #2: Bedeutungsvolle Namen sind nicht verhandelbar
- Regel, die ich befolge #3: Kommentare erklären warum, nicht was
- Regel, die ich befolge #4: Halte Funktionen und Klassen klein (mit Nuancen)
In jener Nacht änderte sich, wie ich über Codequalität denke. Ich sage nicht, dass die Prinzipien des sauberen Codes falsch sind – ganz im Gegenteil. Aber nach der Überprüfung von über 10.000 Pull-Requests, der Mentoring von 47 Entwicklern und dem Versand von 23 großen Produktversionen habe ich gelernt, dass dogmatische Anhänglichkeit an irgendeine Regel ein weiterer Ausdruck von technischer Schuld ist. Einige Regeln des sauberen Codes sind absolutes Gold. Andere? Sind bestenfalls kontextabhängig und im schlimmsten Fall aktiv schädlich.
Hier ist, was ich tatsächlich im Produktionscode mache und, noch wichtiger, warum ich es tue.
Regel, die ich befolge #1: Funktionen sollten eine Sache tun (aber ich definiere "eine Sache" anders)
Das Prinzip der einzigen Verantwortung für Funktionen ist wahrscheinlich die wertvollste Regel, die ich religiös befolge. Aber hier weiche ich vom Lehrbuch ab: Ich messe "eine Sache" nicht an Zeilen Code oder der Anzahl der Operationen. Ich messe es an konzeptioneller Kohäsion.
Im letzten Quartal habe ich eine Funktion überprüft, die acht Zeilen lang war, aber SRP spektakulär verletzte. Sie validierte Benutzereingaben UND protokollierte das Validierungsergebnis UND aktualisierte den Cache. Drei unterschiedliche Verantwortlichkeiten in acht Zeilen gepresst. Vergleiche das mit einer 45-Zeilen-Funktion, die ich letzten Monat geschrieben habe und die eine komplexe Datenbanktransaktion koordiniert – sie tut "eine Sache" (eine Zahlungstransaktion abschließen), aber diese eine Sache erfordert mehrere Schritte, die zusammengehören.
Hier ist mein Litmus-Test: Kann ich beschreiben, was diese Funktion tut, in einem einzigen Satz, ohne das Wort "und" zu verwenden? Wenn ich sagen muss "diese Funktion validiert die Eingabe UND sendet eine E-Mail", dann macht sie zwei Dinge. Wenn ich jedoch sage "diese Funktion verarbeitet eine Rückerstattungsanfrage", und das umfasst natürlich Validierung, Datenbankaktualisierungen und Benachrichtigungen – das ist immer noch eine Sache auf der richtigen Abstraktionsebene.
In der Praxis bedeutet das, dass meine Funktionen im Durchschnitt 25-30 Zeilen lang sind, anstatt der 10-15, die von Puristen empfohlen werden. Aber unsere Fehlerquote bei diesen Funktionen ist 40 % niedriger als bei dem überextrahierten Code, den wir zuvor hatten. Warum? Weil das Zusammenhalten verwandter Operationen die kognitive Belastung beim Verständnis des Systems verringert. Wenn alles in winzige Funktionen aufgeteilt ist, verbringt man mehr Zeit damit, zwischen Dateien zu springen, als die Geschäftslogik zu verstehen.
Der wahre Gewinn hier ist die Testbarkeit. Eine Funktion, die eine konzeptionelle Sache tut, ist leicht zu testen, selbst wenn sie 40 Zeilen lang ist. Du simuliert die Abhängigkeiten, rufst die Funktion auf, überprüfst das Ergebnis. Fertig. Wenn du alles in 5-Zeilen-Funktionen extrahiert hast, bleibst du sowieso mit Integrationstests hängen, weil Unit-Tests bedeutungslos werden.
Regel, die ich befolge #2: Bedeutungsvolle Namen sind nicht verhandelbar
Ich werde auf diesem Hügel sterben: Variablen- und Funktionsnamen sind die wichtigste Dokumentation, die du jemals schreiben wirst. Ich habe Pull-Requests ausschließlich wegen schlechter Benennung abgelehnt und ich werde es wieder tun.
"Dogmatische Anhänglichkeit an irgendeine Regel ist nur eine andere Form von technischer Schuld. Der beste Code ist nicht der sauberste – er ist der Code, der zuverlässig ausgeliefert wird und von deinem Team gewartet werden kann."
Vor zwei Monaten reichte ein Junior-Entwickler Code mit einer Funktion namens `processData()` ein. Ich schickte es mit einem 10-minütigen Loom-Video zurück, in dem ich erklärte, warum. Diese Funktion validierte speziell Kreditkartennummern gegen den Luhn-Algorithmus. Der korrekte Name war `validateCardNumberChecksum()`. Ja, er ist länger. Ja, er ist spezifischer. Genau darum geht es.
Hier ist meine Hierarchie für die Benennung, verfeinert durch tausende von Code-Reviews:
- Boolean-Variablen: Immer mit is/has/can/should beginnen. Nicht `active`, sondern `isActive`. Nicht `permission`, sondern `hasPermission`.
- Funktionen: Verben für Aktionen, Nomen für Abfragen. `calculateTotalPrice()` nicht `totalPrice()`. `getUserById()` nicht `user()`.
- Klassen: Nomen, die Konzepte repräsentieren, nicht Aktionen. `PaymentProcessor` nicht `ProcessPayments`.
- Konstanten: SCREAMING_SNAKE_CASE für echte Konstanten, camelCase für Konfigurationen, die sich ändern könnten.
Die Auswirkungen sind messbar. Nachdem wir vor 18 Monaten strenge Benennungsrichtlinien in unserem Team implementiert haben, fiel unsere durchschnittliche PR-Überprüfungszeit von 3,2 Stunden auf 1,8 Stunden. Warum? Weil Prüfer weniger Zeit damit verbringen, zu entschlüsseln, was der Code tut, und mehr Zeit damit verbringen, zu bewerten, ob er es richtig tut.
Ich setze auch eine "Keine Abkürzungen"-Regel mit genau drei Ausnahmen durch: `id`, `url` und `api`. Ev