Merksätze, die bleiben (Teil 4)

Hallo liebe Leserinnen, liebe Leser und alle, die sich sonst irgendwie hierher verirrt haben,

willkommen im vierten und letzten Teil der Serie „Merksätzen, die bleiben“. Diesmal geht's um Entwickler-Faustregeln.
Entwickler-Faustregeln sind kurze Erfahrungsregeln aus der Softwareentwicklung. Sie helfen dabei, Code verständlicher, wartbarer, sicherer und robuster zu schreiben.

Viele dieser Regeln sind keine starren Gesetze, sondern Orientierungshilfen. Je nach Projekt, Team und Situation kann eine Regel unterschiedlich wichtig sein.

---

Warum Entwickler-Faustregeln nützlich sein können

Softwareentwicklung besteht nicht nur daraus, Code zu schreiben. Es geht auch darum, Systeme zu verstehen, Änderungen sicher vorzunehmen, Fehler zu vermeiden, gute Namen zu finden, Abhängigkeiten zu beurteilen und langfristig wartbare Lösungen zu bauen.
Entwickler-Faustregeln sind nützlich, weil sie

• Erfahrung in kurzen Sätzen bündeln,
• typische Fehler sichtbar machen,
• bessere Entscheidungen im Code fördern,
• Gespräche im Team erleichtern,
• Wartbarkeit und Sicherheit stärken,
• an wichtige Grundprinzipien erinnern.

Ein Satz wie „Code wird öfter gelesen als geschrieben“ erinnert daran, dass Lesbarkeit kein Luxus ist. Sie ist eine Voraussetzung dafür, dass Software langfristig gepflegt werden kann.

---

Entwickler-Faustregeln für bessere Software

