谈谈代码重构

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


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

  • 系统级重构
      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 – 遗留项目开发之最小影响原则
**************************************** 持续更新 *********************************************

  • 7
    点赞
  • 39
    收藏
    觉得还不错? 一键收藏
  • 0
    评论

“相关推荐”对你有帮助么?

  • 非常没帮助
  • 没帮助
  • 一般
  • 有帮助
  • 非常有帮助
提交
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值