Hard-Kriterien
- • Security & Datenvalidierung
- • Fehlerhandling & Logging
- • Performance-Killer vermeiden
- • Upgrade-Fähigkeit (Deprecations)
Architektur · Extbase/Fluid · TCA/DataHandler · OWASP · Performance · CI/CD · Tests
TYPO3 Code Review Checkliste
Qualität, Security & Wartbarkeit systematisch prüfen
Code Reviews sind in TYPO3-Projekten oft der schnellste Hebel für stabilere Releases, bessere Upgrade-Fähigkeit und weniger Support-Aufwand. Diese Checkliste ist so aufgebaut, dass du sie für Pull Requests, Audits oder Rescue-Projekte verwenden kannst – mit Prioritäten und Quick Wins.
Für Agenturen, Inhouse-Teams, öffentliche Träger & KMU
Stand: 2026-01
Was ein gutes TYPO3 Code Review liefern sollte
„Sieht gut aus“ bringt nichts, wenn Releases trotzdem eskalieren. Ein sinnvolles Review liefert konkrete Findings mit Impact, Risiko und Next Steps.
Soft-Kriterien
- • Lesbarkeit & Konsistenz
- • Schichtentrennung / Architektur
- • Entwickler-UX (DX) im Projekt
- • Doku & Handover-Fähigkeit
Die Code-Review-Checkliste (TYPO3)
Die Bereiche sind so gewählt, dass du sie wie einen Funnel nutzen kannst: erst „Kill Switches“ (Security/Fehler), dann Qualität/Architektur.
A) Architektur & Struktur
Schichten, Verantwortlichkeiten, Kopplung
- Domain-Logik ist nicht im Controller/Template versteckt
- Klare Trennung: Domain ↔ Infrastruktur (API/DB)
- Keine „God Services“ mit 800 Zeilen
- Konfiguration nicht per Copy-Paste vervielfacht
B) Extbase
Controller, Repos, Domain Model
- Repos kapseln Query-Logik (keine SQL-Fragmente überall)
- Domain Models sind nicht „Anemic“ ohne Regeln
- Validierung ist vorhanden (Form/Input)
- Dependency Injection sauber (kein Service Locator-Mix)
C) Fluid / Templates
Weniger Logik, mehr Präsentation
- Keine Business-Logik im Template (if-Orgien, Datenaufbereitung)
- ViewHelper-Nutzung nachvollziehbar und wiederverwendbar
- Output Escaping: keine unsauberen Raw-Ausgaben
- FE ist a11y-fähig (Semantik, Labels, Kontraste)
D) TCA / Backend UX
Redaktionsfreundlich & wartbar
- TCA ist modular (Overrides, Paletten, Types) statt „Monolith“
- Field-Configs sind konsistent (required, eval, renderType)
- Backend-UX ist sinnvoll (Tabs, Labels, Hilfetexte)
- DataHandler/TCEmain Hooks nur wenn nötig (sauber dokumentiert)
E) Security (🔴)
OWASP-Basics für TYPO3
- Input Validierung & Sanitizing (GET/POST/JSON)
- Auth & Rechte: FE/BE sauber getrennt, keine „Admin by accident“
- Uploads: Dateitypen/Größen, Storage Rechte, kein Direct-Exec
- Secrets: keine Tokens im Repo, Env/Secret-Management
- Output: XSS vermeiden, raw nur begründet
Wenn hier Findings auftauchen: zuerst fixen – alles andere ist „Kosmetik“.
F) Performance (🟠)
Queries, Caching, Rendering
- Keine N+1 Queries in Listen/Relationen
- Caching ist bewusst (Cache-Tags, invalidation)
- Bildpipeline & Responsive Images korrekt
- Integrationen (API) mit Timeouts & Circuit Breaker
CI/CD & Tests: der Multiplikator für „weniger Chaos“
Code kann gut aussehen und trotzdem im Release knallen. Wenn CI/CD und Tests fehlen, ist jedes Review nur eine Momentaufnahme.
- • Static Checks: phpstan, rector, Coding Guidelines
- • Security: SCA/SAST (Dependencies + Patterns)
- • Smoke-Tests: die wichtigsten Flows in 10–20 Minuten
- • Functional: Backend/FE Kernfunktionen stabil
- • Build: reproducible artifacts, Lockfile, clear releases
Typische TYPO3 Anti-Patterns (die ich ständig finde)
Wenn du diese Muster siehst, ist das fast immer ein Signal für spätere Upgrade-/Release-Probleme.
„Logik im Template“
Datenaufbereitung im Fluid, statt ViewModel/Service – wird untestbar und bricht bei Änderungen.
Copy-Paste Config
10 ähnliche TCA-Definitionen, 8 fast gleiche DataProcessor – der Wartungs-Preis explodiert.
Silent Fail
Fehler werden geschluckt („try/catch & ignore“). Das rächt sich im Betrieb.
Direct DB/Query Chaos
Random QueryBuilder überall, keine Indizes, keine Query-Strategie – Performance & Bugs garantiert.
Keine Rollback-Story
Deployments ohne Plan B sind eine Einladung an „Notfälle nach Update“.
Dependency Drift
Lockfile wild, Releases nicht reproduzierbar – „bei mir lief’s“ wird Standard.
Ergebnis eines Code Reviews: so sollte es aussehen
Wenn du Code Reviews als Deliverable einkaufst (oder intern etablierst), dann hilft ein klares Format:
1) Findings (priorisiert)
Jedes Finding mit Impact, Risiko, Empfehlung und (wenn möglich) Quick Fix.
2) Maßnahmenplan
„Was machen wir in Sprint 1?“ – realistisch, umsetzbar, mit klaren Deliverables.
3) Upgrade-/Release-Risiko
Wo würde es beim nächsten Upgrade knallen? Wo droht Downtime? Wo fehlen Tests/CI?
FAQ: Code Reviews in TYPO3-Projekten
Kurz beantwortet – damit ihr schneller entscheiden könnt.
Wie viel Code muss man wirklich lesen? ›
Nicht alles. Die größten Effekte bekommst du durch Fokus auf:
kritische Extensions, Integrationen, Security-relevante Stellen, CI/CD und die größten Hotspots
(Performance/Queries).
Macht ein Review auch Sinn, wenn wir bald upgraden? ›
Gerade dann. Ein Review identifiziert Deprecations, fragile Stellen und Extension-Risiken – bevor sie im Upgrade teuer werden.
Können wir das als Agentur-Qualitätsgate einsetzen? ›
Ja – besonders effektiv mit CI-Gates (phpstan/CGL) + kleiner Review-Checkliste pro PR.
Das reduziert Bugs und verbessert die Lieferfähigkeit.
Du willst Klarheit über Qualität & Risiken in eurem TYPO3 Code?
Wenn du willst, mache ich aus dieser Checkliste ein konkretes Review für euer Repo: priorisierte Findings, Quick Wins und ein Plan, der Releases und Upgrades stabil macht.
Unverbindlich · vertraulich · NDA/AVV möglich