Nr.	Entwickler-Faustregel	Bedeutung
1	Code wird öfter gelesen als geschrieben.	Lesbarkeit ist wichtiger als clevere Kürze.
2	Schreibe Code für Menschen, nicht nur für Maschinen.	Andere Menschen müssen den Code später verstehen und ändern können.
3	Erst verstehen, dann ändern.	Vor Änderungen sollte man den vorhandenen Code und seine Absicht verstehen.
4	Make it work, make it right, make it fast.	Erst funktional machen, dann sauber gestalten, dann optimieren.
5	Miss zuerst, optimiere dann.	Performance-Probleme sollten gemessen und nicht geraten werden.
6	KISS: Keep it simple.	Einfache Lösungen sind oft robuster und wartbarer.
7	YAGNI: You aren't gonna need it.	Baue nichts, was aktuell nicht wirklich benötigt wird.
8	DRY: Don't repeat yourself.	Wiederholungen vermeiden, aber nicht um jeden Preis.
9	Falsche Abstraktionen sind teurer als Duplikate.	Eine schlechte Vereinheitlichung kann später mehr Probleme machen als etwas Wiederholung.
10	Abstraktion folgt Wiederholung, nicht Vorahnung.	Erst abstrahieren, wenn ein Muster wirklich erkennbar ist.
11	Benennung ist Design.	Gute Namen machen Zuständigkeiten und Absichten sichtbar.
12	Wenn du keinen guten Namen findest, ist das Design vielleicht unklar.	Schwierige Benennung kann auf unklare Struktur hinweisen.
13	Eine Funktion sollte eine Sache tun.	Kleine, fokussierte Funktionen sind leichter zu testen und zu verstehen.
14	Kommentare erklären warum, nicht was.	Der Code zeigt, was passiert; Kommentare erklären Hintergründe und Entscheidungen.
15	Jeder Hack wird irgendwann Infrastruktur.	Provisorien bleiben oft länger bestehen als gedacht.
16	Fail fast.	Fehler sollten früh sichtbar werden, bevor sie später größeren Schaden anrichten.
17	Explizit ist besser als implizit.	Klare Abläufe sind oft sicherer als versteckte Magie.
18	Globale Zustände sind globale Probleme.	Global veränderliche Daten erschweren Debugging und Tests.
19	Seiteneffekte gehören an den Rand.	Kernlogik sollte möglichst klar, testbar und unabhängig bleiben.
20	Traue keiner Eingabe.	Alles, was von außen kommt, kann falsch, manipuliert oder unerwartet sein.
21	Clientseitige Validierung ist Komfort, serverseitige Validierung ist Sicherheit.	Prüfungen im Browser helfen, ersetzen aber nie Prüfungen auf dem Server.
22	Fehlerfälle sind keine Sonderfälle.	Fehlerbehandlung gehört zum normalen Design.
23	Happy Path ist nur die halbe Wahrheit.	Neben dem Idealfall müssen auch Randfälle und Fehler bedacht werden.
24	Datenmodell schlägt Codeakrobatik.	Ein gutes Datenmodell vereinfacht den gesamten Code.
25	APIs sind Verträge.	Schnittstellen sollten stabil, verständlich und verlässlich sein.
26	Tests sind Sicherheitsnetze.	Tests verhindern, dass alte Fehler unbemerkt zurückkommen.
27	Ein Bug braucht zuerst einen Test.	Ein reproduzierender Test schützt vor Wiederholung desselben Fehlers.
28	Teste Verhalten, nicht Implementierung.	Tests sollten prüfen, was Code leisten soll, nicht wie er intern gebaut ist.
29	Was nicht automatisiert ist, wird vergessen.	Wiederkehrende manuelle Schritte führen langfristig zu Fehlern.
30	Secrets gehören nie ins Repository.	Passwörter, Tokens und private Schlüssel dürfen nicht im Code-Repository landen.
31	Logs sind die Stimme des Systems.	Gute Logs erklären später, was passiert ist.
32	Keine sensiblen Daten ins Log.	Logs dürfen keine Passwörter, Tokens oder unnötigen personenbezogenen Daten enthalten.
33	Reproduzierbar ist halb behoben.	Ein Fehler, der zuverlässig nachstellbar ist, lässt sich leichter lösen.
34	Zeit ist ein schwieriger Datentyp.	Zeitzonen, Sommerzeit und Kalenderregeln machen Datumslogik komplex.
35	Speichere Zeit in UTC, zeige lokal an.	Intern UTC verwenden, in der Oberfläche lokal formatieren.
36	Geld ist kein Float.	Geldbeträge sollten nicht mit ungenauen Fließkommazahlen berechnet werden.
37	Unicode ist kein Sonderfall.	Software sollte Umlaute, Emojis und internationale Zeichen korrekt verarbeiten.
38	Cache macht schnell, Cache macht falsch.	Caches verbessern Performance, können aber veraltete Daten liefern.
39	Retry ohne Grenzen ist ein Angriff auf dich selbst.	Wiederholungsversuche brauchen Limits und Pausen.
40	Timeouts sind Pflicht.	Externe Aufrufe dürfen nicht unbegrenzt hängen bleiben.
41	N+1 ist der stille Performance-Killer.	Viele kleine Datenbankabfragen in Schleifen können Systeme stark verlangsamen.
42	Migrationen sind Code.	Datenbankänderungen müssen versioniert, getestet und nachvollziehbar sein.
43	Sicherheit ist kein Plugin.	Sicherheit muss von Anfang an mitgedacht werden.
44	Security by obscurity ist keine Sicherheit.	Verstecken ersetzt keine echte Absicherung.
45	Selbstgebaute Kryptografie ist fast immer kaputt.	Für Kryptografie sollte man bewährte Bibliotheken und Standards verwenden.
46	Dependencies sind fremder Code in deinem Haus.	Abhängigkeiten bringen Nutzen, aber auch Risiken und Wartungsaufwand.
47	Kleine Pull Requests sind freundliche Pull Requests.	Kleine Änderungen sind leichter zu prüfen und sicherer zusammenzuführen.
48	Code Review prüft Denken, nicht Ego.	Reviews dienen Qualität und Lernen, nicht persönlicher Bewertung.
49	Wenn du es nicht erklären kannst, ist es noch nicht einfach genug.	Verständlichkeit ist ein guter Test für Designqualität.
50	Was du nicht beobachten kannst, kannst du schlecht betreiben.	Monitoring, Logs und Metriken gehören zu produktionsreifer Software.

---

Glossar wichtiger Begriffe

Begriff	einfache Erklärung
Code Review	Prüfung von Code durch andere Entwicklerinnen und Entwickler.
Dependency	Eine externe Bibliothek oder Software, die ein Projekt verwendet.
DRY	Prinzip, Wiederholungen im Code zu vermeiden, wenn sie unnötig sind.
KISS	Prinzip, Lösungen möglichst einfach zu halten.
Migration	Strukturierte Änderung an einer Datenbank.
Monitoring	Beobachtung eines Systems mit Messwerten, Logs und Alarmen.
Pull Request	Vorschlag, Codeänderungen in ein Projekt zu übernehmen.
Retry	Erneuter Versuch einer fehlgeschlagenen Operation.
Timeout	Maximale Wartezeit für eine Operation, bevor sie abgebrochen wird.
YAGNI	Prinzip, nichts zu bauen, was aktuell nicht benötigt wird.

---