Clean Code: Engineering für Menschen

„Jeder Narr kann Code schreiben, den ein Computer verstehen kann. Gute Programmierer schreiben Code, den Menschen verstehen können.“ – Martin Fowler.

Dieses Zitat ist die Grundlage der spezifischen Ingenieurskultur bei Maison Code Paris. Wir optimieren nicht für „Lines of Code“. Wir optimieren nicht auf „Schreibgeschwindigkeit“. Wir optimieren für Wartbarkeit.

Dem Compiler ist es egal, ob Sie Ihre Variable „x“ oder „daysUntilExpiration“ nennen. Die CPU führt es in genau derselben Nanosekunde aus. Aber der Junior-Entwickler, der um 3:00 Uhr morgens aufsteht, um einen kritischen Fehler zu beheben, kümmert sich sehr darum. Wenn sie 10 Minuten damit verbringen müssen, Ihre Variablennamen zu entschlüsseln, verliert das Unternehmen Geld. Clean Code ist ein Akt der Empathie.

Warum Maison Code darüber spricht

Bei Maison Code Paris fungieren wir als das architektonische Gewissen unserer Kunden. Wir übernehmen oft „moderne“ Stacks, die ohne grundlegendes Verständnis für Skalierung gebaut wurden.

Wir diskutieren dieses Thema, weil es einen kritischen Wendepunkt in der technischen Reife darstellt. Die korrekte Implementierung unterscheidet ein fragiles MVP von einer widerstandsfähigen Plattform auf Unternehmensniveau.

1. Benennung: Das schwierigste Problem in der Informatik

Namen sollten die Absicht offenbaren. Ein Variablenname sollte Ihnen drei Dinge sagen:

1. Was es tut.
2. Warum es existiert.
3. Wie es verwendet wird.

Die Regel „No Mental Mapping“

Schlecht: „Typoskript const d = 10; // Tage const list = []; // Benutzer „ Der Leser muss „d“ -> „Tage“ im Kopf übersetzen. Dies nutzt die kognitive Belastung (RAM).

Gut: „Typoskript const daysSinceLastLogin = 10; const activeUsers = []; „ Der Code liest sich wie englische Prosa.

Die Regel der Umfangslänge

• Kleiner Umfang (Schleife): Kurze Namen sind in Ordnung. „for (let i = 0; i < 10; i++)“ ist in Ordnung.
• Großer Geltungsbereich (Global/Klasse): Namen müssen explizit sein. „ich“ ist verboten. Verwenden Sie „globalRetryCounter“.

2. Funktionen: Eine Sache tun

Das Single-Responsibility-Prinzip (SRP) gilt für Funktionen, nicht nur für Klassen. Eine Funktion sollte eine Abstraktionsebene haben.

