skillhub-121-request-refactor-plan
wehub-skill-sync
69 行
2.3 KiB
Markdown
69 行
2.3 KiB
Markdown
---
|
|
name: request-refactor-plan
|
|
description: 通过用户访谈创建详细的、包含小型提交的重构计划，然后将其归档为 GitHub Issue。当用户想要规划重构、创建重构 RFC 或将重构分解为安全的增量步骤时使用。
|
|
---
|
|
|
|
此技能将在用户想要创建重构请求时被调用。你应该按以下步骤操作。如果你认为某些步骤不必要，可以跳过它们。
|
|
|
|
1. 向用户询问他们想要解决的问题的详细长描述，以及任何潜在的解决方案想法。
|
|
|
|
2. 探索代码仓库以验证他们的断言，并理解代码库的当前状态。
|
|
|
|
3. 询问用户是否考虑过其他方案，并向他们展示其他可选方案。
|
|
|
|
4. 就实现细节对用户进行访谈。要做到极其详细和彻底。
|
|
|
|
5. 敲定实现的确切范围。明确你计划更改什么以及计划不更改什么。
|
|
|
|
6. 在代码库中检查该区域是否有测试覆盖。如果测试覆盖不足，询问用户的测试计划。
|
|
|
|
7. 将实现分解为一系列小型提交的计划。记住 Martin Fowler 的建议："让每个重构步骤尽可能小，这样你就能始终看到程序处于可工作状态。"
|
|
|
|
8. 创建一个包含重构计划的 GitHub Issue。使用以下模板作为 Issue 描述：
|
|
|
|
<refactor-plan-template>
|
|
|
|
## 问题陈述
|
|
|
|
从开发者角度描述开发者面临的问题。
|
|
|
|
## 解决方案
|
|
|
|
从开发者角度描述问题的解决方案。
|
|
|
|
## 提交计划
|
|
|
|
一份详细而冗长的实现计划。用通俗易懂的英文编写计划，将实现分解为尽可能小的提交。每次提交后代码库都应处于可工作状态。
|
|
|
|
## 决策文档
|
|
|
|
一份已做出的实现决策列表。可以包括：
|
|
|
|
- 将要构建/修改的模块
|
|
- 这些模块将要修改的接口
|
|
- 来自开发者的技术澄清
|
|
- 架构决策
|
|
- 模式变更
|
|
- API 契约
|
|
- 特定交互
|
|
|
|
不要包含具体的文件路径或代码片段。它们可能会很快过时。
|
|
|
|
## 测试决策
|
|
|
|
一份已做出的测试决策列表。包括：
|
|
|
|
- 什么是好测试的描述（只测试外部行为，不测试实现细节）
|
|
- 哪些模块将被测试
|
|
- 测试的先前参考（即代码库中类似类型的测试）
|
|
|
|
## 范围外
|
|
|
|
对本重构来说不属于范围的描述。
|
|
|
|
## 补充说明（可选）
|
|
|
|
关于重构的任何补充说明。
|
|
|
|
</refactor-plan-template>
|