代码重构的最佳实践：让老项目也能跑得更稳

接手一个三年前的项目，打开代码那一刻，心里咯噔一下：函数名叫 doSomething，里面塞了两百行逻辑，还混着三处重复的校验。这种情况太常见了，重构不是锦上添花，而是维持项目生命力的日常操作。

小步快跑，别想着一口吃成胖子

很多人一说重构就想着把整个模块重写，结果改了三天，功能全崩了，测试过不了，最后只能回滚。与其这样，不如一次只做一件事：比如先把一个长函数拆成几个小函数，每个函数只做一件明确的事。改完立刻运行测试，确保没出问题再继续。

就像整理衣柜，你不会一次性把所有衣服扔地上再重新叠，而是先从T恤区开始，叠好再动裤子。代码也一样，每次改动尽量控制在可验证范围内。

提取函数，让代码自己说话

看到一段计算折扣的逻辑嵌在订单处理里，直接把它拎出来：

function calculateDiscount(price, userLevel) {
  if (userLevel === 'vip') {
    return price * 0.8;
  } else if (userLevel === 'premium') {
    return price * 0.9;
  }
  return price;
}

原来那行 price * 0.8 写在一堆 if 里，现在改成调用 calculateDiscount，别人一眼就知道这段在干啥，连注释都省了。

消灭重复代码，别复制粘贴了

项目里搜一圈，经常能发现三四处几乎一模一样的表单校验逻辑。与其到处修bug，不如统一提到一个工具函数里：

function validateEmail(email) {
  const regex = /^[^\s@]+@[^\s@]+\.[^\s@]+$/;
  return regex.test(email);
}

以后邮箱规则变了，改一处就行。这就像家里做饭，调料不用每顿现配，备好一瓶万能酱汁，随取随用。

善用测试，它是你的安全网

没有测试的重构就像高空走钢丝不系保险绳。哪怕只有几个核心流程的单元测试，也能在你改代码时及时报警。比如修改了一个计算总价的方法，测试能立刻告诉你有没有影响到老逻辑。

如果项目原本没测试，可以边重构边补。先给要改的函数写个测试，确认它现在的行为，再动手优化，保证输出不变。

变量命名别图省事

别用 data、temp、obj 这种名字，谁知道它装的是用户信息还是缓存？换成 userInfo、cachedUserData 更清楚。命名清晰的变量，等于给后来人留了路标。

删掉不用的代码，别留“可能还会用”

有些人删代码前总犹豫：“万一哪天又要呢？” 其实版本管理早就记下了，真需要随时能找回来。留在代码里的死逻辑只会增加阅读负担，像衣柜里堆着五年没穿的衣服，占地方还影响挑选。

重构不是炫技，也不是非得用最新语法。它的目标很实在：让下一个人（包括几个月后的你自己）看代码时少骂两句，改功能时心里有底。”}