用Cursor重构烂代码的真实案例-平芜编程栈

上周三下午，我接手了一个让我倒吸一口凉气的代码库。同事离职前留下的这个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列出了：

魔法数字（到处出现的0.1、100等）
重复的条件判断逻辑
过长的函数（超过100行的有8个）
混合的抽象层次（业务逻辑直接操作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指出了几个明显可以抽离的逻辑：

价格计算逻辑（第45-90行）
状态判断逻辑（第120-180行）
数据格式化逻辑（第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); }