重构 代码重构原则 总结

版权声明:https://blog.csdn.net/qq_26814945 https://blog.csdn.net/qq_26814945/article/details/82628384

重构定义

如果你发现自己需要为程序添加一个特性 而代码结构使你无法很方便地达成目的 那就先重构那个程序 使特性的添加比较容易进行 然后再添加特性

重构之前 首先检查自己是否有一套可靠的测试机制 这些测试必须有自我检验能力

重构技术就是以微小的步伐修改程序 如果你犯下错误 很容易便可发现它

任何一个傻瓜都能写出计算机可以理解的代码 唯有写出人类容易理解的代码 才是优秀的程序员

重构(名词) 对软件内部结构的一种调整 目的是在不改变软件可观察行为的前提下 提供其可理解性 降低其修改成本

重构(动词) 使用一系列重构手法 在不改变软件可观察行为的前提下 调整其结构

重构目的

重构的目的是使软件更容易被理解和修改
与之形成对比的是性能优化 和重构一样 性能优化通常不会改变组件的行为(除了执行速度) 只会改变其内部结构 但是两者出发点不同 性能优化往往使代码较难理解 但为了得到所需的性能你不得不那么做
重构不会改变软件可观察的行为 重构之后软件功能一如以往

为何重构

重构改进软件设计
重构使软件更容易理解
重构帮助找到bug
重构提高编程速度

何时重构

三次法则 事不过三 三则重构
添加功能时重构
修补错误时重构
复审代码时重构

代码的坏味道 有以下情况进行重构

  1. 重复代码
  2. 过长函数
  3. 过大的类
  4. 过长参数列
  5. 发散式变化
  6. 霰弹式修改
  7. 依恋情结
  8. 数据泥团
  9. 基本类型偏执
  10. switch惊悚现身
  11. 平行继承体系
  12. 冗赘类
  13. 夸夸其谈未来性
  14. 令人迷惑的暂时字段
  15. 过度耦合的消息链
  16. 中间人
  17. 狎昵关系
  18. 异曲同工的类
  19. 不完美的库类
  20. 纯稚的数据类
  21. 被拒绝的遗赠
  22. 过多的注释
    当你感觉需要撰写注释时 请先尝试重构 试着让所有注释都变得多余

构筑测试

如果你想进行重构 首要前提就是拥有一个可靠的测试环境

确保所有测试都完全自动化 让它们检查自己的测试结果
一套测试就是一个强大的bug侦测器 能够大大缩减查找bug所需要的时间
频繁地运行测试 每次编译请把测试也考虑进去 每天至少执行每个测试一次
每当你收到bug报告 请先写一个单元测试来暴露bug
编写未臻完善的测试并实际运行 好过对完美测试的无尽等待
考虑可能出错的边界条件 把测试火力集中在那儿
当事情被认为应该会出错时 别忘了检查是否抛出了预期的异常
不要因为测试无法捕捉所有bug就不写测试 因为测试的确可以捕捉到大多数bug

猜你喜欢

转载自blog.csdn.net/qq_26814945/article/details/82628384