Developer Cockpit
Zentrale Arbeitsfläche für Projektzustand, Risiken, Entscheidungen und nächste technische Schritte. Nutze die Seite für eine konkrete Engineering-Aufgabe: Kläre zuerst Ziel und Risiko und halte danach Ergebnis, Nachweis und nächsten Schritt fest.
Arbeitsauftrag
Wann verwenden?
Zu Beginn einer Änderung, eines Incidents oder einer technischen Initiative mit unklarem Umfang.
Nicht dafür verwenden
Nicht als dauerhaftes Statusdashboard ohne konkrete nächste Entscheidung.
Definition of Done
Ziel, betroffene Bereiche, Risiken, Owner, Evidence und der nächste überprüfbare Schritt sind sichtbar.
Projekt-Startdiagnose
Ein Senior beginnt nicht mit dem ersten gefundenen Ticket, sondern mit einem belastbaren Systembild. Das Cockpit bündelt fachlichen Zweck, Modulgrenzen, Laufzeitabhängigkeiten, Qualitätsindikatoren und offene Risiken.
Die Startdiagnose trennt Fakten, Annahmen und offene Fragen. Dadurch werden vorschnelle Architekturentscheidungen und unbemerkte Seiteneffekte vermieden.
Projekt: Order Platform
Fachlicher Zweck: Auftragserfassung und Preisfindung
Java: 21
Build: Maven Multi-Modul
Architektur: modularer Monolith, hexagonale Modulgrenzen
Kritische Abhängigkeiten: PostgreSQL, Kafka, Identity Provider
Offene Risiken: unklare Idempotenz bei Wiederholungsaufträgen
Änderungsradar
Jede Änderung wird entlang von Domäne, API, Daten, Events, Sicherheit, Betrieb und Migration bewertet. Das Radar verhindert, dass eine lokal kleine Codeänderung global große Folgen auslöst.
Für jeden Bereich wird nur festgehalten, was wirklich betroffen ist. Nicht betroffene Bereiche werden bewusst markiert, statt stillschweigend ignoriert zu werden.
Änderung: Neue Rabattregel
Domäne betroffen – neue Invariante
API nicht betroffen
Datenbank betroffen – neue Regelversion
Events betroffen – Preisberechnung nachvollziehbar machen
Security nicht betroffen
Observability betroffen – fachliche Kennzahl ergänzen
Rollback Regelversion zurückschalten
Definition of Ready und Done
Die Workbench stellt zwei kurze Gates bereit: Vor der Umsetzung müssen Problem, Akzeptanzkriterien, Randbedingungen und Risiken verstanden sein. Nach der Umsetzung müssen Verhalten, Tests, Architektur, Dokumentation und Betriebsfähigkeit überprüft sein.
Praxisartefakt · Change Brief
- Ziel
- Kunde kann eine noch nicht versandte Bestellung vollständig stornieren.
- Betroffen
- Order API, Payment-Erstattung, Shipping-Status und Audit.
- Größtes Risiko
- Stornierung und Versand kreuzen sich zeitlich.
- Nachweis
- Sequenztest, Contract-Tests, Metrik für ausstehende Erstattungen und Rollback-Probe.
- Nächster Schritt
- Invariante mit Product und Shipping-Owner verbindlich klären.