Besseren Code schreiben

Ich entwickle seit mehr als 10 Jahren professionell Software. In dieser Zeit habe ich sehr viel Code geschrieben, und noch mehr gelesen. Eigenen Code und Code von anderen. Code, der furchtbar schlecht war, und Code, mit dem die Arbeit eine echte Freude ist. Guter Code hat dabei fast immer dieselben Eigenschaften: Er ist leicht zu lesen, leicht zu verstehen, leicht zu warten und zu erweitern. So komplex wie nötig, aber so einfach wie möglich.

№ 01 Die Grundlagen verstehen

Beginnen wir mit etwas Offensichtlichem (aber wirklich Wichtigem). Egal, was Sie im Leben tun, Sie müssen die Grundlagen beherrschen. Für die Programmierung gilt das ganz besonders. Wenn Sie nicht grundlegend verstehen, was Sie tun, werden Sie es schwer haben. Lernen Sie, wie Datentypen, Algorithmen und Datenstrukturen funktionieren. Beschäftigen Sie sich mit verschiedenen Arten von Programmiersprachen.

№ 02 Erst denken, dann schreiben

Je erfahrener Sie als Software-Engineer werden, desto mehr werden Sie feststellen, dass Sie mehr Zeit mit dem Nachdenken über ein Problem und dessen Lösung verbringen als mit dem eigentlichen Schreiben von Code. Das liegt daran, dass Programmieren Denken ist. Wenn Sie zuerst über Ihr Problem nachdenken und bereits eine Lösung im Kopf haben, wird das eigentliche Codieren einfach.

№ 03 Konsistent bleiben

Konsistenz ist einer der wichtigsten Faktoren beim Schreiben von Software. Wenn Sie in Ihrer gesamten Codebase dieselben Regeln befolgen, wird es für andere deutlich einfacher, Ihren Code zu lesen, nachzuvollziehen und zu verstehen.

• Dateibenennung
• Einrückung
• Benennung von Variablen und Funktionen
• Verwendung von einfachen/doppelten Anführungszeichen

№ 04 Zuständigkeiten trennen

Ihr Code sollte möglichst wenige Seiteneffekte und Abhängigkeiten haben. Bestimmte Code-Abschnitte sollten eine Aufgabe erfüllen, und diese gut. Wenn Sie an einem Datenbankservice arbeiten, vermeiden Sie den Zugriff auf den Application State. Fügen Sie stattdessen einen Parameter hinzu, über den Aufrufer diese Information selbst übergeben können.

// Schlecht
const getUserOrders = () => orders.filter(o => o.userId === store.userId)

// Gut
const getUserOrders = (userId: string) => orders.filter(o => o.userId === userId)

№ 05 Keine Magic Numbers

Magic Numbers und Strings sind schlecht. Es handelt sich meist um Inline-Variablen, die für einen bestimmten Zweck verwendet werden, der beim Lesen des Codes nicht sofort ersichtlich ist. Anstatt eine „magische Zahl" einzufügen, extrahieren Sie eine Variable mit einem Namen, der den Zweck klar beschreibt.

// Schlecht
if (users.length >= 100) { ... }

// Gut
const earlyAccessUserLimit = 100
if (users.length >= earlyAccessUserLimit) { ... }

№ 06 Das Rad nicht neu erfinden

Programmieren macht Spaß. Als Engineers neigen wir dazu, für fast alles eigene Lösungen schreiben zu wollen. Das ist aber nicht immer sinnvoll. Nutzen Sie bestehende Frameworks, Tools und Services und konzentrieren Sie sich darauf, Ihr eigentliches Problem zu lösen. Jede Zeile Code, die Sie nicht schreiben, müssen Sie auch nicht warten.

№ 07 Weniger Dependencies

Umgekehrt sollten Sie nicht für alles ein Package einbinden. Wenn es eine sehr einfache Lösung für Ihr Problem gibt, fügen Sie nicht unnötig Overhead durch eine externe Dependency hinzu. Wissen Sie, wann es sinnvoll ist, einen Drittanbieter-Service oder ein Package zu verwenden, und wann nicht.

№ 08 Selbsterklärende Namen

Es ist entscheidend, in der gesamten Codebase selbsterklärende, einfache Namen zu verwenden. Vermeiden Sie unnötige Abkürzungen. Vermeiden Sie willkürliche Namen. Guter Code liest sich wie ein Buch.

// Schlecht
const maxMbs = 10
const matchingOrders = orders.filter(x => x.status === 'fulfilled')

// Gut
const fileSizeLimitMb = 10
const unfulfilledOrders = orders.filter(o => o.status !== 'fulfilled')

№ 09 Nicht überentwickeln (YAGNI)

YAGNI, „You ain't gonna need it". Implementieren Sie neue Funktionalität nur, wenn Sie sie wirklich brauchen, nicht, wenn Sie glauben, sie in Zukunft zu brauchen. Höchstwahrscheinlich werden Sie sie nie benötigen. Bauen Sie ein Feature auch nicht auf die komplexeste Art und Weise. Jeder neue Code muss gewartet werden.

№ 10 Duplizierung vermeiden (DRY)

DRY, „Don't repeat yourself". Vermeiden Sie Redundanz um jeden Preis. Das gilt für Code, Daten und Kommentare. Wann immer Sie ein Stück Code wiederverwenden müssen, extrahieren Sie es in eine separate Datei, ein Modul oder eine Funktion.

№ 11 Refactoring wenn nötig

Scheuen Sie sich nicht vor Refactoring. Software entwickelt sich weiter, und Sie sollten das auch. Es ist besser, technische Schulden zu beseitigen und den betreffenden Code zu refactoren, anstatt ihn mitzuschleppen und sich darüber zu ärgern.

№ 12 Keine Annahmen

Treffen Sie keine Annahmen darüber, wie sich Ihr Code in bestimmten Situationen verhält. Behandeln Sie Fehler. Rechnen Sie mit dem Unerwarteten. Murphy's Law gilt: Alles, was schiefgehen kann, wird irgendwann auch schiefgehen.

№ 13 Immutability nutzen

Verwenden Sie wann immer möglich unveränderliche Datentypen und vermeiden Sie es, bestehende Variablen direkt zu manipulieren. Ihr Code wird deutlich vorhersagbarer und weniger fehleranfällig, wenn Sie mit unveränderlichen Objekten arbeiten.

№ 14 Environment Variables

Führen Sie immer Environment Variables für Daten ein, die nicht fest einprogrammiert werden sollten. Datenbank-Connection-Strings, Dateisystempfade, App-Einstellungen. Speichern Sie solche Daten niemals direkt in Ihrem Code.

№ 15 In den Flow kommen

Programmieren erfordert Konzentration. Wenn Sie ein Problem angehen, sorgen Sie dafür, in den Flow zu kommen. Schalten Sie Benachrichtigungen stumm. Denken Sie sich in das Problem und seine möglichen Lösungen hinein. Kommen Sie in den Flow, und unterbrechen Sie ihn nicht.