代码重构实战经验：从5个痛苦场景到系统化重构方法
回过头看，—
引言：代码重构的5个痛苦场景
关于这部分，我的实际体会是这样的：你是否经历过这些场景？
场景1：面对遗留代码，想重构但不敢动手，担心引入新Bug，只能继续在”屎山”上堆代码。
场景2：花了1周重构代码，上线后出现新Bug，被老板质疑”重构有什么用”。
实话说，场景3：开始只是重构一个函数，结果越改越大，最后变成重写整个模块。
场景4：重构时没有测试保护，改着改着发现功能坏了，不知道哪里出错。
场景5：花费大量时间重构，但团队和老板看不到价值，质疑为什么不写新功能。
以我的经验来看，代码重构本应是保持代码健康的手段，但在实际执行中常常充满风险和质疑。基于多年实战经验，提供系统化的重构方法，帮助你安全高效地重构代码。
—
第一部分：重构失败的深层原因
为什么重构常常出问题？
1. 缺乏安全感
心理学研究表明，人类对损失的厌恶是对收益的喜好的2倍（损失厌恶理论）。重构本质上是”改变工作正常的代码”，这触发了工程师的安全警报。
说真的，真实案例：某工程师重构了支付模块，上线后出现金额计算错误，导致公司损失5万元。从此整个团队不敢再重构。
2. 缺乏系统化方法
很多重构是”感觉不对就改”，缺乏科学方法：
3. 组织阻力
重构常常面临组织和团队阻力：
常见误区
我在这个点上栽过跟头，误区1：”重构就是重写”
误区2：”重构应该一次性完成”
误区3：”重构不需要测试”
我觉得这里有个关键点：误区4：”重构是技术债，应该还完”
误区5：”重构只改代码不改测试”
—
第二部分：系统化重构方法论
方法1：安全重构的5个步骤
我后来才意识到，基于Martin Fowler的《重构》经典方法，结合实战经验：
步骤1：建立测试保护（必须！）
没有测试的重构是赌博，不是工程。
// 先写测试，再重构
describe('Order.calculateTotal', () => {
it('应该正确计算订单总价', () => {
const order = new Order([
{ price: 100, quantity: 2 },
{ price: 50, quantity: 1 }
]);
expect(order.calculateTotal()).toBe(250);
});
我的感受是，it('应该正确处理折扣', () => {
const order = new Order([
{ price: 100, quantity: 2 }
]);
expect(order.calculateTotal(0.1)).toBe(180); // 10%折扣
});
});
测试覆盖标准：
步骤2：识别坏味道
回过头看，常见代码坏味道（来自《重构》）：
| 坏味道 | 例子 | 影响 |
|——–|——|——|
| 重复代码 | 相同逻辑出现3次 | 维护成本x3 |
| 过长函数 | 函数超过50行 | 难以理解 |
| 过大类 | 类超过500行 | 职责不清 |
| 过长参数列表 | 参数超过5个 | 难以使用 |
| 发散式变化 | 一个类因多个原因变化 | 违反SRP |
| 霰弹式修改 | 一个改动修改多个类 | 耦合度高 |
| 依恋情结 | 函数使用其他类的数据 | 职责混乱 |
| 数据泥团 | 总是一起出现的数据 | 应该封装为对象 |
| 基本类型偏执 | 用基本类型表示概念 | 应该使用类 |
| switch惊悚 | 大量switch/if-else | 应该用多态 |
步骤3：选择重构模式
7种最常用的重构模式：
实话说，1. 提取函数（Extract Function）
// Before
function printOwing(invoice) {
let outstanding = 0;
console.log("*");
console.log("* Customer Owes *");
console.log("*");
// 计算未付金额
for (const o of invoice.orders) {
outstanding += o.amount;
}
// 打印详情
console.log(name: ${invoice.customer});
console.log(amount: ${outstanding});
}
以我的经验来看，// After
function printOwing(invoice) {
printBanner();
const outstanding = calculateOutstanding(invoice);
printDetails(invoice, outstanding);
}
说真的，function printBanner() {
console.log("*");
console.log("* Customer Owes *");
console.log("*");
}
function calculateOutstanding(invoice) {
let result = 0;
for (const o of invoice.orders) {
result += o.amount;
}
return result;
}
function printDetails(invoice, outstanding) {
console.log(name: ${invoice.customer});
console.log(amount: ${outstanding});
}
我在这个点上栽过跟头，2. 内联函数（Inline Function）
// Before（函数很简单，没必要存在）
function getRating(driver) {
return driver.numberOfLateDeliveries > 5 ? 2 : 1;
}
// After
function getRating(driver) {
return driver.numberOfLateDeliveries > 5 ? 2 : 1;
}
3. 提取变量（Extract Variable）
// Before（难以理解）
function price(order) {
return order.quantity * order.itemPrice -
Math.max(0, order.quantity - 500) order.itemPrice 0.05 +
Math.min(order.quantity order.itemPrice 0.1, 100);
}
我觉得这里有个关键点：// After
function price(order) {
const basePrice = order.quantity * order.itemPrice;
const quantityDiscount =
Math.max(0, order.quantity - 500) order.itemPrice 0.05;
const shipping =
Math.min(basePrice * 0.1, 100);
return basePrice - quantityDiscount + shipping;
}
4. 用查询替换临时变量（Replace Temp with Query）
// Before
function calculateTotal(order) {
const basePrice = order.quantity * order.itemPrice;
if (basePrice > 1000) {
return basePrice * 0.9; // 10%折扣
}
return basePrice;
}
我后来才意识到，// After
function calculateTotal(order) {
const basePrice = this.getBasePrice(order);
if (basePrice > 1000) {
return basePrice * 0.9;
}
return basePrice;
}
function getBasePrice(order) {
return order.quantity * order.itemPrice;
}
5. 用类替换类型码（Replace Type Code with Class）
// Before（使用魔法数字）
function createEmployee(type, salary) {
if (type === 0) { // 工程师
return { type: 0, salary };
} else if (type === 1) { // 经理
return { type: 1, salary, bonus: salary * 0.2 };
}
}
我的感受是，// After（使用类）
class EmployeeType {
static ENGINEER = new EmployeeType(0);
static MANAGER = new EmployeeType(1);
constructor(code) {
this.code = code;
}
}
function createEmployee(type, salary) {
if (type === EmployeeType.ENGINEER) {
return { type, salary };
} else if (type === EmployeeType.MANAGER) {
return { type, salary, bonus: salary * 0.2 };
}
}
回过头看，6. 用策略模式替换条件表达式（Replace Conditional with Strategy）
// Before（大量if-else）
function calculatePay(employee) {
if (employee.type === 'ENGINEER') {
return employee.salary;
} else if (employee.type === 'SALESMAN') {
return employee.salary + employee.bonus;
} else if (employee.type === 'MANAGER') {
return employee.salary * 1.5;
}
}
// After（策略模式）
class PayStrategy {
calculate(employee) {
throw new Error('Must implement');
}
}
class EngineerPayStrategy extends PayStrategy {
calculate(employee) {
return employee.salary;
}
}
实话说，class SalesmanPayStrategy extends PayStrategy {
calculate(employee) {
return employee.salary + employee.bonus;
}
}
class ManagerPayStrategy extends PayStrategy {
calculate(employee) {
return employee.salary * 1.5;
}
}
function calculatePay(employee) {
const strategy = payStrategies[employee.type];
return strategy.calculate(employee);
}
以我的经验来看，const payStrategies = {
'ENGINEER': new EngineerPayStrategy(),
'SALESMAN': new SalesmanPayStrategy(),
'MANAGER': new ManagerPayStrategy()
};
7. 提取类（Extract Class）
// Before（一个类做太多事）
class Person {
constructor(name, officeAreaCode, officeNumber) {
this.name = name;
this.officeAreaCode = officeAreaCode;
this.officeNumber = officeNumber;
}
get officeAreaCode() {
return this._officeAreaCode;
}
说真的，get officeNumber() {
return this._officeNumber;
}
getTelephoneNumber() {
return (${this.officeAreaCode}) ${this.officeNumber};
}
}
// After（拆分职责）
class Person {
constructor(name, officeAreaCode, officeNumber) {
this.name = name;
this.officeTelephone = new Telephone(
officeAreaCode,
officeNumber
);
}
我在这个点上栽过跟头，getTelephoneNumber() {
return this.officeTelephone.toString();
}
}
class Telephone {
constructor(areaCode, number) {
this.areaCode = areaCode;
this.number = number;
}
toString() {
return (${this.areaCode}) ${this.number};
}
}
步骤4：小步前进（微重构）
我觉得这里有个关键点：关键原则：每次改动不超过10分钟，随时可以回滚
重构流程
写测试（5分钟）
修改1个地方（5分钟）
运行测试（1分钟）
如果通过，提交；如果失败，回滚
重复步骤2-4
真实案例：某团队重构支付模块，将原本1个月的大重构拆分为30个微重构，每个微重构：
结果：
步骤5：持续集成
我后来才意识到，重构必须与CI/CD集成：
.github/workflows/refactor.yml
name: Refactor Check
on:
pull_request:
types: [opened, synchronize]
jobs:
test:
runs-on: ubuntu-latest
我的感受是，steps:
- uses: actions/checkout@v2
- name: Setup Node.js
uses: actions/setup-node@v2
with:
node-version: '16'
- name: Install dependencies
run: npm ci
回过头看，- name: Run tests
run: npm test
- name: Check coverage
run: |
COVERAGE=$(npm run test:coverage | grep "All files" | awk '{print $4}' | sed 's/%//')
if (( $(echo "$COVERAGE < 80" | bc -l) )); then
echo "Coverage too low: $COVERAGE%"
exit 1
fi
- name: Lint
run: npm run lint
方法2：重构价值量化
实话说，如何说服老板和产品经理？用数据说话。
// 重构前后对比指标
const metrics = {
before: {
testCoverage: '45%', // 测试覆盖率
buildTime: '5分钟', // 构建时间
bugCount: 23, // 每月Bug数
newFeatureTime: '5天', // 新功能开发时间
onCallIncidents: 15 // 每月值班故障数
},
after: {
testCoverage: '85%',
buildTime: '2分钟',
bugCount: 8,
newFeatureTime: '2天',
onCallIncidents: 3
}
};
// ROI计算
const roi = {
bugReduction: (23 - 8) / 23 * 100, // 65%↓
speedImprovement: (5 - 2) / 5 * 100, // 60%↑
incidentReduction: (15 - 3) / 15 * 100 // 80%↓
};
真实案例：一个创业团队重构用户中心模块：
以我的经验来看，投入：
收益（6个月）：
ROI：(6万 – 4万) / 4万 = 50%
方法3：重构优先级矩阵
说真的，如何决定先重构什么？使用重要性-紧急性矩阵。
重构优先级矩阵
P0（立即重构）
严重性能问题（影响用户体验）
安全漏洞（SQL注入、XSS等）
阻塞新功能开发
P1（本周重构）
高频使用的模块
高复杂度代码（圈复杂度>15）
测试覆盖率<50%的核心模块
P2（本月重构）
中频使用的模块
中等复杂度代码
代码重复率高
P3（有空再做）
低频使用的模块
简单代码但可读性差
测试覆盖率>80%的代码
—
第三部分：实战案例
案例1：重构N+1查询（性能优化）
问题：订单列表加载慢（3-5秒）
我在这个点上栽过跟头，Before：
// API控制器
app.get('/api/orders', async (req, res) => {
const orders = await Order.findAll(); // 1次查询
const result = orders.map(order => ({
...order.toJSON(),
customer: await Customer.findByPk(order.customerId), // N次查询
items: await OrderItem.findAll({ // N次查询
where: { orderId: order.id }
})
})); // 总共 2N+1 次查询！
res.json(result);
});
我觉得这里有个关键点：性能分析：
重构步骤：
步骤1：写测试
describe('GET /api/orders', () => {
it('应该在1秒内返回订单列表', async () => {
const start = Date.now();
const res = await request(app).get('/api/orders');
const duration = Date.now() - start;
我后来才意识到，expect(res.status).toBe(200);
expect(duration).toBeLessThan(1000);
expect(res.body).toHaveLength(100);
});
});
步骤2：使用Eager Loading
app.get('/api/orders', async (req, res) => {
const orders = await Order.findAll({
include: [
{ model: Customer, as: 'customer' },
{ model: OrderItem, as: 'items' }
]
}); // 仅3次查询
res.json(orders);
});
我的感受是，测试：
npm test
✓ 应该在1秒内返回订单列表 (156ms)
步骤3：提交代码
git add .
git commit -m "refactor: fix N+1 query in orders API"
git push
效果：
案例2：重构复杂条件逻辑（可读性提升）
回过头看，问题：折扣计算逻辑难以理解
Before：
function calculateDiscount(customer, order) {
let discount = 0;
if (customer.membership === 'GOLD') {
if (order.total > 1000) {
discount = 0.15;
} else if (order.total > 500) {
discount = 0.1;
} else {
discount = 0.05;
}
} else if (customer.membership === 'SILVER') {
if (order.total > 1000) {
discount = 0.1;
} else if (order.total > 500) {
discount = 0.05;
}
} else {
if (order.total > 1000) {
discount = 0.05;
}
}
实话说，if (order.hasCoupon) {
discount += 0.1;
}
if (customer.years > 5) {
discount += 0.05;
}
return discount;
}
以我的经验来看，重构步骤：
步骤1：写测试
describe('calculateDiscount', () => {
it('GOLD会员>1000元有优惠券', () => {
const customer = { membership: 'GOLD', years: 3 };
const order = { total: 1200, hasCoupon: true };
expect(calculateDiscount(customer, order)).toBe(0.25);
});
// ... 更多测试用例
});
说真的，步骤2：提取条件函数
function calculateDiscount(customer, order) {
let discount = 0;
discount += getMembershipDiscount(customer.membership, order.total);
discount += getDiscountForCoupon(order.hasCoupon);
discount += getLoyaltyDiscount(customer.years);
return Math.min(discount, 0.5); // 最高50%折扣
}
我在这个点上栽过跟头，function getMembershipDiscount(membership, total) {
const membershipRules = {
'GOLD': [
{ threshold: 1000, discount: 0.15 },
{ threshold: 500, discount: 0.10 },
{ threshold: 0, discount: 0.05 }
],
'SILVER': [
{ threshold: 1000, discount: 0.10 },
{ threshold: 500, discount: 0.05 },
{ threshold: 0, discount: 0 }
],
'NORMAL': [
{ threshold: 1000, discount: 0.05 },
{ threshold: 0, discount: 0 }
]
};
const rules = membershipRules[membership] || membershipRules['NORMAL'];
for (const rule of rules) {
if (total >= rule.threshold) {
return rule.discount;
}
}
return 0;
}
function getDiscountForCoupon(hasCoupon) {
return hasCoupon ? 0.1 : 0;
}
我觉得这里有个关键点：function getLoyaltyDiscount(years) {
return years > 5 ? 0.05 : 0;
}
步骤3：测试
npm test
✓ 所有测试通过
效果：
membershipRules对象案例3：重构重复代码（DRY原则）
我后来才意识到，问题：验证逻辑在多处重复
Before：
// 用户注册
app.post('/api/users/register', (req, res) => {
const { email, password, name } = req.body;
// 验证
if (!email || !email.includes('@')) {
return res.status(400).json({ error: 'Invalid email' });
}
if (!password || password.length < 8) {
return res.status(400).json({ error: 'Invalid password' });
}
if (!name || name.length < 2) {
return res.status(400).json({ error: 'Invalid name' });
}
我的感受是，// 创建用户...
});
// 用户登录
app.post('/api/users/login', (req, res) => {
const { email, password } = req.body;
// 验证（重复！）
if (!email || !email.includes('@')) {
return res.status(400).json({ error: 'Invalid email' });
}
if (!password || password.length < 8) {
return res.status(400).json({ error: 'Invalid password' });
}
回过头看，// 登录逻辑...
});
// 更新用户信息
app.put('/api/users/:id', (req, res) => {
const { email, name } = req.body;
// 验证（又重复！）
if (!email || !email.includes('@')) {
return res.status(400).json({ error: 'Invalid email' });
}
if (!name || name.length < 2) {
return res.status(400).json({ error: 'Invalid name' });
}
实话说，// 更新逻辑...
});
重构步骤：
步骤1：提取验证中间件
// validators/userValidator.js
const { body, validationResult } = require('express-validator');
以我的经验来看，const registerValidation = [
body('email')
.isEmail()
.withMessage('Invalid email'),
body('password')
.isLength({ min: 8 })
.withMessage('Password must be at least 8 characters'),
body('name')
.isLength({ min: 2 })
.withMessage('Name must be at least 2 characters'),
(req, res, next) => {
const errors = validationResult(req);
if (!errors.isEmpty()) {
return res.status(400).json({ errors: errors.array() });
}
next();
}
];
const loginValidation = [
body('email')
.isEmail()
.withMessage('Invalid email'),
body('password')
.isLength({ min: 8 })
.withMessage('Password must be at least 8 characters'),
说真的，(req, res, next) => {
const errors = validationResult(req);
if (!errors.isEmpty()) {
return res.status(400).json({ errors: errors.array() });
}
next();
}
];
module.exports = {
registerValidation,
loginValidation
};
步骤2：使用中间件
const { registerValidation, loginValidation } = require('./validators/userValidator');
我在这个点上栽过跟头，// 用户注册
app.post('/api/users/register',
registerValidation,
(req, res) => {
// 创建用户...
}
);
// 用户登录
app.post('/api/users/login',
loginValidation,
(req, res) => {
// 登录逻辑...
}
);
效果：
我觉得这里有个关键点：—
第四部分：工具推荐
重构辅助工具
VS Code：
F2IntelliJ IDEA：
Refactor → Extract MethodRefactor → Inline安装
npm install --save-dev jest
配置 package.json
{
"scripts": {
"test": "jest",
"test:watch": "jest --watch",
"test:coverage": "jest --coverage"
}
}
运行
npm test
npm run test:watch # 监视模式
npm run test:coverage # 覆盖率报告
安装
npm install --save-dev eslint
配置 .eslintrc.json
{
"extends": ["eslint:recommended"],
"rules": {
"no-unused-vars": "error",
"max-len": ["error", { "code": 100 }],
"complexity": ["error", 10]
}
}
运行
eslint src/
安装
npm install --save-dev prettier
配置 .prettierrc
{
"semi": true,
"singleQuote": true,
"tabWidth": 2
}
格式化
prettier --write src/
启动
docker run -d --name sonarqube -p 9000:9000 sonarqube:lts
扫描
sonar-scanner
-Dsonar.projectKey=my-project
-Dsonar.sources=src
-Dsonar.host.url=http://localhost:9000
CI/CD集成工具
.github/workflows/refactor.yml
name: Refactor Check
我后来才意识到，on: [pull_request]
jobs:
quality:
runs-on: ubuntu-latest
steps:
- uses: actions/checkout@v2
我的感受是，- name: Setup Node.js
uses: actions/setup-node@v2
with:
node-version: '16'
- name: Install dependencies
run: npm ci
- name: Lint
run: npm run lint
回过头看，- name: Test
run: npm test
- name: Coverage
run: npm run test:coverage
// Dangerfile.js
import { warn, fail } from 'danger'
// 警告大改动
const prSize = danger.github.pr.additions + danger.github.pr.deletions
if (prSize > 500) {
warn(PR过大（${prSize}行），建议拆分)
}
实话说，// 检查测试覆盖率
const coverage = await danger.github.utils.coverage()
if (coverage < 80) {
fail(测试覆盖率不足（${coverage}%），需要>80%)
}
—
第五部分：避坑指南
陷阱1：没有测试就重构
问题：直接修改代码，靠人工验证
以我的经验来看，后果：
解决方案：
重构前必须写测试
先写测试（测试驱动重构）
确保所有测试通过
小步重构
每步都运行测试
测试失败立即回滚
陷阱2：重构范围过大
问题：一次重构整个模块
说真的，后果：
解决方案：
重构拆分原则
单次重构改动<100行
单次重构时间<30分钟
大重构拆分为10+个微重构
每个微重构独立测试和提交
陷阱3：忽视性能
问题：重构后性能下降
我在这个点上栽过跟头，例子：
// Before（性能好）
function getUsers(ids) {
return User.findAll({
where: { id: ids }
});
}
// After（性能差，N+1查询）
async function getUsers(ids) {
const users = [];
for (const id of ids) {
const user = await User.findByPk(id);
users.push(user);
}
return users;
}
解决方案：
陷阱4：过度抽象
我觉得这里有个关键点：问题：为了”可扩展”而过度设计
例子：
// 过度设计
class OrderProcessorFactory {
static create(type) {
switch (type) {
case 'STANDARD':
return new StandardOrderProcessor();
case 'EXPRESS':
return new ExpressOrderProcessor();
case 'INTERNATIONAL':
return new InternationalOrderProcessor();
// ...
}
}
}
// 实际只需要
class OrderProcessor {
process(order) {
if (order.type === 'EXPRESS') {
// 加急处理
}
// 标准处理
}
}
我后来才意识到，解决方案：
陷阱5：忽视团队协作
问题：单打独斗重构，不与团队沟通
后果：
我的感受是，解决方案：
陷阱6：重构不测试代码
问题：只重构业务代码，不重构测试代码
后果：
回过头看，解决方案：
陷阱7：缺乏回滚计划
问题：重构出问题无法快速恢复
解决方案：
每次重构都是独立的commit
git commit -m "refactor: extract function X"
如果出问题
git revert HEAD
或使用feature flag
if (featureFlags.enableNewOrderProcessing) {
// 新逻辑
} else {
// 旧逻辑
}
实话说，—
第六部分：实施行动清单
立即行动（本周）
短期目标（本月）
中期目标（3个月）
长期目标（6个月）
—
结语：重构是持续的过程，不是一次性活动
说说我自己的经历和看法：记住这些关键原则：
重构的目标是让代码更容易理解和修改，让团队更高效地交付价值。
以我的经验来看，立即行动：
你有重构的经验或问题吗？欢迎在评论区分享！
—
作者简介
结合我自己的项目经验来聊聊：作者：资深软件工程师，擅长代码重构和架构设计。曾在多家公司主导大型重构项目，帮助团队将代码质量提升到新的水平。
说真的，—
相关文章
—
推荐资源
这部分我踩过不少坑，说说心得：书籍：
文章：
我在这个点上栽过跟头，工具：
—
文章元信息：
