2.1 KiB
👷 [Frontend Expert]
Verstanden. Ich nehme die Herausforderung an.
Ich werde diesen Scan als "Audit-Phase" behandeln. Mein Ziel ist es, nicht nur ein Chaos-Dokument zu erstellen, sondern eine "Architektur-Anleitung", die als Single Source of Truth für die zukünftige Entwicklung dient.
Hier ist mein Schlachtplan für die nächsten Schritte:
1. Der Scan (Aktueller Schritt)
Ich führe den Scan durch, um die Struktur jedes einzelnen Moduls zu erfassen. Ich werde die Pfade so mappen, dass ich genau sehe:
- Modul-Name (z.B.
features:login) - Vorhandene Source-Sets (
commonMain,jvmMain,wasmJsMain) - Status (Ist es ein "Standard-Modul" oder ein "Sonderfall"?)
2. Die Analyse (Die "Chaos-Matrix")
Aus den Rohdaten erstelle ich die Chaos-Matrix. Diese wird folgende Fragen beantworten:
- Welche Module folgen bereits einem Muster?
- Wo sind die "Inseln der Wildnis" (Module ohne jegliche Struktur)?
- Welche Abhängigkeiten (Gradle-Module) sind von der Struktur-Anpassung betroffen?
3. Die Architektur-Anleitung (Das Endprodukt)
Dies ist das Dokument, das Sie am Ende erhalten. Es wird kein bloßes Problem-Dokument sein, sondern ein Blueprint. Es wird enthalten:
- Die "Golden Rule" der Modul-Struktur: Die definierte Standard-Struktur für jedes neue Modul.
- Die "Migration-Matrix": Eine Liste aller existierenden Module mit der Anweisung: "Modul X muss von Struktur A nach Struktur B migriert werden".
- Das "Pattern-Library" Dokument:
- Wie ein
feature-Modul aufgebaut sein muss (mitcommonMainundjvmMain). - Wie ein
library-Modul aufgebaut sein muss (reincommonMain). - Wie ein
platform-Modul aufgebaut sein muss (z.B. für Android oder Desktop-spezifische Erweiterungen). - Die "Definition of Done" (DoD) für neue Module: Eine Checkliste, die ein Entwickler abhaken muss, bevor ein Modul als "fertig" gilt.
Ich starte jetzt den Scan.
(Ich werde nach Abschluss des Scans und der Erstellung der Matrix sofort mit der Analyse beginnen.)
`[Status: Running Structural Scan...]