Flux de Travail de Rearchitecture Incrémentale

Que fait Flux de Travail de Rearchitecture Incrémentale ?

Utilisez cette compétence pour transformer une refonte architecturale en un package prêt pour le développement. Le résultat n'est pas simplement un diagramme : c'est un contrat borné définissant ce qui sera construit, comment il migrera, comment il sera testé et ce qui reste non supporté. Considérez la réarchitecture comme un programme de migration continu. Chaque package est un incrément de livraison révisable, et non une promesse de spécifier ou d'implémenter l'ensemble du système futur.

Principes opérationnels

1. Séparez l'autorité de l'intention. Lisez d'abord le code actuel, les tests, l'autorité architecturale et les instructions du dépôt. Marquez les documents de refonte comme cible, plan ou preuve ; ne les présentez jamais comme un comportement actuel.
2. Nommez les choses existantes. Associez chaque module proposé aux classes, contrats, registres, magasins ou points d'entrée actuels. Ne dissimulez pas le contenu existant derrière des noms inventés.
3. Rendez la propriété explicite. Indiquez ce que chaque frontière possède et ne doit pas posséder, qui écrit les faits durables, qui autorise les mutations et qui possède la reprise.
4. Gagnez les abstractions à partir de consommateurs réels. N'admettez une nouvelle abstraction que lorsque un consommateur réel supprime une dépendance nommée, unifie un enregistrement réel ou rend une invariant enforceable. Une abstraction générique nécessite normalement deux consommateurs ; une frontière de sécurité étroite peut être admise pour un seul.
5. Commencez par une tranche verticale réelle. Conservez un dispositif de test existant et ajoutez un dispositif de test cible pour le même scénario. Un graphe synthétique peut tester la mécanique mais ne peut pas prouver l'architecture.
6. Gelez les contrats avant le remplacement. Définissez les entrées, sorties, autorisation, identité, idempotence, échec, persistance, reprise et compatibilité avant de supprimer une dépendance concrète.
7. Traitez la performance comme une preuve, pas une justification. Préservez d'abord l'autorité, la compatibilité durable et la reprise ; mesurez ensuite des charges de travail équivalentes par rapport au chemin actuel.
8. Gardez les documents maintenables. Attribuez à chaque affirmation un propriétaire canonique unique, maintenez le statut actuel/cible/historique visible et liez à la politique au lieu de la copier à travers les documents.
9. Planifiez la livraison successive. Chaque incrément indique les livrables, les reports, son prochain déclencheur d'avancement et la preuve de promotion requise.

Workflow et chargement des modules

Le niveau 1 (L1) désigne les frontières du système, le niveau 2 (L2) les contrats stables de module/frontière et le niveau 3 (L3) les détails d'implémentation spécifiques à une tâche. Associez les étiquettes existantes d'un projet à ces significations plutôt que d'introduire une seconde taxonomie.

Dimensionnez correctement d'abord. Lisez references/deliverable-matrix.md et sélectionnez le plus petit package qui rend la prochaine décision révisable. Les phases ci-dessous sont le chemin complet, pas une liste de contrôle obligatoire pour chaque demande. Chargez les autres références uniquement lorsque leur phase ou préoccupation correspondante est active.

Chaque package ou incrément de migration doit déclarer un horizon de livraison. La matrice de livrable possède le schéma, la réduction de conception uniquement, les reports et les conditions d'avancement.

Phase 0 — Résoudre l'autorité et la ligne de base

• Lisez les instructions du dépôt, le README, les directives de développement et l'autorité architecturale s'ils existent.
• Recherchez les enregistrements d'orientation, de documentation, de version, de migration, de tâche et de passation avant de conclure qu'aucun programme de réarchitecture antérieur n'existe.
• Pour chaque programme actif pertinent pour la demande, lisez son dernier enregistrement d'incrément, les décisions de révision, les reports non résolus, les revendications L1/L2 ouvertes, les ADR et la prochaine tâche enregistrée avant de définir une nouvelle portée.
• Vérifiez le déclencheur d'avancement précédent et la preuve de promotion. Si l'un ou l'autre est non satisfait, ou si une conclusion bloquante reste ouverte, présentez l'état et les options à l'utilisateur avant de continuer. Si l'utilisateur autorise une exception, enregistrez la raison, l'approbateur et la portée affectée dans l'enregistrement de l'incrément actuel.
• Identifiez la hiérarchie source et la révision de base exacte. Inspectez les points d'entrée actuels, les propriétaires d'état/données, la persistance, les tests, les exemples et les registres d'extension lorsqu'ils sont présents.
• Enregistrez ce qui est implémenté, ce qui est une intention cible et ce qui est inconnu.
• Avant de revendiquer un couplage réduit, créez un inventaire reproductible des dépendances ou d'enregistrement : une commande/script réexécutable, une sortie ou un rapport vérifié dans le dépôt, et la même méthode réutilisée pour la comparaison avant/après.

