Die Prinzipien
SOLID
Fünf Regeln für objektorientiertes Design – allen voran Single Responsibility: eine Klasse, ein Grund zur Änderung.
DRY
Don’t Repeat Yourself – jedes Wissen hat genau eine Quelle. Aber: Zwei ähnliche Zeilen sind noch kein Duplikat.
KISS
Keep It Simple – die einfachste Lösung, die funktioniert. Clever ist selten gut wartbar.
YAGNI
You Aren’t Gonna Need It – nichts auf Vorrat bauen. Später erweitern ist billiger als Unnötiges pflegen.
Sprechende Namen
days_until_due statt d. Ein guter Name spart einen Kommentar.
Kleine Funktionen
Eine Funktion, eine Aufgabe, eine Abstraktionsebene. Passt sie nicht auf den Bildschirm, aufteilen.
Die Gewohnheiten
- 01
Testen nach der Pyramide
viele Unit · wenige E2EViele schnelle Unit-Tests als Basis, weniger Integrationstests, nur wenige langsame End-to-End-Tests.
- 02
Code Review
Pull RequestVier Augen finden Fehler, verteilen Wissen und halten den Stil einheitlich. Kleine PRs werden besser reviewt.
- 03
Versionieren mit Bedeutung
feat: · fix: · 2.1.0Conventional Commits beschreiben jede Änderung, SemVer (MAJOR.MINOR.PATCH) signalisiert Breaking Changes.
- 04
Automatisieren
CIFormatter, Linter und Tests laufen bei jedem Push – Diskussionen über Einrückung entfallen.
- 05
Dokumentieren, was nicht im Code steht
README · ADRWie starte ich das Projekt? Warum wurde X entschieden? Das gehört in README und Architecture Decision Records.
- 06
Technische Schulden sichtbar machen
BacklogAbkürzungen sind okay, wenn sie bewusst sind – als Ticket festhalten und regelmäßig abbauen.
Nicht so
def calc(d, f=False):
# berechnet den Preis
return d * 1.19 if f else dSo
VAT_RATE = Decimal("1.19")
def gross_price(net: Decimal, include_vat: bool) -> Decimal:
return net * VAT_RATE if include_vat else net