3.7 KiB
3.7 KiB
Entwicklungsstandards
Allgemein gültige Standards für die Arbeit in diesem Repository.
Sprache
- Code-Bezeichner (Variablen, Funktionen, Klassen, Dateinamen): Englisch
- Domänenobjekte (z. B.
Pflanze,Beet,Aussaatkalender): Deutsch erlaubt, wenn es die Lesbarkeit erhöht - Commit-Messages: Englisch, Imperativ (
Add,Fix,Refactor) - Dokumentation & Kommentare: Deutsch
Git & Branching
Struktur
main
└── develop
├── feature/<name> – neue Features
├── fix/<name> – Bugfixes / kleine Fixes
└── debug/<name> – Debugging / Fehleranalyse
Regeln
- Branch-Wechsel erfolgen selbstständig – Claude wechselt eigenständig in den jeweils passenden Branch, ohne nachzufragen. Dabei gelten alle übrigen Regeln uneingeschränkt.
- Nie direkt nach
mainpushen oder mergen. Änderungen inmainkommen ausschließlich über eine Pull-Request ausdevelop. - Jede Änderung findet in einem eigenen
feature/oderfix/Branch unterhalb vondevelopstatt. - In
developmergen erst, wenn die Arbeit abgeschlossen ist und alle Tests erfolgreich waren. - Eine PR nach
mainwird nur auf explizite Anweisung des Nutzers geöffnet. - Vor jedem Merge nach
developund vor jeder PR nachmainwerden alle wesentlichen Dokumente (README.md, CHANGELOG.md, docs/) geprüft und ggf. aktualisiert.
Commit-Messages
Format: <type>: <short description> (max. 72 Zeichen)
| Type | Wann |
|---|---|
feat |
Neues Feature |
fix |
Bugfix |
refactor |
Code-Umbau ohne Verhaltensänderung |
test |
Tests hinzufügen/anpassen |
docs |
Nur Dokumentation |
chore |
Build, Dependencies, Konfiguration |
Nach jedem Commit wird sofort gepusht.
Versionierung
Schema: MAJOR.MINOR.PATCH
| Teil | Bedeutung | Wechsel |
|---|---|---|
MAJOR |
Hauptrelease | Nur auf explizite Anweisung des Nutzers |
MINOR |
Größere Updates, neue Features | Bei jeder Feature-Erweiterung oder größerem Umbau |
PATCH |
Kleine Fixes, Minimalkorrekturen | Bei Bugfixes, kleinen Ergänzungen, Mini-Umbauten |
- Die aktuelle Version steht in CHANGELOG.md und in der Datei
VERSION - Nach jeder Änderung wird die Versionsnummer eigenständig erhöht und in beiden Dateien notiert
- Die Versionsnummer wird im Commit-Message-Footer vermerkt:
Version: x.y.z
Projektstruktur-Dokumentation
- Alle Funktionen/Module werden kurz in docs/project-structure.md dokumentiert
- Ziel: Token-Effizienz in zukünftigen Conversations – nicht alles neu einlesen müssen
- Bei jeder Änderung an Funktionen/Modulen wird die Dokumentation synchron aktualisiert
Code-Qualität
- Keine auskommentierten Code-Blöcke committen
- Keine
console.log/print-Statements in Produktionscode - Funktionen bleiben klein und haben eine einzige Verantwortung
- Keine spekulativen Abstraktionen – erst abstrahieren, wenn ein Muster dreimal vorkommt
Testing
- Unit-Tests für Geschäftslogik (Berechnungen, Transformationen)
- Integrationstests an Systemgrenzen (API, Datenbank)
- Keine Mocks für die Datenbank in Integrationstests
- Testdatei liegt neben der zu testenden Datei oder in einem
__tests__/tests-Verzeichnis auf gleicher Ebene - In
developwird erst gemergt, wenn alle Tests grün sind
Fehlerbehandlung
- Fehler nur an Systemgrenzen abfangen (User-Input, externe APIs, Datenbankzugriff)
- Intern Fehler propagieren, nicht still schlucken
- Keine Fallbacks für Szenarien, die nicht eintreten können
Abhängigkeiten
- So wenig externe Abhängigkeiten wie möglich
- Vor dem Hinzufügen einer Bibliothek prüfen: Wird sie wirklich gebraucht?
package.json/ Lockfile immer committen