make-native

轻量级功能会将异常处理叠加到原本没有为此设计的代码上。你的任务是重新设计它，让这项功能成为原生能力。

流程

1. 阅读功能差异： 使用 git diff <base>...HEAD，其中 <base> 是 PR 的目标分支（例如 gh pr view --json baseRefName -q .baseRefName），或指定的提交。列出功能新增的所有内容，包括新分支、标志、常量、文件和测试。
2. 了解原有设计，然后深入理解。 对每个改动区域，都比调用点再深入一到两个层级。阅读类型、调用方和历史记录（git log -p），直到你能说清楚代码为何采用这种结构。你掌握的信息比原作者更多。如果你能访问运行时数据（日志、错误跟踪、分析数据、数据库记录），检查实际发生的路径和情况。只读；切勿提交这些数据。
3. 按照功能从一开始就在原始规范中的方式重新设计。 问问自己：“如果作者第一天就知道这项功能，代码会是什么样？”然后写出那个版本。借此机会简化：泛化类型或联合类型、重命名、重组结构、合并重复项，并删除新结构不再需要的内容。
4. 应用二八法则。 先让常见的 80% 情况做到完美且简单，再尽可能妥善处理剩下的 20%，绝不以牺牲前 80% 为代价。如果某个边缘情况会让主路径变复杂，就单独处理它，否则就明确报错。
5. 按新设计重写测试。 删除那些只是为了证明旧行为在变通方案下仍然有效的测试。更新其余测试，使其验证新行为。现有测试理应有所改动。
6. 检查。 读者不应看出最终代码中的哪部分是最后添加的。对已移除的符号运行 git grep，确认没有残留。运行项目的构建、代码检查和测试。

需要消除的异味

• 重新推导已有值的别名，例如已有 getContentType() 返回名词时，又写 const noun = isVideo ? 'video' : 'image'。
• 在已经按类型分发的代码中，散布 if (newKind) 分支。
• 新建文件或组件，为某个变体镜像已有实现。
• 新增与类型已有编码信息重复的 options 令牌、标志或布尔值。
• 在共享验证或下载路径旁重复实现验证或下载流程。
• 唯一目的只是证明“其他一切都没变”的测试。
• 针对已有系统负责的问题另建一套系统，例如新增成本跟踪器、计数器、日志记录器、重试辅助程序或配置读取器。应将其整合到现有系统中，在现有系统不足时扩展它，并删除重复实现。

规则

• 仅用于功能。Bug 修复应保持最小改动。不要对 Bug 修复提交执行此操作。
• 不要引入新的抽象层。重塑现有抽象层。
• 保留确实不同的行为。<video> 元素与 <img> 确实不同；重复的状态机则不然。
• 单独提交，不与功能提交合并，并遵循仓库的提交规范。采用 Conventional Commits 时，行为不变用 refactor，重塑后行为有变化则用 feat。