110 lines
3.7 KiB
Markdown
110 lines
3.7 KiB
Markdown
# 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
|
||
|
||
0. **Branch-Wechsel erfolgen selbstständig** – Claude wechselt eigenständig in den jeweils passenden Branch, ohne nachzufragen. Dabei gelten alle übrigen Regeln uneingeschränkt.
|
||
1. **Nie direkt nach `main` pushen oder mergen.** Änderungen in `main` kommen ausschließlich über eine Pull-Request aus `develop`.
|
||
2. Jede Änderung findet in einem eigenen `feature/` oder `fix/` Branch unterhalb von `develop` statt.
|
||
3. In `develop` mergen erst, wenn die Arbeit abgeschlossen ist und alle Tests erfolgreich waren.
|
||
4. Eine PR nach `main` wird nur auf explizite Anweisung des Nutzers geöffnet.
|
||
5. Vor jedem Merge nach `develop` und vor jeder PR nach `main` werden 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](../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](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 `develop` wird 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
|