Suivez le registre de tâches existant du dépôt, le système de tickets et le format de passation. N'exigez pas un outil de collaboration particulier et n'utilisez pas l'historique de conversation comme autorité architecturale.

Phase 1 — Positionnement et portée

Enregistrez :

• ce qu'est le système et qui construit dessus ;
• le problème causé par le couplage ou la croissance actuelle ;
• la frontière de déploiement de première étape ;
• les non-objectifs et les capacités reportées ;
• les avantages bornés et la ligne de base de comparaison pour chaque affirmation.

En même temps, établissez un budget de complexité. Chargez references/document-and-complexity-gates.md pour le budget, les règles de propriété des documents et les conditions d'arrêt. Préférez les affirmations bornées à des mots comme « plus modulaire » ou « plus évolutif ».

Portes de décision utilisateur

N'inférez pas l'intention du produit à partir du code ou des diagrammes. Lorsque les preuves du dépôt ne peuvent pas répondre à une question matérielle concernant la portée, la propriété, le déploiement, la compatibilité, la sécurité, les critères de succès ou l'ordre de migration, faites une pause et demandez à l'utilisateur. Regroupez les choix connexes, montrez les faits observés et les compromis, et recommandez une valeur par défaut prudente lorsque cela est justifié.

Utilisez references/user-decision-gates.md pour les questions spécifiques à l'étape et les emplacements d'enregistrement durables. Si l'utilisateur délègue explicitement un choix matériel, sélectionnez l'option réversible recommandée ou la mieux étayée, enregistrez la délégation et les hypothèses, et continuez. Rendez explicites les hypothèses réversibles non matérielles au lieu de bloquer la progression.

Phase 2 — Architecture cible de niveau 1

Définissez les principaux sous-systèmes ou plans de coordination, les autorités de données/état et les rédacteurs uniques, la propriété de l'identité, la direction des dépendances, le point d'entrée de l'application, la frontière de processus/déploiement et les formes de communication contrôlées.

L1 est requis et explicite pour la cible dans la portée avant la direction de mise en œuvre. Il n'est pas nécessaire de décrire chaque module futur, mais il ne peut pas laisser la propriété, la direction des dépendances ou la portée du déploiement ambiguës. Nommez les questions L1 non résolues avec un propriétaire et une porte de décision.

Chargez references/architecture-contracts.md pour les règles du diagramme L1 et les schémas L2/L3/interface utilisés dans les phases ultérieures.

Phase 3 — Cartographie actuel-vers-cible

Pour chaque point chaud actuel, classez la première action comme conserver, exposer, adapter, splitter, consolider, déprécier ou supprimer. Enregistrez le propriétaire actuel, le propriétaire cible, le chemin de communication/persistance préservé et la porte de suppression. Gardez l'horizon de livraison comme propriétaire canonique des reports détaillés.

Ne créez pas un document simplement parce qu'un sujet est intéressant. Trouvez d'abord le propriétaire canonique ; créez un nouveau document uniquement lorsque la propriété, le statut, le public ou le cycle de vie est matériellement différent.

Phase 4 — Contrats de module de niveau 2

Créez un contrat L2 par module stable ou frontière inter-modules. Couvrez la responsabilité et la non-responsabilité, les composants actuels, les services fournis/requis, l'autorité d'écriture, les appels/visibilité des données autorisés, le cycle de vie/échec, la compatibilité et les décisions reportées à la mise en œuvre.

L2 peut rester incomplet dans le premier package. Marquez les affirmations significatives comme établies, conditionnelles ou ouvertes. Chaque choix ouvert nécessite une expérience bornée, un seuil de preuve ou une porte de mise en œuvre qui peut le résoudre ; n'inventez pas de précision pour l'apparence.

Utilisez les règles L2 et de forme d'interaction dans references/architecture-contracts.md. Utilisez la navigation et les vérifications de propriétaire canonique dans references/document-and-complexity-gates.md lorsque le package contient plusieurs documents.

Phase 5 — MVP et contrat local à la tâche

Choisissez la plus petite boucle fermée réelle qui exerce la frontière prévue. Une tranche de lecture/clôture de cycle de vie peut précéder une tranche de première frontière d'écriture. Conservez les étiquettes MVP locales uniquement lorsqu'elles sont associées à un nom descriptif, et indiquez exactement ce que la tranche prouve et ne prouve pas.

