技术重构何时做，为什么做要想清楚

代码重构（Refactoring）是指在不改变代码外部行为的前提下，对代码内部结构进行调整，以提高代码的可读性、可维护性和可扩展性。

• 重构的目标是让代码变得更简洁、更优雅、更容易理解和修改

• 重构不难，何时做，以及为什么要做要想清楚，不要为了重构而重构、不为了KPI 夸大事实来重构。

何时进行代码重构

1.交付快慢

1
2
3

当写一个需求发现代码新增量比较大，代码编写比较多

扩展一个功能发现要改动范围比较多，涉及多个文件或者类

• 可能要考虑是否原来的代码没有基建，造成重复增加代码。

• 扩展的功能没有模块化、没有分层、要反复改动多处。

交付缓慢，当代码变得难以理解和维护且错误频出时，可能就是重构的最佳时机

2.使用体验

1
2

当使用产品时卡顿、不流畅，页面加载时间比较长
使用中应用频繁出错、页面出错，内存读写等问题

• 可能需要看下卡顿的原因，性能问题、渲染问题、数据量过大造成请求缓慢等问题，可能来源于代码的效率低下、资源的过度消耗等。

当系统体验已经严重影响用户了，就需要重构提高系统的响应速度和稳定性

3.需求变化

1
2

当需求或者业务发生变化时，代码无法通过相关配置进行快速开发
为满足需求变化，需要改动大的模块进行调整，牵一发而动全身的代码调整代价

• 需要从架构设计、模块耦合、数据隔离等方面来判断造成代码耦合度高，不能快速响应业务和需求变化的原因。

更好地适应新的需求变化，此时进行重构，确保系统的灵活性和可扩展性

4.技术问题

1
2
3

当原有的系统使用框架、组件在开发需求中不能满足新的呈现形式

当老的控件开发速度缓慢、还有相关老技术所暴露的安全隐患类问题

• 需要评估老技术的局限性，并判断新技术的稳定性、快捷性，能从效率和稳定性上改善老系统

如果系统依赖于过时的技术，此时需要重构来升级技术、确保系统安全和可维护性。

5.团队人员变化

1
2

当团队人员发生变化，老的系统、代码无人知晓和熟悉
新人不知道原来逻辑，要看懂别人代码、维护代码成本都会比较高

• 当对系统的代码不熟悉，新的扩展和改动逻辑都会是比较危险的事情，可能里面一些坑因为不知道逻辑，导致系统频繁出错。

此时进行重构可以帮助新成员更快地上手业务、梳理代码逻辑，同时熟悉到系统间关联代码。