Maison

Skill

Révision du code

request-refactor-plan

vinvcn/mattpocock-skills-zh-cn

Créez un plan de refonte détaillé incluant de petites contributions grâce à des entretiens avec les utilisateurs, puis soumettez-le en tant que GitHub issue. Cette méthode convient aux utilisateurs qui souhaitent planifier une refonte, rédiger un RFC de refonte, ou diviser la refonte en étapes incrémentales sécurisées.

...Développer tout

Heure mise à jour 26 août 2026

# documentation # github # code-review # refactoring # Code ReviewGit & Version ControlDocumentation # planning

À propos de request-refactor-plan

request-refactor-plan est une compétence de planification en langue chinoise (traduite) issue de la collection mattpocock-skills-zh-cn (chemin obsolète), qui interroge l’utilisateur afin d’élaborer un plan de refactoring détaillé composé de petits commits, avant de le soumettre sous forme d’issue GitHub. Le problème qu’elle vise est que les refactors importants présentent des risques lorsqu’ils sont réalisés en grandes étapes ; cette compétence impose des étapes incrémentales toujours fonctionnelles, conformément au conseil de Martin Fowler de rendre chaque étape de refactoring aussi petite que possible afin de pouvoir constater en permanence que le programme fonctionne.

La procédure (les étapes sont optionnelles) est la suivante : faire décrire à l’utilisateur le problème et les solutions envisagées ; explorer le dépôt pour vérifier ses affirmations et comprendre l’état actuel ; identifier d’autres options possibles ; interroger en profondeur l’utilisateur au sujet de la mise en œuvre ; définir précisément le périmètre, y compris ce qui sera modifié et ce qui ne le sera pas ; vérifier la couverture des tests dans la zone concernée et s’enquérir des plans de test si celle-ci est insuffisante ; diviser la mise en œuvre en un plan de petits commits, chacun laissant le codebase dans un état fonctionnel ; et enfin créer une issue GitHub à l’aide d’un modèle fourni, comprenant des sections pour l’Énoncé du problème, la Solution, les Commits, le Document de décision, les Décisions relatives aux tests, ce qui est hors périmètre, ainsi que des Notes supplémentaires facultatives. Ce modèle évite délibérément les chemins de fichiers concrets et les extraits de code, car ceux-ci deviennent rapidement obsolètes.

Elle s’adresse aux développeurs et chefs techniques qui planifient des refactors ou rédigent des RFC de refactoring et souhaitent disposer d’un plan rigoureux, basé sur des entretiens, incrémental et sûr, conservé sous forme d’issue durable. Son fonctionnement consiste en l’exploration du dépôt suivie de la création d’une issue — sans opérations destructrices ou sensibles.

FAQ

Quel est le résultat produit par cette compétence ?

Un plan de refactoring détaillé, conservé sous forme d’issue GitHub, utilisant un modèle comprenant l’Énoncé du problème, la Solution, les Commits, le Document de décision, les Décisions relatives aux tests, ce qui est hors périmètre, ainsi que des Notes supplémentaires facultatives.

Comment assure-t-elle la sécurité du refactoring ?

Elle divise le travail en petits commits, chacun laissant le codebase dans un état fonctionnel, en suivant les directives de Martin Fowler visant à rendre chaque étape de refactoring aussi petite que possible.

Le plan fait-il référence à des fichiers ou du code spécifiques ?

Non. Le modèle omet délibérément les chemins de fichiers concrets et les extraits de code, car ils deviennent rapidement obsolètes ; il se concentre plutôt sur les décisions, les modules, les interfaces et le comportement.

Que fait-elle concernant les tests ?

Elle vérifie la couverture des tests dans la zone concernée et, si celle-ci est insuffisante, demande à l’utilisateur des informations sur ses plans de test, avant d’enregistrer les décisions relatives aux tests dans l’issue.