Schlecht (Die Gott-Funktion): „Typoskript asynchrone Funktion registerUser(req) { // 1. Parsen const { E-Mail, Passwort } = req.body;

// 2. Validierung if (!email.includes(’@’)) throw new Error(‘Invalid Email’);

// 3. Datenbanklogik const user = wait db.users.create({ E-Mail, Passwort: bcrypt.hashSync(Passwort) });

// 4. E-Mail-Logik wait mailgun.messages().send({ to: email, text: „Willkommen!“ });

// 5. Antwortlogik return { Status: 200, ID: user.id }; } „ Diese Funktion ändert sich, wenn:

• Die Datenbank ändert sich (Postgres zu Mongo).
• Der E-Mail-Anbieter ändert sich (Mailgun zu SendGrid).
• Das API-Format ändert sich. Es ist zerbrechlich.

Gut (Der Orchestrator): „Typoskript asynchrone Funktion registerUser(req) { const accountInfo = parseRequest(req); validierenKonto(accountInfo);

const user = Warten auf createUserInDatabase(accountInfo); Warten auf sendWelcomeEmail(user);

return formatResponse(user); } „ Jetzt ist „registerUser“ nur noch ein Orchestrator. Es erzählt eine Geschichte. Die Implementierungsdetails sind in kleinen, fokussierten Funktionen verborgen.

3. Kommentare: Das Scheitern des Ausdrucks

Top-Ingenieure schreiben weniger Kommentare, nicht mehr. Warum? Weil Kommentare ein Code-Geruch sind. Wenn Sie einen Kommentar schreiben müssen, um zu erklären, was der Code tut, ist Ihr Code zu komplex. Refaktorieren Sie es.

Schlecht: „Typoskript // Prüfen Sie, ob der Benutzer Anspruch auf Seniorenrabatt hat if (user.age > 65 && user.purchases > 10 && user.country === ‘FR’) { applyDiscount(); } „

Gut: „Typoskript if (user.isEligibleForSeniorDiscount()) { applyDiscount(); } „

Wann kommentieren?

Kommentieren Sie das WARUM, nicht das WAS. Der Code erklärt, was passiert. Der Kommentar erläutert den geschäftlichen Kontext oder die seltsame Problemumgehung.

„Typoskript // Wir verwenden hier eine Verzögerung von 500 ms aufgrund der externen Zahlungs-API // hat eine Racebedingung, wenn es unmittelbar nach der Erstellung abgefragt wird. // Siehe Ticket Nr. 452. Warten auf Verzögerung (500); „ Dieser Kommentar erspart dem nächsten Entwickler die „Optimierung“ der Verzögerung.

4. Bedingungen: Vermeiden Sie den Pfeilcode

„Pfeilcode“ ist, wenn verschachtelte „if“-Anweisungen eine Form wie einen Pfeil „>“ erzeugen. Dadurch wird die Logik auf die rechte Seite des Bildschirms verschoben und es wird schwieriger, den Status zu verfolgen.

Schlecht: „Typoskript Funktion processPayment(order) { if (Bestellung) { if (order.isPaid) { if (order.amount > 0) { // Logik } } } } „

Gut (Schutzklauseln): Kommen Sie früh zurück. Beenden Sie die Funktion so schnell wie möglich. „Typoskript Funktion processPayment(order) { if (!order) return; if (!order.isPaid) return; if (order.amount <= 0) return;

// Logik (keine Einrückung) } „

5. Primitive Besessenheit

Geben Sie keine rohen Zeichenfolgen und Zahlen weiter. Übergeben Sie Objekte, die Regeln erzwingen.

Schlecht: Funktion bookFlight(origin: string, dest: string) Ist „NYC“ gültig? Ist „New York“ gültig? Ist „JFK“ gültig?

Gut: Funktion bookFlight(origin: AirportCode, dest: AirportCode) Die Klasse „AirportCode“ stellt sicher, dass nur gültige 3-Buchstaben-IATA-Codes im System vorhanden sein können. Sie machen ungültige Zustände nicht darstellbar.

7. Testen als Dokumentation

Die beste Dokumentation ist ein Unit-Test. Dokumente sind veraltet. Tests nicht. Wenn Sie wissen möchten, wie „calculateDiscount()“ funktioniert, lesen Sie die Testfälle.

• it('sollte 10 % für neue Benutzer gelten')
• es('sollte fehlschlagen, wenn der Warenkorb leer ist') Das Schreiben von Tests zwingt Sie dazu, sauberen Code zu schreiben. Wenn eine Funktion schwer zu testen ist, handelt es sich um fehlerhaften Code. „Ich kann das nicht testen, weil es die Datenbank innerhalb der Funktion abfragt.“ Refactor: DB-Abhängigkeit einfügen. Jetzt ist es testbar.

8. Die Code-Review-Kultur

Code Review dient nicht dazu, Fehler zu finden. Dafür ist CI da. Code Review dient dem Wissensaustausch. Es handelt sich um eine Mentoring-Sitzung. „Warum haben Sie hier ein Set anstelle eines Arrays gewählt?“ „Dieses Muster ist interessant, können wir es auch im Benutzermodul verwenden?“ Leitende Ingenieure sollten nicht einfach „LGTM“ sagen. Sie sollten erklären, warum etwas gut oder schlecht ist. Wir benötigen mindestens 1 „Nitpick“ oder „Suggestion“ pro PR. Es erzwingt Engagement.

9. Die Pfadfinderregel

„Verlassen Sie den Campingplatz immer sauberer, als Sie ihn vorgefunden haben.“ Dies ist das Gegenmittel zur technischen Verschuldung. Sie beheben einen Fehler im Modul „Preise“. Sie bemerken eine Variable mit dem Namen „x“. Benennen Sie es um. Ihnen fällt auf, dass eine Funktion zu lang ist. Split it. Bitten Sie nicht um Erlaubnis. Erstellen Sie kein Ticket „Refactor Pricing“. Machen Sie es einfach als Teil Ihrer Arbeit. Wenn jeder Ingenieur 1 % des Codes bereinigt, den er berührt, bleibt die Codebasis für immer makellos.

7. DRY vs. WET (Die Abstraktionsfalle)

Uns wird DRY (Don’t Repeat Yourself) beigebracht. Es ist eine gute Regel. Aber es ist gefährlich. Wenn Sie zwei Codeteile sehen, die ähnlich aussehen, führen Sie sie in einer gemeinsamen Funktion zusammen. Das Problem: Jetzt sind beide Orte auf diese Funktion angewiesen. Wenn Feature A eine geringfügige Änderung der Funktion erfordert, fügen Sie ein boolesches Flag hinzu. Funktion doThing(isFeatureA) Dann braucht Feature B eine Änderung. Funktion doThing(isFeatureA, isFeatureB) Bald haben Sie eine Gottfunktion mit 10 Flaggen. WET (Write Everything Twice) ist oft besser. Duplizierung ist billiger als die falsche Abstraktion. Wenn zwei Funktionen versehentlich die gleiche Logik haben, aber unterschiedliche geschäftliche Gründe für eine Änderung haben, kopieren Sie den Code und fügen Sie ihn ein.

8. Die „Broken Windows“-Theorie

In der Kriminalistik gilt: Wenn ein Gebäude ein kaputtes Fenster hat, das nicht repariert wird, werden Vandalen bald alle Fenster einschlagen. Der Code ist derselbe. Wenn Sie eine unordentliche Funktion hinterlassen, wird der nächste Entwickler denken: „Diese Datei ist sowieso Müll, ich hacke einfach meinen Fix rein.“ Wenn die Datei makellos ist, werden sie den sozialen Druck verspüren, sie makellos zu halten. Sei der Gärtner. Beseitigen Sie das Chaos täglich.

9. Fazit

Bei Clean Code geht es nicht um Ästhetik. Es geht um Wirtschaftswissenschaften. Unordentlicher Code verrottet. Es wird zum „Legacy-Code“, vor dessen Berührung sich jeder fürchtet. Die Erstellung von Funktionen dauert länger. Fehler treten häufiger auf. Clean Code ist ein Gewinn. Es ermöglicht Ihnen, sich unbegrenzt schnell zu bewegen.

---

Codebasis ein Chaos?

Verlangsamt sich Ihre Geschwindigkeit aufgrund des „Spaghetti-Codes“?

Kodex-Audit vereinbaren. Lesen Sie mehr über Unit Testing und Refactoring.

Bei Clean Code geht es nicht um Ästhetik. Es geht um Wirtschaftswissenschaften. Unordentlicher Code verrottet. Es wird zum „Legacy-Code“, vor dessen Berührung sich jeder fürchtet. Die Erstellung von Funktionen dauert länger. Fehler treten häufiger auf. Clean Code ist ein Gewinn. Es ermöglicht Ihnen, sich unbegrenzt schnell zu bewegen.

Schreiben Sie Code für den Menschen, der ihn lesen wird. Denn in 6 Monaten werden Sie dieser Mensch sein.

Codebasis ein Chaos?

Verlangsamt sich Ihre Geschwindigkeit aufgrund des „Spaghetti-Codes“?

Kodex-Audit vereinbaren. Beauftragen Sie unsere Architekten.