Prädikat has_documentation
Code, den niemand versteht, ist wie eine Landkarte ohne Beschriftung - technisch korrekt, aber praktisch nutzlos. Das Prädikat has_documentation stellt sicher, dass Änderungen nicht nur funktionieren, sondern auch verstanden werden können.
Dokumentation ist keine Kür
Viele Teams behandeln Dokumentation als optionales Extra. Aber was passiert, wenn der ursprüngliche Entwickler das Projekt verlässt? Wenn eine KI den Code weiterentwickeln soll? Ohne Dokumentation wird jede Änderung zum Ratespiel.
Vollständiges Beispiel
Definition des Dokumentations-Prädikats:
# Prädikat: has_documentation
# Verwendet in: Gate G4 (Implementation), Gate G5 (Review)
predicate:
id: "has_documentation"
name: "Dokumentation vorhanden"
description: "Prüft, ob alle Änderungen ausreichend dokumentiert sind"
category: "quality"
severity: "high"
# Was wird geprüft?
checks:
- id: "code_comments"
name: "Code-Kommentare"
rules:
- "public_methods_have_docblock"
- "complex_logic_explained"
- "no_todo_without_ticket"
- id: "api_docs"
name: "API-Dokumentation"
required_for:
- file_pattern: "**/api/**"
- file_pattern: "**/public/**"
rules:
- "openapi_spec_updated"
- "all_endpoints_documented"
- "examples_provided"
- id: "readme_updated"
name: "README aktualisiert"
required_for:
- change_type: "new_feature"
- change_type: "breaking_change"
rules:
- "installation_steps_current"
- "usage_examples_present"
- id: "changelog_entry"
name: "CHANGELOG-Eintrag"
required_for:
- change_class: "normal"
- change_class: "critical"
rules:
- "version_number_valid"
- "change_description_meaningful"
# Erfolgskriterien
success_criteria:
all_required_docs_present: true
no_broken_links: true
examples_executable: true
Auswertung in der Praxis
# Dokumentations-Check Ergebnis
evaluation:
predicate_id: "has_documentation"
change_id: "CHG-2024-0045"
change_type: "new_feature"
evaluated_at: "2024-01-15T14:00:00Z"
check_results:
- check_id: "code_comments"
passed: true
details:
files_checked: 12
methods_checked: 47
coverage:
public_methods: "100%"
complex_sections: "95%"
findings:
- file: "src/Services/PaymentService.php"
line: 89
type: "info"
message: "Consider adding example in docblock"
- check_id: "api_docs"
passed: true
details:
endpoints_documented: 5
openapi_valid: true
examples_present: true
- check_id: "readme_updated"
passed: true
details:
sections_updated:
- "Installation"
- "Configuration"
- "Usage"
last_update: "2024-01-15T13:45:00Z"
- check_id: "changelog_entry"
passed: true
details:
version: "2.3.0"
entry: "Added payment retry functionality"
category: "Added"
result: true
evidence:
docblock_coverage: "reports/phpdoc-coverage.html"
openapi_spec: "docs/api/openapi.yaml"
changelog_diff: "git diff CHANGELOG.md"
Warum ist das wichtig?
Dokumentation ist Wissenstransfer in die Zukunft. Sie ermöglicht es Menschen und KI, Code zu verstehen, zu warten und weiterzuentwickeln. Im Mensch + KI-Code Prozess ist gute Dokumentation keine Option, sondern eine formale Anforderung.
Im Mensch + KI-Code Prozess: Bei Change Class "Trivial" reichen Code-Kommentare. Bei "Normal" und "Critical" sind zusätzlich API-Docs und CHANGELOG-Einträge erforderlich. Das Prädikat wird am Gate G4 (Implementation) geprüft.