代码能跑就别动？GitHub 官方这个 Skill 把重构说清楚了

代码能跑，就别动——这是很多团队的信条。但欠下的技术债，终归要还。问题在于，重构这事太容易好心办坏事：改着改着，功能坏了；或者重构完了，代码是漂亮了，但没人敢动，下次还是一坨浆糊。

GitHub 官方维护的 Refactor Skill，就是来解决这个问题的。它不是让你重写，而是在保留行为的前提下，把代码一点点变干净。属于那种”慢慢来比较快”的典型。

10 种最常见的代码病症，对症下药

Skill 里总结了 10 种最破坏代码可维护性的”smell”，每种都给 Before/After 对比：

• 长方法：200 行的函数拆成职责单一的子函数
• 重复代码：提取公共逻辑，用多态或策略模式消除 if-else 链条
• 过长的参数列表：用接口或 Builder 模式代替七八个散参数
• 嵌套过深：用守卫子句（Guard Clause）做早期返回，告别箭头代码
• 魔法数字/字符串：替换成有名字的常量
• 死代码：直接删，别留恋——Git 历史都记得
• 类型滥用：原始类型（string/number）换成有校验的域类型（Domain Type）

设计模式也是重点

Skill 专门用两节讲策略模式（Strategy）和责任链模式（Chain of Responsibility），结合 TypeScript 类型系统演示如何把一坨条件判断，优雅地转换成可扩展的结构。实际项目中，这两个模式能解决 80% 的条件逻辑膨胀问题。

最后的检查清单也值得收藏：函数是否小于 50 行、是否单一职责、有没有重复代码、类型是否到位——逐项打勾，重构成果量化可见。

怎么装

在 Smithery 页面搜索 github/refactor，或者直接去 GitHub 下载 SKILL.md 文件放到项目目录里。87 次安装，GitHub 官方维护，属于那种装完就舍不得删的类型。

代码质量这事，做了不一定有回报，但不做迟早有代价。与其等着技术债利滚利，不如从今天开始，一小步一小步地把它变好。

GitHub 地址 →

GitHub: https://github.com/github/awesome-copilot/tree/main/skills/refactor