TypeScript 代码重构：何时以及如何将混乱变为有序

引言：当代码开始“有异味”时

每位开发者都熟悉这种感觉。你打开三个月前自己写的文件，表情逐渐凝固。内心深处，你听到一个低语：“这不是我写的，这肯定是个新手写的。”但后视镜是无情的：那就是你。代码能运行，测试能通过，但每次添加新功能时，你花费的时间越来越多。熟悉吗？

这时候，就该考虑 TypeScript 代码重构了。不是从头重写一切（那是通往地狱之路），而是进行精准的外科手术式改进，让代码更整洁、更清晰、更安全。在本文中，我们将探讨 何时应该开始重构，如何无痛地进行，以及 为什么 TypeScript 能为你提供这个过程中的超能力。

何时需要进行 TypeScript 代码重构？

有一种误解认为重构是 Sprint 中的独立任务。实际上，最好的重构是一个持续的过程。但有一些明确的信号在大声呼喊：“停下！这里需要整理！”

三次法则（再加两次）

如果你复制了同一段代码三次——将其提取到函数或类中。如果你看到同事复制了你的代码——那就是第四次。TypeScript 及其严格的类型化使这条规则尤为重要：类型重复会导致数据不同步。

TypeScript 中“脏代码”的症状

• Any 混乱： 如果你的项目中 any 的出现频率比 string 还高——这是一个危险信号。TypeScript 失去了意义。
• 怪兽函数： 一个超过 200 行的函数，什么都能做：验证、解析、发送请求和绘制界面。
• “魔法”数字和字符串： if (status === 3) —— 3 是什么？没人知道，除了已经离职的作者。
• 违反 DRY 原则： 相同的接口分散在 10 个文件中。
• 测试比代码更可怕： 如果为了测试一个函数需要启动服务器、数据库和 Docker——你走错路了。

记住主要规则：当添加新功能花费的时间比从头编写它还要多时，就需要进行 TypeScript 代码重构。这是关键时刻。

基本原则：如何不破坏生产环境

在开始重构之前，记住支撑安全重构的三大支柱：

1. 测试是你的保险。 没有测试覆盖的重构就是俄罗斯轮盘赌。开始前至少编写基本的单元测试。
2. 小步前进。 不要试图在一夜之间重构整个项目。一个模块一次提交。
3. TypeScript 编译器是你的朋友。 使用严格的 tsconfig.json 配置：strict: true 是你的谎言探测器。

实用重构技巧及 TypeScript 示例

让我们进入最有趣的部分——代码。我们将讨论三种真实场景，并展示如何改进它们。

1. 摆脱 any：泛型的力量

糟糕的示例。函数接受任何内容并返回任何内容。这不是 TypeScript，这是戴着面具的 JavaScript。

// 糟糕：any 破坏了类型化function getFirstElement(arr: any[]): any {  if (arr.length === 0) {    throw new Error('Array is empty');  }  return arr[0];}

const num = getFirstElement([1, 2, 3]); // num: anyconsole.log(num.toUpperCase()); // 运行时错误，但编译器保持沉默

好的示例。使用泛型。代码变得更安全，IDE 会提示类型。

// 好：泛型拯救function getFirstElement<T>(arr: T[]): T {  if (arr.length === 0) {    throw new Error('Array is em