🧭 导语

最近有位辅导同学问我：“你平时是怎么做代码重构的？”

重构不是“把旧代码改好看”，而是让系统重新回到可持续演进的状态。 这篇文章，我想从实际项目出发，聊聊前端在做代码重构时，应该怎么思考、怎么落地。

一、什么时候需要重构？

重构的目标从来不是“写得更优雅”，而是让系统重新可维护。

前端常见的触发场景包括：

• 业务快速变化，组件/逻辑耦合严重；
• 技术栈升级（从 Vue2 → Vue3、JS → TS）；
• 性能或体积瓶颈明显；
• 新成员接手代码困难、阅读成本高。

一句话总结：

当“改一个小功能要动几十个文件”时，就是该重构的时候了。

二、重构的核心：不改变行为，改善结构

重构的本质，是在不改变系统行为的前提下，优化内部实现。

所以第一步，是建立安全网。前端最有效的安全网包括：

• ✅ 单元测试（Unit Test）
• ✅ 端到端测试（E2E）
• ✅ 视觉回归测试

例如：

// utils/price.js
export function formatPrice(value) {
  return Number(value).toFixed(2);
}

import { formatPrice } from './price';
test('format price', () => {
  expect(formatPrice(10)).toBe('10.00');
});

确保测试通过后，才能放心地调整结构。

三、前端常见的重构类型

1. 结构重构：模块化、职责拆分

当组件职责混乱时，首要任务是“拆”。

// Before
function OrderCard({ order }) {
const status = getStatus(order.status);
return<div>{status}</div>;
}

// After
function useOrderStatus(order) { ... }
function OrderCard({ order }) {
const status = useOrderStatus(order);
return<OrderStatus text={status} />;
}

好处：逻辑清晰、测试容易、可复用。

2. 技术重构：类型与框架迁移

迁移到 TypeScript 或新框架（Vue3、React Hooks）时，建议采用渐进式方案：

1. allowJs 兼容旧代码；
2. 优先类型化核心模块；
3. 在 CI 中开启 tsc --noEmit；
4. 逐步提升严格程度。

技术重构是“长期投资”，提升稳定性与可维护性。

3. 性能重构：减少无意义渲染

性能型重构关注三件事：渲染次数、包体积、加载策略。

常用方法：

• React memo、useMemo、useCallback
• 懒加载 import()
• Bundle Analyzer 分析依赖

const ExpensiveList = React.memo(({ data }) =>
  data.map(item => <Item key={item.id} {...item} />)
);

量化结果：首屏渲染从 2.8s 降至 1.9s，bundle 缩减 18%。

4. 样式重构：从混乱到体系化

重构样式时目标是隔离、规范、主题化：

• CSS Modules / CSS-in-JS：作用域隔离；
• 设计 Tokens：统一变量；
• TailwindCSS：原子化方案减少命名歧义。

/* Before */
.title { color: #1890ff; }

/* After */
.title { color: var(--primary-color); }

统一变量体系 = 可维护的样式系统。

5. 工具辅助：自动化是效率倍增器

自动化是现代前端重构的标配：

比如使用 jscodeshift：

npx jscodeshift -t renameProp.js src/

可以安全地在数百个文件中统一替换属性。

四、如何验证重构效果？

重构的成功应当“可被度量”：

这些数据能让团队相信重构的价值。

五、让重构成为一种日常习惯

优秀团队不会“等到系统烂掉再重构”，而是：

• 每个 Sprint 留时间偿还技术债；
• 每个 PR 都包含可读性改进；
• 每次 Code Review 都关注架构健康；
• 建立 Lint + Type Check 的持续集成。

成熟的前端团队，不是没有烂代码，而是让烂代码活不过一周。

六、总结

当面试官问你“怎么做代码重构”时， 他们想了解的是：你是否具备系统化的工程思维。

重构不是炫技，而是保持系统长期可控的手段。 它让我们在高速变化的业务中，仍能写出可维护、可扩展、可验证的前端系统。

真正的重构，不是改过去的代码，而是为未来铺路。