Ich erinnere mich noch an den Tag, an dem ich einen Codebestand mit 50.000 Zeilen geerbt habe, der mich ließ, meine Karrierewahl zu hinterfragen. Es war 2015, ich war drei Jahre in meiner Rolle als Senior Developer bei einem Fintech-Startup, und unser leitender Ingenieur hatte gerade ohne Dokumentation verlassen. Der Code funktionierte – kaum – aber ihn zu lesen fühlte sich an, als würde man antike Hieroglyphen entziffern, die von jemandem geschrieben wurden, der zukünftige Entwickler aktiv hasste. Diese Erfahrung hat mir mehr über sauberen Code beigebracht, als es jedes Lehrbuch jemals könnte.
💡 Wichtige Erkenntnisse
- Die wahren Kosten von schmutzigem Code
- Prinzip 1: Bedeutungsvolle Namen sind Ihre erste Linie der Dokumentation
- Prinzip 2: Funktionen sollten eine Sache tun und sie gut tun
- Prinzip 3: Kommentare sollten erklären, warum, nicht was
Fast neun Jahre später bin ich jetzt Principal Engineer in einem Unternehmen, das Systeme verwaltet, die täglich über 2 Millionen Transaktionen verarbeiten. Ich habe Tausende von Pull-Requests überprüft, Dutzende von Entwicklern betreut und mehr Legacy-Code refaktoriert, als ich gerne zugeben möchte. Durch all das habe ich destilliert, was guten Code von großartigem Code trennt, in zehn grundlegende Prinzipien, die nicht nur meine Arbeit, sondern auch die Arbeit jedes Entwicklers, den ich gecoacht habe, transformiert haben.
Sauberer Code geht nicht darum, pedantisch zu sein oder Regeln um ihrer selbst willen zu folgen. Es geht um Respekt – Respekt für dein zukünftiges Ich, deine Teamkollegen und die nächste Person, die deine Arbeit um 2 Uhr morgens warten wird, wenn die Produktion ausgefallen ist. Lass mich teilen, was ich gelernt habe.
Die wahren Kosten von schmutzigem Code
Bevor wir zu den Prinzipien übergehen, lass uns darüber sprechen, warum das wichtig ist. In meiner aktuellen Rolle haben wir eine interne Studie durchgeführt, um die Produktivität der Entwickler in unseren Engineering-Teams zu verfolgen. Wir fanden heraus, dass Entwickler im Durchschnitt 65% ihrer Zeit damit verbringen, bestehenden Code zu lesen und zu verstehen, während nur 35% tatsächlich neuen Code schreiben. Dieses Verhältnis wird bei schlecht geschriebenem Code noch schlechter – in unseren Altsystemen springt es auf 80/20.
Hier ist der Clou: Wir haben berechnet, dass allein unklare Variablennamen unser Team ungefähr 127 Stunden pro Quartal kosten. Das sind über drei volle Arbeitswochen, die nur damit verbracht werden, herauszufinden, was x, temp oder data2 tatsächlich darstellt. Multipliziere das mit einem Team von 40 Ingenieuren, und du siehst, dass es sich um eine sechsstellige jährliche Kosten aus etwas so einfachem wie schlechten Namenskonventionen handelt.
Ich habe gesehen, wie Projekte scheitern, nicht wegen technischer Unmöglichkeiten, sondern weil der Codebestand so verworren wurde, dass selbst einfache Änderungen Wochenstatt Stunden in Anspruch nahmen. Ein E-Commerce-Kunde, für den ich beratend tätig war, verlor schätzungsweise 50.000 Dollar pro Tag an potenziellen Einnahmen, weil sein Checkout-System so fragil war, dass das Hinzufügen einer neuen Zahlungsmethode einen dreimonatigen Entwicklungszyklus erforderte. Nach einem sechswöchigen Refaktorisierungs-Sprint, in dem Prinzipien des sauberen Codes angewendet wurden, dauerte dieselbe Änderung vier Tage.
Die geschäftliche Notwendigkeit ist klar: cleaner Code hat direkte Auswirkungen auf dein Endergebnis, die Moral deines Teams und deine Fähigkeit zu innovieren. Lass uns nun erkunden, wie man es erreicht.
Prinzip 1: Bedeutungsvolle Namen sind Ihre erste Linie der Dokumentation
Ich habe einmal mit einem Entwickler gearbeitet, der darauf bestand, dass kurze Variablennamen den Code schneller zu tippen machten. Er schrieb Dinge wie let u = getUserData() oder const p = calculatePrice(). Als ich ihn drei Monate später bat, seinen Code zu erklären, konnte er es nicht. Er hatte sein eigenes Abkürzungssystem vergessen.
Deine Variablen-, Funktions- und Klassennamen sollten eine Geschichte erzählen. Sie sollten die Absicht offenbaren, ohne dass ein Kommentar erforderlich ist. Vergleiche diese beiden Beispiele:
Schlecht: const d = 86400;
Gut: const SECONDS_PER_DAY = 86400;
Der Unterschied scheint trivial, bis du um Mitternacht debuggen musst und versuchst zu verstehen, warum eine Berechnung falsch ist. Die zweite Version sagt dir sofort, was diese magische Zahl darstellt.
Hier ist meine Namens-Checkliste, die ich mit jedem Junior-Entwickler teile, den ich betreue:
- Verwende aussprichbare Namen – wenn du es bei einer Code-Überprüfung nicht sagen kannst, ist es zu kryptisch
- Verwende durchsuchbare Namen – einbuchstabige Variablen sind unmöglich mit Ctrl+F zu finden
- Vermeide mentales Mapping – lasse die Leser deine Abkürzungen nicht übersetzen
- Wähle ein Wort pro Konzept – mische nicht fetch, retrieve und get für denselben Vorgang
- Verwende Lösungsbereichsnamen – andere Programmierer werden deinen Code lesen, also macht AccountVisitor oder JobQueue Sinn
In der Praxis habe ich festgestellt, dass das zusätzliche Nachdenken über einen Namen von 30 Sekunden im Durchschnitt 15 Minuten Verwirrung später spart. Das ist eine 30-fache Rendite. Wenn du das über Hunderte von Variablen in einem Projekt multiplizierst, werden die Zeitersparnisse enorm.
Eine Technik, die ich benutze: Wenn ich nicht in einem klaren Satz erklären kann, was eine Variable tut, ist der Name nicht gut genug. Probier es selbst aus – wenn du Schwierigkeiten hast, etwas zu benennen, ist das oft ein Zeichen dafür, dass das Ding selbst zu viel macht und zerlegt werden muss.