重构系统：程序员的必备技能指南

欢迎来到啾啾的博客🐱。
记录学习点滴。分享工作思考和实用技巧，偶尔也分享一些杂谈💬。
有很多很多不足的地方，欢迎评论交流，感谢您的阅读和评论😄。

引言

作为程序员，重构系统是我们几乎绕不开的任务。
那么？为什么要重构？什么时候重构、怎么重构？

本篇讲述重构的那些事。

1 为什么要重构

重构（Refactoring） 是指在不改变系统外部行为的前提下，改进代码内部结构的工艺过程。简单说，就是“让代码更好写、更好读、更好维护”，而功能一模一样。

那么什么情况在代码变得不好写、不好读、不好维护呢？
当我们的工程出现了巨型函数、过期注释满天飞、不可读命名、冗余的代码逻辑等，这时候的代码常被称为有坏味道的代码。

这时，我们可以消除重复、简化结构、优化我们的设计，从而消除代码中的坏味道。

我们常见的使用DDD来重构复杂业务逻辑代码就是这样的设计。

2 重构的时机

我们需要在发现代码中的坏味道时进行重构。

红灯预警（立即行动）：

• 函数>100行
• 条件判断>5个嵌套
• 注释解释“为什么”（证明代码不清）
• 新功能添加>30分钟犹豫

黄灯提醒（近期规划）：

• 重复代码>3处
• 测试覆盖<80%
• 代码年龄>6个月未动

3 如何重构

为避免大范围重构导致验证困难，应该采用测试驱动+小步验证的方法。

从函数开始、不从全局开始，并且准备好。

重构流程参考如下：

3.1 常见重构陷阱及避坑

4 重构的长期回报

重构代码会为代码带来长期的回报。今天多花1小时，明天省10小时维护。

5 关于重构的思考

如果是频次低的大规模的重构，这种事情往往很少有公司愿意承担、也很少有团队愿意去做这样的事情，因为对于中小型公司、或者处于快速发展阶段的公司来说，这样做短期是没有任何产出的。

专注于交付项目的外包公司往往没有长期的思考，所以有不少公司出于这个原因将外包经历筛掉。

尽管重构能带来长期回报，解决技术债务，真正的重构还是很少。

所以，要培养团队的“重构思维”，常见如下方式：

• 建立评审机制，做code review
• 宽松的技术氛围，鼓励一步步做好

在AI时代，引入AI评审进行锐评也挺好的。AI+CI/CD流程的代码质量检测。