上周三下午，我接手了一个让我倒吸一口凉气的代码库。同事离职前留下的这个 JavaScript 文件有 1200 多行，函数长得能滚动三屏，变量名像是用随机字符生成的。产品经理说需要加个简单功能——根据用户类型显示不同的订单状态。我看了两小时，愣是没搞清楚该在哪改。

这就是那种典型的“烂代码”：能跑，但没人敢动。

初探代码沼泽

文件名叫 orderProcessing.js，打开后的第一印象是这样的：

function proc(o) {let a = [];for (let i = 0; i < o.length; i++) {    if (o[i].s === 'pd') {      if (o[i].amt > 100) {        if (o[i].uType === 'vip') {          // ... 还有五层嵌套        }      }    }  }// 后面还有800行类似代码}

变量名全是单字母，逻辑嵌套深得能挖到地心，重复代码随处可见。更糟糕的是，业务逻辑和数据处理、UI 更新全搅在一起。

用 Cursor 理解这团乱麻

我没有直接开始重写，而是先让 Cursor 帮我理解代码在做什么。

技巧一：让 AI 解释代码块我选中了一个 150 行的函数，按下 Cmd+I（Mac）调出 Chat 界面，问：“这个函数到底在做什么？用简单的话解释。”

Cursor 花了点时间分析，然后说：“这个函数似乎在做三件事：1）过滤出待处理订单，2）计算折扣，3）格式化显示数据。但都混在一起了。”

这正是问题所在——一个函数做太多事情。

技巧二：识别代码模式我又问：“找出这个文件中最常见的代码坏味道。”

Cursor 列出了：

1. 魔法数字（到处出现的 0.1、100 等）

2. 重复的条件判断逻辑

3. 过长的函数（超过 100 行的有 8 个）

4. 混合的抽象层次（业务逻辑直接操作 DOM）

有了这个分析，我知道该从哪里下手了。

实战重构：从最臭的代码开始

阶段一：提取魔法数字

原代码中到处都是这样的片段：

if (order.amount > 100) {  discount = order.amount * 0.2;} else if (order.amount > 50) {  discount = order.amount * 0.1;}

我选中这类代码，让 Cursor 重构： “将这些魔法数字提取为有意义的常量”

Cursor 生成：

const DISCOUNT_THRESHOLD_PREMIUM = 100;const DISCOUNT_THRESHOLD_STANDARD = 50;const PREMIUM_DISCOUNT_RATE = 0.2;const STANDARD_DISCOUNT_RATE = 0.1;
if (order.amount > DISCOUNT_THRESHOLD_PREMIUM) {  discount = order.amount * PREMIUM_DISCOUNT_RATE;} else if (order.amount > DISCOUNT_THRESHOLD_STANDARD) {  discount = order.amount * STANDARD_DISCOUNT_RATE;}

阶段二：拆解巨无霸函数

最大的那个函数有 300 行。我决定分步骤重构。

首先，识别可提取的部分我问 Cursor：“这个函数中哪些部分可以独立成单独的函数？”

Cursor 指出了几个明显可以抽离的逻辑：

1. 价格计算逻辑（第 45-90 行）

2. 状态判断逻辑（第 120-180 行）

3. 数据格式化逻辑（第 200-280 行）

然后，让 Cursor 帮我提取我选中价格计算部分（45-90 行），输入： “将这部分提取为一个独立函数，专注于价格计算，考虑所有边界情况”

Cursor 不仅提取了函数，还给了个好名字：

function calculateOrderPrice(order, userType) {  // 清晰的逻辑，包含注释说明  const basePrice = order.amount;  const discount = calculateDiscount(basePrice, userType);  const tax = calculateTax(basePrice - discount, order.state);  return basePrice - discount + tax;}

神奇的是，它还发现了一个原代码中的 bug：某个特定情况下税被计算了两次。

阶段三：处理条件嵌套地狱

原代码中的条件嵌套让人头晕：

if (user.type === 'vip') {  if (order.status === 'pending') {    if (order.amount > 100) {      if (order.paymentMethod === 'credit_card') {        // 实际逻辑      }    }  }}

我让 Cursor 用策略模式重构： “使用策略模式重构这个多层条件判断，让不同用户类型的处理逻辑分离”

结果出乎意料地好：

const userHandlers = {  vip: new VipOrderHandler(),  standard: new StandardOrderHandler(),  guest: new GuestOrderHandler()};
function processOrder(order, user) {  const handler = userHandlers[user.type] || userHandlers.guest;  return handler.handle(order);}

遇到问题：Cursor 不是总对

在重构一个复杂的数据转换函数时，Cursor 给出了一个有问题的建议。它试图合并两个相似的循环，但没注意到它们有细微的副作用差异。

教训：任何时候都要运行测试。我在重构前已经准备了几个关键测试用例：

// 简单的快照测试test('重构前后结果一致', () => {  const originalResult = oldProcessOrders(testData);  const refactoredResult = newProcessOrders(testData);  expect(refactoredResult).toEqual(originalResult);});

当 Cursor 的重构导致测试失败时，我没有直接接受，而是问： “为什么这个重构会导致测试失败？原逻辑中的微妙区别是什么？”

Cursor 重新分析后承认：“抱歉，我忽略了第一个循环会修改原数组，而第二个循环依赖这个修改。”

重构后的成果

经过两天的重构（原本估计要一周），代码有了明显改善：

之前：

• 1 个文件，1200 行

• 函数平均长度：85 行

• 最深嵌套：8 层

• 重复代码块：约 30 处

之后：

• 6 个文件，平均 150 行

• 函数平均长度：22 行

• 最深嵌套：3 层

• 重复代码：基本消除

更重要的是，新加功能变得简单。产品经理要的“根据用户类型显示不同订单状态”功能，现在只需要：

// 以前：需要在多个地方修改条件判断// 现在：import { getStatusDisplay } from './orderStatus';
function displayOrderStatus(order, user) {  return getStatusDisplay(order, user.type);}

学到的重构技巧

1. 先理解，再动手用 Cursor 解释代码比自己摸索快得多。但永远要结合自己的业务理解。

2. 小步前进，频繁测试每次重构不超过一个函数，立即运行测试。Cursor 的“重构并解释”功能很好用。

3. 用好 Cursor 的代码分析像“找出重复模式”、“识别坏味道”这类指令，能帮你发现肉眼忽略的问题。

4. 不要完全依赖 AICursor 有时会过度设计。简单的重复代码提取它做得很好，但涉及复杂设计模式时，需要人工判断是否合适。

5. 命名是重构的关键 Cursor 能建议更好的变量名，但最终命名要符合团队习惯。我经常这样问：“给这个函数起个更清晰的名字，它负责验证订单并计算价格。”

重构烂代码就像整理一个杂乱的仓库。Cursor 不是那个替你干所有活的机器人，而是给你提供了一个好用的手推车、一些收纳箱，还有一位随时能问的仓储专家。

烂代码不会一夜之间变好，但有了合适的工具和方法，至少我们知道从哪里开始清理。而每一次清理，都让系统更健壮一点，也让下一个接手的同事少骂我们两句。