Was macht Umstrukturierungs-Entwicklungsworkflow?
Nutzen Sie diesen Skill, um ein Architektur-Redesign in ein entwicklungsbereites Paket zu verwandeln. Das Ergebnis ist nicht nur ein Diagramm: Es ist ein abgegrenzter Vertrag darüber, was gebaut wird, wie migriert wird, wie getestet wird und was nicht unterstützt bleibt. Behandeln Sie die Umstrukturierung als ein fortlaufendes Migrationsprogramm. Jedes Paket ist ein überprüfbares Lieferinkrement, kein Versprechen, das gesamte zukünftige System zu spezifizieren oder zu implementieren.
Betriebsprinzipien
- Autorität von Absicht trennen. Lesen Sie zuerst aktuellen Code, Tests, Architekturautorität und Repository-Anweisungen. Kennzeichnen Sie Redesign-Dokumente als Ziel, Plan oder Beweis; präsentieren Sie sie niemals als aktuelles Verhalten.
- Vorhandenes benennen. Ordnen Sie jedes vorgeschlagene Modul aktuellen Klassen, Verträgen, Registern, Speichern oder Einstiegspunkten zu. Verstecken Sie vorhandenen Inhalt nicht hinter erfundenen Substantiven.
- Eigentum explizit machen. Geben Sie an, was jede Grenze besitzt und nicht besitzen darf, wer dauerhafte Fakten schreibt, wer Mutationen autorisiert und wer für die Wiederherstellung zuständig ist.
- Abstraktionen von echten Konsumenten verdienen. Lassen Sie eine neue Abstraktion nur zu, wenn ein echter Konsument eine benannte Abhängigkeit entfernt, eine echte Registrierung vereinheitlicht oder eine Invariante durchsetzbar macht. Eine generische Abstraktion benötigt normalerweise zwei Konsumenten; eine enge Sicherheitsgrenze kann für einen Konsumenten zugelassen werden.
- Mit einem echten vertikalen Ausschnitt beginnen. Bewahren Sie ein Legacy-Fixture und fügen Sie ein Zielgrenzen-Fixture für dasselbe Szenario hinzu. Ein synthetischer Graph kann die Mechanik testen, aber nicht die Architektur beweisen.
- Verträge vor dem Ersetzen einfrieren. Definieren Sie Ein- und Ausgaben, Autorisierung, Identität, Idempotenz, Fehler, Persistenz, Wiederherstellung und Kompatibilität, bevor Sie eine konkrete Abhängigkeit entfernen.
- Leistung als Beweis behandeln, nicht als Rechtfertigung. Bewahren Sie zuerst Autorität, dauerhafte Kompatibilität und Wiederherstellung; messen Sie dann äquivalente Arbeitslasten im Vergleich zum aktuellen Pfad.
- Dokumente wartbar halten. Geben Sie jeder Behauptung einen kanonischen Besitzer, halten Sie den Status aktuell/Ziel/Historie sichtbar und verlinken Sie auf Richtlinien, anstatt sie über Dokumente hinweg zu kopieren.
- Für aufeinanderfolgende Lieferungen planen. Jedes Inkrement gibt Liefergegenstände, Zurückstellungen, seinen nächsten Fortschrittsauslöser und erforderliche Beförderungsnachweise an.
Workflow und Modulladung
Stufe 1 (L1) bedeutet Systemgrenzen, Stufe 2 (L2) bedeutet stabile Modul-/Grenzenverträge und Stufe 3 (L3) bedeutet aufgabenspezifische Implementierungsdetails. Ordnen Sie die vorhandenen Bezeichnungen eines Projekts diesen Bedeutungen zu, anstatt eine zweite Taxonomie einzuführen.
Zuerst richtig dimensionieren. Lesen Sie
references/deliverable-matrix.md und wählen Sie
das kleinste Paket aus, das die nächste Entscheidung überprüfbar macht. Die folgenden Phasen
sind der vollständige Pfad, keine obligatorische Checkliste für jede Anfrage. Laden Sie die
anderen Referenzen nur, wenn die entsprechende Phase oder das entsprechende Anliegen aktiv ist.
Jedes Paket oder Migrationsinkrement muss einen Lieferhorizont deklarieren. Die Liefermatrix besitzt das Schema, die Design-only-Reduktion, Zurückstellungen und Fortschrittsbedingungen.
Phase 0 – Autorität und Ausgangsbasis klären
- Lesen Sie Repository-Anweisungen, README, Entwicklungsrichtlinien und Architekturautorität, falls vorhanden.
- Durchsuchen Sie Orientierungs-, Dokumentations-, Release-, Migrations-, Aufgaben- und Übergabe- aufzeichnungen, bevor Sie schlussfolgern, dass kein früheres Umstrukturierungsprogramm existiert.
- Lesen Sie für jedes aktive Programm, das für die Anfrage relevant ist, dessen neuestes Inkrement- protokoll, überprüfte Entscheidungen, ungelöste Zurückstellungen, offene L1/L2-Behauptungen, ADRs und die aufgezeichnete nächste Aufgabe, bevor Sie den neuen Umfang definieren.
- Überprüfen Sie den vorherigen Fortschrittsauslöser und die Beförderungsnachweise. Wenn einer von beiden nicht erfüllt ist oder ein blockierender Befund offen bleibt, präsentieren Sie dem Benutzer den Status und die Optionen, bevor Sie fortfahren. Wenn der Benutzer eine Ausnahme autorisiert, protokollieren Sie den Grund, den Genehmiger und den betroffenen Umfang im aktuellen Inkrement- protokoll.
- Identifizieren Sie die Quellhierarchie und die genaue Ausgangsrevision. Überprüfen Sie aktuelle Einstiegspunkte, Zustands-/Dateninhaber, Persistenz, Tests, Beispiele und Erweiterungsregister, sofern vorhanden.
- Protokollieren Sie, was implementiert ist, was Zielabsicht ist und was unbekannt ist.
- Bevor Sie eine reduzierte Kopplung behaupten, erstellen Sie ein reproduzierbares Abhängigkeits- oder Registrierungsinventar: einen wiederholbaren Befehl/ein Skript, einen eingecheckten Ausgabe- oder Bericht, und dieselbe Methode, die für den Vorher/Nachher-Vergleich wiederverwendet wird.
Folgen Sie dem vorhandenen Aufgabenverzeichnis, Issuesystem und Übergabeformat des Repositorys. Verlangen Sie kein bestimmtes Kollaborationstool und verwenden Sie keine Konversationshistorie als Architekturautorität.
Phase 1 – Positionierung und Umfang
Protokollieren Sie:
- was das System ist und wer darauf aufbaut;
- das Problem, das durch die aktuelle Kopplung oder das Wachstum verursacht wird;
- die erste Einsatzgrenze;
- Nicht-Ziele und zurückgestellte Fähigkeiten;
- abgegrenzte Vorteile und die Vergleichsbasis für jede Behauptung.
Legen Sie gleichzeitig ein Komplexitätsbudget fest. Laden Sie
references/document-and-complexity-gates.md
für das Budget, Dokumenteigentumsregeln und Stoppbedingungen. Bevorzugen Sie abgegrenzte Behauptungen
gegenüber Wörtern wie „modularer“ oder „skalierbarer“.
Benutzerentscheidungsgates
Leiten Sie Produktabsichten nicht aus Code oder Diagrammen ab. Wenn Repository-Nachweise eine wesentliche Frage zu Umfang, Eigentum, Bereitstellung, Kompatibilität, Sicherheit, Erfolgskriterien oder Migrationsreihenfolge nicht beantworten können, halten Sie inne und fragen Sie den Benutzer. Bündeln Sie verwandte Entscheidungen, zeigen Sie beobachtete Fakten und Abwägungen und empfehlen Sie eine konservative Standardeinstellung, wenn dies gerechtfertigt ist.
Verwenden Sie references/user-decision-gates.md für
die phasenspezifischen Fragen und dauerhaften Aufzeichnungsorte. Wenn der Benutzer eine wesentliche
Entscheidung explizit delegiert, wählen Sie die empfohlene oder am besten unterstützte reversible
Option, protokollieren Sie die Delegation und Annahmen und fahren Sie fort. Machen Sie unwesentliche
reversible Annahmen explizit, anstatt den Fortschritt zu blockieren.
Phase 2 – L1-Zielarchitektur
Definieren Sie Hauptsubsysteme oder Koordinationsebenen, Zustands-/Datenautoritäten und alleinige Schreiber, Identitätseigentum, Abhängigkeitsrichtung, Anwendungseinstiegspunkt, Prozess-/Einsatzgrenzen und kontrollierte Kommunikationsformen.
L1 ist vor der Implementierungsrichtung für das im Umfang befindliche Ziel erforderlich und explizit. Es muss nicht jedes zukünftige Modul beschreiben, aber es darf Eigentum, Abhängigkeitsrichtung oder Einsatzumfang nicht mehrdeutig lassen. Benennen Sie ungelöste L1-Fragen mit einem Besitzer und einem Entscheidungsgate.
Laden Sie references/architecture-contracts.md
für L1-Diagrammregeln und die L2/L3/Schnittstellenschemata, die in späteren Phasen verwendet werden.
Phase 3 – Aktuell-Ziel-Zuordnung
Klassifizieren Sie für jeden aktuellen Hotspot die erste Aktion als beibehalten, exponieren, anpassen, aufteilen, konsolidieren, verwerfen oder entfernen. Protokollieren Sie aktuellen Besitzer, Zielbesitzer, beibehaltenen Kommunikations-/Persistenzpfad und Entfernungsgate. Behalten Sie den Lieferhorizont als den kanonischen Besitzer detaillierter Zurückstellungen.
Erstellen Sie kein Dokument nur, weil ein Thema interessant ist. Finden Sie zuerst den kanonischen Besitzer; erstellen Sie ein neues Dokument nur, wenn sich Eigentum, Status, Zielgruppe oder Lebenszyklus wesentlich unterscheiden.
Phase 4 – L2-Modulverträge
Erstellen Sie einen L2-Vertrag pro stabilem Modul oder modulübergreifender Grenze. Behandeln Sie Verantwortung und Nicht-Verantwortung, aktuelle Komponenten, bereitgestellte/benötigte Dienste, Schreibautorität, erlaubte Aufrufe/Datensichtbarkeit, Lebenszyklus/Fehler, Kompatibilität und Entscheidungen, die auf die Implementierung verschoben wurden.
L2 kann im ersten Paket unvollständig bleiben. Kennzeichnen Sie wesentliche Behauptungen als etabliert, bedingt oder offen. Jede offene Wahl benötigt ein abgegrenztes Experiment, eine Nachweisschwelle oder ein Implementierungsgate, das sie auflösen kann; erfinden Sie keine Präzision nur des Anscheins wegen.
Verwenden Sie die L2- und Interaktionsformregeln in
references/architecture-contracts.md.
Verwenden Sie die Navigations- und Kanonischer-Besitzer-Prüfungen in
references/document-and-complexity-gates.md,
wenn das Paket mehrere Dokumente enthält.
Phase 5 – MVP und aufgabenlokaler Vertrag
Wählen Sie die kleinste echte geschlossene Schleife, die die beabsichtigte Grenze trainiert. Ein Lese-/Lebenszyklusabschluss-Ausschnitt kann einem ersten Schreibgrenzen-Ausschnitt vorausgehen. Bewahren Sie lokale MVP-Bezeichnungen nur in Verbindung mit einem beschreibenden Namen und geben Sie genau an, was der Ausschnitt beweist und was nicht beweist.
Bevor Sie eine abgegrenzte Implementierungsaufgabe codieren, frieren Sie nur den L3-Vertrag ein,
der von dieser Aufgabe konsumiert wird. Er bleibt ein Kandidat, bis die Implementierungsaufgabe
ihn übernimmt oder Überarbeitungen daran aufzeichnet. Erstellen Sie keine L3-Dokumente für nicht
ausgewählte Module. Verwenden Sie die L3- und Schnittstellencheckliste in
references/architecture-contracts.md.
Phase 6 – Adversarial Review und bidirektionaler Steelman
Führen Sie einen adversarialen Durchlauf durch, der versucht, Eigentums-, Wiederherstellungs-, Kompatibilitäts-, Migrations- und Beweisbehauptungen zu brechen, gefolgt von einem Steelman, der den stärksten Wert und bewusst konservative Grenzen darlegt. Bevorzugen Sie einen unabhängigen Prüfer, der das Paket nicht geschrieben hat; verwenden Sie andernfalls einen neuen Kontext und legen Sie die Einschränkung offen.
Verwenden Sie references/adversarial-review.md für den
Überprüfungszeitpunkt, Fragen und das einzige Abstimmungsprotokoll. Verarbeiten Sie jeden Befund
sofort. Ein blockierender Befund hält das Gate geschlossen, bis das Risiko behoben oder explizit
als Ausnahme durch den Benutzer oder einen unabhängigen Prüfer herabgestuft/akzeptiert wurde;
Alleiniges Ablehnen oder Verschieben öffnet das Gate nicht.
Phase 7 – Migration, Verifizierung und Beförderung
Definieren Sie gestaffelte Migration mit Kompatibilitätsschichten, Abbruchbedingungen, Entfernungsgates, Rollback-/Neustartgrenzen, Legacy-/Ziel-Fixtures und äquivalenten Nachweisen. Befördern Sie Zieltext in die aktuelle Architektur erst, nachdem die Implementierung, die Kompatibilitätsnachweise und die Aktualisierungen der Repository-Autorität gemeinsam zusammengeführt wurden.
Wählen Sie am Ende jedes Inkrements ein Ergebnis aus: fortsetzen, ein benanntes Experiment ausführen,
das Ziel/den Vertrag überarbeiten oder anhalten und den aktuellen Pfad beibehalten. Das nächste
Inkrement beginnt erst, wenn sein Auslöser und die Beförderungsnachweise erfüllt sind. Laden Sie
references/migration-and-promotion.md
für detaillierte Nachweise, Experimente und ADR-Regeln.
Phase 8 – Übergabe und Veröffentlichung
Vor der Veröffentlichung:
- validieren Sie Metadaten, Links, Kataloge und relevante Konformitäts-/Regressionstests;
- überprüfen Sie das vollständige Diff auf nicht zusammenhängende Dateien oder nicht unterstützte Implementierungsbehauptungen;
- aktualisieren Sie den vorhandenen Änderungs-/Übergabedatensatz des Projekts;
- machen Sie den Inkrementdatensatz über einen Orientierungs- oder Katalogeintrag auffindbar;
- geben Sie die genaue nächste Aufgabe und den Besitzer an.
Erstellen Sie keinen PR und pushen Sie keinen Branch, es sei denn, der Benutzer autorisiert diese externe Mutation. Wenn autorisiert, beschreiben Sie das Paket als Ziel-Design/Dokumentation, es sei denn, das Laufzeitverhalten hat sich tatsächlich geändert.
Optionale Belange
Plugins, Versionskoexistenz, Prozessisolierung, Hot Replacement und dynamisches Entladen sind
keine Standard-Architekturanforderungen. Laden Sie
references/optional-concerns.md nur, wenn das angeforderte
Design tatsächlich einen dieser Belange aktiviert.
Modul-Routing
| Bedarf | Laden |
|---|---|
| Das kleinste Artefaktset und den Lieferhorizont auswählen | deliverable-matrix.md |
| Eine wesentliche Benutzerentscheidung erfragen oder aufzeichnen | user-decision-gates.md |
| L1/L2/L3 oder eine implementierungsorientierte Schnittstelle definieren | architecture-contracts.md |
| Dokumentenwachstum, Komplexität oder Überdesign kontrollieren | document-and-complexity-gates.md |
| Adversarial Review und Steelman durchführen | adversarial-review.md |
| Migration, Experimente, ADRs oder Beförderung planen | migration-and-promotion.md |
| Plugins, Isolation oder Versionskoexistenz entwerfen | optional-concerns.md |
Laden Sie nicht jedes Modul standardmäßig. Die aktive Phase und das angeforderte Lieferobjekt bestimmen, welche Referenzen benötigt werden.
Nicht tun
- Schreiben Sie nicht die gesamte Codebasis neu, bevor Sie einen echten Ausschnitt bewiesen haben.
- Machen Sie nicht jede Datei/Klasse zu einem Plugin.
- Erstellen Sie keine doppelten Zustandsinhaber, Scheduler, Stores, Busse oder Lebenszyklus- autoritäten ohne eine explizite Zielentscheidung und ein Fehlermodell.
- Verstecken Sie keine gemischten Verantwortlichkeiten hinter einem umbenannten Durchreich-Wrapper.
- Behaupten Sie keine Entkopplung allein aufgrund einer niedrigeren Abhängigkeitsanzahl.
- Verwenden Sie keine synthetische Demo als primäre MVP-Ausstiegsbedingung.
- Lassen Sie nicht zu, dass die Erweiterungsbereinigung die Domänenvollständigkeit oder -zerstörung impliziert.
- Behandeln Sie Aufgabenhinweise, Benchmark-Ergebnisse oder generierte Prosa nicht als aktuelle Architekturautorität.