Avant de coder une tâche d'implémentation bornée, gelez uniquement le contrat L3 consommé par cette tâche. Il reste un candidat jusqu'à ce que la tâche d'implémentation l'adopte ou enregistre des révisions. Ne créez pas de documents L3 pour des modules non sélectionnés. Utilisez la liste de contrôle L3 et d'interface dans references/architecture-contracts.md.

Phase 6 — Révision antagoniste et steelman bidirectionnel

Effectuez une passe antagoniste qui tente de briser les affirmations de propriété, de reprise, de compatibilité, de migration et de preuve, suivie d'un steelman qui énonce la valeur la plus forte et les frontières délibérément conservatrices. Préférez un relecteur indépendant qui n'a pas écrit le package ; sinon, utilisez un contexte frais et divulguez la limitation.

Utilisez references/adversarial-review.md pour le calendrier de révision, les questions et le registre de réconciliation unique. Consommez chaque constatation immédiatement. Une constatation bloquante maintient la porte fermée jusqu'à ce que le risque soit résolu ou explicitement déclassé/accepté comme une exception par l'utilisateur ou un relecteur indépendant ; le rejeter ou le reporter seul n'ouvre pas la porte.

Phase 7 — Migration, vérification et promotion

Définissez une migration par étapes avec des couches de compatibilité, des conditions d'abandon, des portes de suppression, des frontières de restauration/redémarrage, des dispositifs de test existants/cibles et des preuves équivalentes. Ne promouvez le texte cible dans l'architecture actuelle qu'après la fusion de la mise en œuvre, des preuves de compatibilité et des mises à jour de l'autorité du dépôt.

À la fin de chaque incrément, choisissez un résultat : continuer, exécuter une expérience nommée, réviser la cible/le contrat, ou arrêter et préserver le chemin actuel. Le prochain incrément commence uniquement lorsque son déclencheur et sa preuve de promotion sont satisfaits. Chargez references/migration-and-promotion.md pour les preuves détaillées, les expériences et les règles ADR.

Phase 8 — Passation et publication

Avant la publication :

• validez les métadonnées, les liens, les catalogues et les vérifications de conformité/régression pertinentes ;
• inspectez la différence complète pour les fichiers non liés ou les affirmations d'implémentation non supportées ;
• mettez à jour l'enregistrement de changement/passation existant du projet ;
• rendez l'enregistrement de l'incrément découvrable à partir d'une entrée d'orientation ou de catalogue ;
• indiquez la tâche exacte suivante et son propriétaire.

Ne créez pas de PR ou poussez une branche à moins que l'utilisateur n'autorise cette mutation externe. Lorsqu'elle est autorisée, décrivez le package comme conception/documentation cible à moins que le comportement d'exécution n'ait réellement changé.

Préoccupations optionnelles

Les plugins, la coexistence de versions, l'isolation de processus, le remplacement à chaud et le déchargement dynamique ne sont pas des exigences d'architecture par défaut. Chargez references/optional-concerns.md uniquement lorsque la conception demandée active réellement l'une de ces préoccupations.

Routage des modules

Besoin	Charger
Sélectionner le plus petit ensemble d'artefacts et l'horizon de livraison	deliverable-matrix.md
Demander ou enregistrer une décision utilisateur matérielle	user-decision-gates.md
Définir L1/L2/L3 ou une interface orientée implémentation	architecture-contracts.md
Contrôler la croissance des documents, la complexité ou la sur-conception	document-and-complexity-gates.md
Exécuter une révision antagoniste et un steelman	adversarial-review.md
Planifier la migration, les expériences, les ADR ou la promotion	migration-and-promotion.md
Concevoir des plugins, l'isolation ou la coexistence de versions	optional-concerns.md

Ne chargez pas chaque module par défaut. La phase active et le livrable demandé déterminent les références nécessaires.

À ne pas faire

• Ne réécrivez pas tout le codebase avant d'avoir prouvé une tranche réelle.
• Ne transformez pas chaque fichier/classe en plugin.
• Ne créez pas de propriétaires d'état, planificateurs, magasins, bus ou autorités de cycle de vie en double sans une décision cible explicite et un modèle d'échec.
• Ne cachez pas les responsabilités mixtes derrière un wrapper de passage renommé.
• Ne revendiquez pas le découplage à partir d'un simple nombre de dépendances inférieur.
• N'utilisez pas une démo synthétique comme condition de sortie principale du MVP.
• Ne laissez pas le nettoyage d'extension impliquer l'achèvement ou la destruction du domaine.
• Ne traitez pas les notes de tâche, les scores de benchmark ou la prose générée comme une autorité architecturale actuelle.