Cette skill sera invoquée quand l'utilisateur veut créer une demande de refactorisation. Vous devez suivre les étapes ci-dessous. Vous pouvez sauter des étapes si vous ne les jugez pas nécessaires.
-
Demandez à l'utilisateur une description longue et détaillée du problème qu'il veut résoudre et toute idée potentielle de solutions.
-
Explorez le repo pour vérifier ses affirmations et comprendre l'état actuel de la base de code.
-
Demandez s'il a envisagé d'autres options, et présentez-lui d'autres options.
-
Interrogez l'utilisateur sur l'implémentation. Soyez extrêmement détaillé et minutieux.
-
Définissez précisément le périmètre de l'implémentation. Déterminez ce que vous prévoyez de modifier et ce que vous prévoyez de ne pas modifier.
-
Regardez dans la base de code pour vérifier la couverture de tests de cette zone. S'il y a une couverture de tests insuffisante, demandez à l'utilisateur quels sont ses plans pour les tests.
-
Décomposez l'implémentation en un plan de minuscules commits. Rappelez-vous les conseils de Martin Fowler pour « faire chaque étape de refactorisation aussi petite que possible, afin que vous puissiez toujours voir le programme fonctionner ».
-
Créez un GitHub issue avec le plan de refactorisation. Utilisez le modèle suivant pour la description de l'issue :
Problem Statement
Le problème auquel le développeur fait face, du point de vue du développeur.
Solution
La solution au problème, du point de vue du développeur.
Commits
Un plan d'implémentation LONG et détaillé. Écrivez le plan en anglais clair, en décomposant l'implémentation en commits minuscules. Chaque commit doit laisser la base de code dans un état fonctionnel.
Decision Document
Une liste des décisions d'implémentation qui ont été prises. Ceci peut inclure :
- Les modules qui seront construits/modifiés
- Les interfaces de ces modules qui seront modifiées
- Les clarifications techniques du développeur
- Les décisions architecturales
- Les changements de schéma
- Les contrats API
- Les interactions spécifiques
N'INCLUEZ PAS de chemins de fichiers spécifiques ou d'extraits de code. Ils pourraient devenir obsolètes très rapidement.
Testing Decisions
Une liste des décisions de test qui ont été prises. Incluez :
- Une description de ce qui fait un bon test (testez uniquement le comportement externe, pas les détails d'implémentation)
- Quels modules seront testés
- Les références antérieures pour les tests (c'est-à-dire des types de tests similaires dans la base de code)
Out of Scope
Une description des choses qui sont hors du périmètre de cette refactorisation.
Further Notes (optional)
Toute note supplémentaire sur la refactorisation.