谈谈代码重构

【代码重构的定义】
  关于代码重构的理解：在不改变软件系统/模块所具备的功能特性的前提下，遵循/利用某种规则，使其内部结构趋于完善。其在软件生命周期中的价值体现主要在于可维护性和可扩展性。

---

【代码重构的时机】
  依据重构所带来的影响范围的大小，我们分别依次从系统级别和函数接口级别进行说明。

• 系统级重构
    1. 系统越来越臃肿，业务调用链路交错复杂，难以进行正常维护；
    2. 新功能添加代价很大，扩展困难；
    3. 系统技术架构无法满足业务发展需求，如性能瓶颈频现，无法快速进行新业务逻辑的添加/修改；
    4.负责人新官上任，需要立flag;
• API级重构
    1. 函数声明设计不合理:
        a. 函数命名不规范，缺少注释，尤其是函数功能、返回值及参数说明；
        b. 输入参数与输出参数无法明确区分;
        c. 参数类型不精确，如整型与浮点型;
        d. 参数个数过多，大于5个;
        e. 参数传递方式不合理，如值传递与引用传递；
    2. 函数实现的的几个问题：
        a. 含义不明确的变量，未使用的变量，未初始化的变量，初始化方式不当；
        b. 代码行过多，如C语言而言单个函数体代码行超过500行，甚至1000行；
        c. 复杂的表达式；
        d. 算法逻辑：未能依据应用场景，合理均衡时间复杂度与空间复杂度；
        e. 过多的外部依赖，导致接口调用的时长增加；
        f. 大量重复代码块；
        g.不合理的使用全局变量，宏定义，内联函数；
        h. 接口功能边界模糊；

---

【代码重构的规则】

• 系统级重构规则

1. 简单：识别系统的复杂度（高可用、高性能、IO密集型、CPU密集型、适用对象），然后尽可能采用合适且简单的架构；
2. 适用：基于自身当前及未来的业务特性和发展趋势进行技术架构选型；
3. 演化：技术架构是动态的，随着业务发展不断变化完善的；
4. 性能优化贯穿于系统设计的始终：可参考博文《系统性能优化策略 – 持续优化更新》

• API级重构规则

1. 合理声明；
2. 职责单一；
3. 里氏替换；
4. 高内聚低耦合；
5. 面向对象编程；面向失败编程；
6. 可维护、可扩展性

---

【重构系统上线的几个注意事项】
      新系统或者新API的上线难免会引入未知的难以提前评估或者测试（单元测试+集成测试）难以覆盖到的错误。为了保证线上问题出现时的秒级回滚，我们一般需要将前一次的成功版本服务作为本次升级服务的降级。
5. 遵从灰度发布原则：旧的API作为默认逻辑，将新的API作为旧的API的降级逻辑，使用策略分流一部分流量到新的API。
6. 一段时间验证后，若新的API没有问题，则将新的API设置为默认逻辑，旧的API保留作为降级逻辑。

---

【示例】
7. 《代码重构示例 1 – 遗留项目开发之最小影响原则》
**************************************** 持续更新 *********************************************