Strukturierte Dokumentation für Softwareprojekte¶
Ein praxiserprobtes System für Projektdokumentation, das mit dem Code lebt.
Dokumentation ist einer der meistunterschätzten Aspekte der Softwareentwicklung. Ohne klare Struktur veraltet sie schnell, wird inkonsistent oder geht ganz verloren. Dieses System löst das Problem durch eine feste Ordnerstruktur, klare Namenskonventionen und automatisierte Validierung.
Warum strukturierte Dokumentation?¶
In vielen Projekten beginnt Dokumentation als lose Sammlung von Markdown-Dateien im Root-Verzeichnis. Mit der Zeit wachsen diese Dateien unkontrolliert: Doppelte Inhalte, veraltete Informationen und fehlende Verlinkung machen die Dokumentation unbrauchbar.
Das hier beschriebene System wurde über mehrere Projekte hinweg entwickelt und verfeinert. Es basiert auf drei Grundprinzipien:
- Feste Ordnerstruktur -- Jeder Dokumenttyp hat einen definierten Platz
- Automatisierte Validierung -- Scripts prüfen Konsistenz und Vollständigkeit
- Tool-Integration -- Claude Code Rules erzwingen die Einhaltung
Das 4-Ordner-System¶
Die Dokumentation lebt im docs/-Verzeichnis und ist in vier Hauptkategorien unterteilt:
| Ordner | Zielgruppe | Inhalt |
|---|---|---|
architecture/ | Entwickler | System-Design, ADRs, Sicherheitskonzepte |
development/ | Entwickler | Setup-Anleitungen, Workflow, Testing, Tool-Guides |
operations/ | Betrieb / Kunden | Deployment, Backup, Monitoring, Disaster Recovery |
reference/ | Beide | Übersichten, Environment Variables, Port-Referenzen |
Zusätzlich gibt es optionale Ordner:
templates/-- Code-Templates für wiederkehrende Muster (z.B. ERP-Integration)examples/-- Vollständige Integrationsbeispieleplans/-- Temporäre Feature-Pläne (werden nach Abschluss gelöscht)
Diese Trennung sorgt dafür, dass Entwickler schnell die richtige Information finden und Betriebsdokumentation nicht mit internen Entwicklernotizen vermischt wird.
Namenskonventionen¶
Einheitliche Benennung ist entscheidend für die Auffindbarkeit:
| Kontext | Konvention | Beispiel |
|---|---|---|
| Ordner | kebab-case | architecture/, development/ |
| Dateien in Unterordnern | kebab-case.md | getting-started.md, erp-integration.md |
| Root-Level Dateien | UPPER_CASE.md | README.md, CODEBASE_KNOWLEDGE.md |
Root-Level Dateien wie CODEBASE_KNOWLEDGE.md dienen als Einstiegspunkt und verlinken auf die Detail-Dokumentation in den Unterordnern. Dieses Muster hält die Top-Level-Übersicht kurz und verweist für Details in die Tiefe.
Automatisierte Validierung¶
Ein Shell-Script (check-docs.sh) prüft die Dokumentation auf häufige Probleme:
- Verwaiste Dateien -- Markdown-Dateien, die nirgends verlinkt sind
- Tote Links -- Verweise auf nicht existierende Dateien
- Namenskonventionen -- Dateien, die nicht dem kebab-case-Muster folgen
- Leere Dateien -- Platzhalter, die nie mit Inhalt gefüllt wurden
Das Script lässt sich in die CI/CD-Pipeline integrieren, sodass fehlerhafte Dokumentation den Build blockiert -- genauso wie fehlerhafte Tests.
# Dokumentation validieren
./scripts/check-docs.sh
# Beispiel-Output
[OK] 24 Dateien geprüft
[WARN] docs/development/old-guide.md ist nicht verlinkt
[ERROR] docs/architecture/security.md verweist auf nicht existierende Datei
Claude Code Integration¶
Die stärkste Komponente dieses Systems ist die Integration mit Claude Code. Durch Rules in .claude/rules/ wird sichergestellt, dass die Dokumentationsstruktur bei jeder Änderung eingehalten wird:
documentation.md-- Definiert die Ordnerstruktur und Naming-Konventionenci-fix.md-- Regelt das Löschen erledigter Pläne und Issuesverification.md-- Erzwingt die Ausführung von Validierungs-Scripts
Wenn Claude Code ein neues Feature implementiert, erstellt es automatisch die zugehörige Dokumentation im richtigen Ordner, verlinkt sie in der Übersicht und führt die Validierung aus. Die Regel "Kein Feature ohne Doku" wird damit technisch durchgesetzt, nicht nur organisatorisch vereinbart.
Setup für eigene Projekte¶
Das gesamte System ist als Template verfügbar:
- Template klonen -- aebionix/docs-template als Basis verwenden
- Ordnerstruktur anlegen -- Die vier Hauptordner erstellen
- CODEBASE_KNOWLEDGE.md erstellen -- Als zentrale Übersicht
- Claude Code Rules kopieren --
documentation.mdundverification.mdin.claude/rules/ - Validierungs-Script einrichten --
check-docs.shanpassen und in CI integrieren
Erfahrungen aus dem OPC-Projekt¶
Das OPC-Projekt war das erste, in dem dieses System vollständig eingesetzt wurde. Einige Erkenntnisse:
- Früh starten lohnt sich -- Dokumentation nachträglich zu strukturieren ist um ein Vielfaches aufwändiger als von Anfang an ein System zu haben
- Automatisierung ist Pflicht -- Ohne automatisierte Validierung driftet die Dokumentation innerhalb weniger Wochen ab
- Temporäre Dateien aufräumen -- Der
plans/-Ordner muss aktiv gepflegt werden, sonst sammeln sich veraltete Pläne an - DRY gilt auch für Doku -- Information an genau einer Stelle, Verweise von überall sonst
- Claude Code Rules sparen enorm Zeit -- Statt bei jedem Commit manuell zu prüfen, erzwingt das Tool die Einhaltung automatisch
Das System hat sich in der Praxis bewährt: Die Dokumentation bleibt aktuell, neue Teammitglieder finden sich schnell zurecht, und die Struktur skaliert mit dem Projekt.