您现在的位置是：网站首页 > 拒绝重构（“能跑就行，别动它”）文章详情
拒绝重构（“能跑就行，别动它”）
陈川
【
前端综合
】
41963人已围观
4804字
代码能跑就行？重构的代价与风险
"能跑就行，别动它"——这句话在前端开发中经常听到。项目上线后，代码往往被束之高阁，即使存在明显的设计缺陷或性能问题，也很少有人愿意去触碰。这种态度看似务实，实则隐藏着巨大的技术债务。
为什么开发者拒绝重构
- 时间压力：产品经理不断催促新功能开发，重构被视为"不产生价值"的工作
- 风险恐惧：修改现有代码可能引入新bug，影响线上业务
- 测试不足：缺乏完善的测试覆盖，无法保证重构后的行为一致性
- 认知偏差："没坏就别修"的保守心态普遍存在
// 典型的"能跑就行"代码示例
function processData(data) {
// 500行的巨型函数
// 混杂着业务逻辑、DOM操作和API调用
// 没有任何注释和文档
if (data && data.length > 0 || data === 0) {
// 模糊的条件判断
let temp = [];
for (let i=0; i<data.length; i++) {
// 直接操作DOM
document.getElementById('result').innerHTML += `<div>${data[i]}</div>`;
// 业务逻辑与UI更新耦合
if (data[i].status === 1 || data[i].status === 3) {
temp.push(data[i].id);
}
}
// 异步操作嵌套
fetch('/api/update', {
method: 'POST',
body: JSON.stringify({ids: temp})
}).then(res => {
if (res.ok) {
location.reload(); // 简单粗暴的页面刷新
}
});
}
}
技术债务的累积效应
不重构的代码会像滚雪球一样积累问题：
- 维护成本指数增长：每次添加新功能都需要在糟糕的代码基础上打补丁
- 性能瓶颈：低效的实现逐渐成为系统瓶颈
- 团队知识断层：原始开发者离职后，代码成为"黑盒"
- 创新阻碍：糟糕的架构难以支持新需求
// 随时间演变的组件代码
class OldComponent extends React.Component {
// 混合了多个版本React的生命周期方法
componentWillMount() {
// 已废弃的方法
}
UNSAFE_componentWillReceiveProps() {
// 不安全的更新逻辑
}
componentDidMount() {
// 直接操作DOM
// 使用jQuery插件
// 全局事件监听未清理
}
render() {
// 内联样式
// 行内事件处理
// 没有 PropTypes 检查
return <div onClick={() => {}} style={{color: 'red'}}>...</div>;
}
}
重构的合理时机
虽然不鼓励盲目重构，但以下情况值得考虑：
- 修复bug时：在解决问题同时改善相关代码结构
- 添加新功能前：先清理将要修改的代码区域
- 性能优化时：重写低效算法或实现
- 技术栈升级：如从AngularJS迁移到Vue/React
// 渐进式重构示例：将JS文件转为TypeScript
// 第一步：添加基本类型
interface User {
id: number;
name: string;
status: 1 | 2 | 3;
}
// 第二步：拆分巨型函数
function filterActiveUsers(users: User[]): User[] {
return users.filter(user => user.status === 1);
}
// 第三步：分离UI与逻辑
function renderUsers(users: User[], container: HTMLElement) {
container.innerHTML = users.map(user =>
`<div class="user">${user.name}</div>`
).join('');
}
安全重构的策略
- 版本控制：确保每个重构步骤都可单独提交和回滚
- 测试覆盖：先补充单元测试，再开始修改
- 小步前进：每次只重构一小部分，立即验证
- 工具辅助：使用ESLint、TypeScript等工具捕获潜在问题
// 使用Jest测试保护重构
describe('filterActiveUsers', () => {
test('should return only active users', () => {
const users = [
{id: 1, name: 'Alice', status: 1},
{id: 2, name: 'Bob', status: 2}
];
expect(filterActiveUsers(users)).toEqual([
{id: 1, name: 'Alice', status: 1}
]);
});
});
重构的实际收益
经过精心规划的重构可以带来：
- 开发效率提升：清晰的代码结构减少认知负荷
- bug率下降：强类型和良好设计减少意外错误
- 性能改善：消除不必要的计算和渲染
- 团队协作增强：一致的代码风格和模式
// 重构后的React组件
const UserList = ({ users }) => {
const activeUsers = useMemo(() =>
users.filter(user => user.status === 1),
[users]
);
return (
<ul className="user-list">
{activeUsers.map(user => (
<UserItem key={user.id} user={user} />
))}
</ul>
);
};
UserList.propTypes = {
users: PropTypes.arrayOf(
PropTypes.shape({
id: PropTypes.number,
name: PropTypes.string,
status: PropTypes.oneOf([1, 2, 3])
})
).isRequired
};
管理层沟通技巧
说服业务方支持重构需要：
- 量化影响：用性能指标、bug统计等数据说话
- 关联业务目标：说明重构如何支持未来需求
- 制定计划：明确时间投入和预期收益
- 展示成果：用前后对比证明价值
| 指标 | 重构前 | 重构后 | 改善 |
|--------------|--------|--------|------|
| 加载时间 | 2.4s | 1.1s | 54%↓ |
| Bug数量/月 | 15 | 4 | 73%↓ |
| 开发速度 | 3天/功能| 1.5天/功能| 50%↑ |
长期维护的代码特征
可持续维护的代码通常具有：
- 单一职责：每个模块/函数只做一件事
- 明确接口：清晰的输入输出定义
- 适当抽象：平衡复用性与灵活性
- 完整文档：注释、类型定义和示例
// 良好维护的代码示例
interface PaginationParams {
page: number;
pageSize: number;
total: number;
}
/**
* 分页钩子
* @param initialParams 初始分页参数
* @returns 分页状态和控制方法
*/
function usePagination(initialParams: PaginationParams) {
const [params, setParams] = useState(initialParams);
const nextPage = useCallback(() => {
setParams(prev => ({
...prev,
page: Math.min(prev.page + 1, maxPage)
}));
}, [params.pageSize, params.total]);
return { params, nextPage /* ... */ };
}
自动化工具的支持
现代前端工具链大大降低了重构成本：
- 代码格式化：Prettier统一代码风格
- 静态检查：ESLint捕获潜在问题
- 类型安全：TypeScript防止类型错误
- 重构助手：IDE自动重命名、提取函数等
// .eslintrc.json 配置示例
{
"rules": {
"complexity": ["warn", 5], // 圈复杂度警告
"max-lines-per-function": ["warn", 30],
"no-mixed-operators": "error",
"react/prop-types": "error"
}
}
团队文化的影响
健康的工程文化应该：
- 鼓励改进：将重构视为正常开发环节
- 分享知识：定期进行代码审查和讨论
- 平衡节奏：在迭代中预留技术优化时间
- 量化质量：跟踪技术债务指标
技术债务看板示例：
- [ ] 重构用户模块的验证逻辑
- 预估时间：2人日
- 预期收益：减少30%的相关bug
- [ ] 升级Webpack配置
- 预估时间：1人日
- 预期收益：构建速度提升20%
