# PERSÖNLICHE PRÄFERENZEN

## TECH-STACKS

### Frontend
- **Framework:** React, Next.js
- **Styling:** Tailwind CSS
- **Language:** TypeScript
- **State:** React Context, Zustand (bei Bedarf)

### Backend
- **Framework:** Django 5.2+, Django REST Framework
- **Language:** Python 3.12+
- **Task Queue:** Celery mit Redis
- **Optimization:** PuLP, FICO Xpress

### Database
- **Production:** PostgreSQL
- **Development:** SQLite
- **Cache/Broker:** Redis

### Infrastructure
- **Container:** Docker (Multi-Stage Builds)
- **Orchestration:** K3s
- **Monitoring:** Prometheus, Loki, Grafana
- **CI/CD:** GitLab CI

---

## CODING STYLE

### Python / Django
- **Type Hints:** Immer verwenden (`str | None` statt `Optional[str]`)
- **Docstrings:** Google-Style für öffentliche APIs
- **Imports:** Absolute Imports bevorzugen, gruppiert (stdlib, third-party, local)
- **Line Length:** 88 Zeichen (Black-Standard)
- **String Quotes:** Double Quotes für Strings
- **F-Strings:** Bevorzugt gegenüber `.format()` oder `%`

### Django-spezifisch
- **Views:** Fat Models, Thin Views
- **Queries:** Immer `select_related`/`prefetch_related` für Relations
- **Naming:** Models singular (`Match`), related_name plural (`matches`)
- **Managers:** Custom Manager für häufige Queries

### TypeScript / React
- **Components:** Functional Components mit Hooks
- **Naming:** PascalCase für Components, camelCase für Funktionen
- **Props:** Destructuring im Funktions-Signatur
- **CSS:** Tailwind Utility Classes, keine Custom CSS wenn vermeidbar

### Allgemein
- **Comments:** Englisch im Code
- **No Magic Numbers:** Konstanten mit sprechenden Namen
- **Error Messages:** Hilfreich und kontextbezogen
- **DRY:** Duplikation erst ab 3. Vorkommen abstrahieren

---

## WORKFLOW

### Dokumentation
- Format: Markdown
- Sprache: Deutsch für Nutzer-Dokumentation, Englisch für Code-Docs
- Tool: MkDocs mit Material Theme

### Git
- **Commits:** Konventionelle Commit-Messages (feat, fix, refactor, docs, test)
- **Branches:** `feature/`, `fix/`, `refactor/` Prefixes
- **PRs:** Klare Beschreibung, Test-Plan, Reviewer zuweisen

### Testing
- **Unit Tests:** pytest / Django TestCase
- **Coverage:** Minimum 80% für kritische Pfade
- **Mocking:** `unittest.mock` oder `pytest-mock`

### Code Review
- **Fokus:** Security > Correctness > Performance > Style
- **Feedback:** Konstruktiv, mit Alternativen
- **Blocking:** Nur bei Security/Correctness Issues

---

## ABNEIGUNGEN (Was ich NICHT will)

- Over-Engineering ohne konkreten Nutzen
- Premature Optimization
- Magic Imports (implizite Abhängigkeiten)
- Riesige Commit-Messages ohne Substanz
- `any` Types in TypeScript
- Undokumentierte Public APIs
- Tests ohne Assertions

---

*Letzte Aktualisierung: 2026-02-04*