[美] 马丁·福勒(Martin Fowler) 著
随便说说
重构的定义
用做名词：在不改变软件的前提下，提高其，降低其的手法。
用做动词：使用一系列，在不改变软件可观察行为的前提下，。
正文节选总结
- 傻瓜都能写出计算机可以理解的代码。唯有写出人类容易理解的代码的，才是优秀的程序员。
- 只有充分理解需求，才能够做好设计。但的存在使它总是不能够达到。
- 好代码的检验标准：是否能轻而易举地修改它。
- 设计总是在时间流逝中逐渐腐坏，但重构可以改变这一观点。
- 设计耐久性假说：通过投入精力，我们增加了，从而可以更长时间地。
- 持续集成（CI）需要拆分功能的能力，需要项目支持特性开关。
- 不要隔离团队内成员的代码，应该让成员可以监控到各自的代码责任区的变化。
- 不要过度设计，未来的变化可以交给重构，当下只需要写需求中的功能。
- 再次强调：代码的自测试很重要。
- 是编程中最难的两件事之一。另一件是（一致性问题）。
- 想不出好名字，往往是设计还不够到位。
- 可以做点什么重构
做一些使添加新功能更容易
在时重构使功能更容易被理解
观察代码时发现某些功能可以
有计划的重新发现可能重构点
在解决旧的时进行长期的重构 - 如果你要给程序添加一个特性，但发现代码因缺乏良好的结构而不易于进行更改，那就先重构那个程序。
- 勇敢地把做了过多事情的循环拆分成多个循环函数。
- 将总是一起变化的东西放在一块儿。
- 每当你感觉需要注释来说明的时候，我们就把需要说明的东西写进一个独立函数中，并以其用途命名。
- 应该重构的内容：原文有24种，此处提炼成8种
隐藏：信息过多或过少都会无法控制。原文：、和
重复：重复的信息浪费脑细胞。原文：、和
堆积：冗长的内容总是难以被理解。原文：、、、和
共享：多个实体控制同一份数据。原文：、和
关联：一个修改必须同时进行其他几个修改。原文：、和
无效：没有调用，过度封装，历史代码注释。原文：、、和
偏执：常用的数据类型就直接定义出结构来，将循环做的事情进行拆分而更清晰。原文：和
错误：子类只实现父类的部分功能等。原文： - 应该重构的内容达到什么再进行重构需要经验。
- 每次进行一小步。每一步测试成功的修改，都做一次本地提交。
- 重构过程不需要特别在意，因为重构只为了代码、。
- 需求的变化使重构变得必要。如果一段代码能正常运行，需求不再变化，那它不需要重构。
- 因为需要把控成本，所以无需一次做到极致，但应该遵循营地法则：保证你离开时的代码库一定比来时更健康。
- 不要告诉经理你正在进行重构，自行将其安排到你的每一项工作中去。
- 重构后运行过慢重构出容易调优的代码，再对它进行调优。
- 调优一般有：（预先定义每个组件的时间占用和空间占用）、（随时保持系统的高性能，通常效果不好）。
- 调优必须在数据的支持下，否则将“劳而无获“。
- 不要在测试之间共享数据。
- 断言之前产生的测试错误，可以尝试在代码中引入预先的错误断言来阻断。
- 每当有一个BUG被发现，就应该先写一个测试来暴露这个BUG。
补充一个常规的重构流程
- 确保即将修改的代码拥有一组。
- ：抽离需要结构化的函数部分构成一个新函数。
- ：临时变量实质上是鼓励你写长而复杂的函数。
- ：变量名需要让读者可以顾名思义。
- ：在需要修改的地方，将原函数提炼成两个函数
声明：本站部分文章及图片源自用户投稿，如本站任何资料有侵权请您尽早请联系jinwei@zod.com.cn进行处理,非常感谢！