前言

什么是重构：所谓重构是这样一个过程，在不改变代码外在行为的前提下，对代码做出修改，以改进程序的内部结构。

第一章 重构，第一个示例

示例可以看见事情在真正的进行。该原理，很容易流于泛泛，又很难说明如何实际应用。

如何程序杂乱无章，先为它整理出结构来，再做需要的修改，通常来说更加简单。

如果你要给程序添加一个特性，但发现代码因缺乏良好的结构而不易进行更改，那就先重构那个程序，使其比较容易添加该特性，然后再添加该特性。

是需求的变化使重构变得必要。如果一段代码能正常工作，并且不会再被修改，那么完全可以不去重构它。

重构的第一步：确保即将修改的代码拥有一组可靠的测试。

重构前，先检查自己是否有一套可靠的测试集。这些测试必须有自我检验能力。

重构过程的精髓：小步修改，每次修改后就运行测试。

傻瓜都能写出计算机可以理解的代码，唯独能写出人类容易理解的代码的，才是优秀的程序员。

好代码应该能清楚地表明它在做什么，而变量命名是代码清晰的关键。

编程时，需要遵循营地法则：保证你离开时的代码库一定比来时更健康。

好代码的检验标准就是人们是否能轻而易举地修改它。

第二章 重构的原则

如果有人说他们的代码在重构的过程中有一两天时间不可用，基本上可以确定，他们在做的事不是重构。

重构是为了让代码，更容易理解，更容易修改。

两顶帽子：添加新功能和重构。

消除重复代码是改进设计的一个重要方向。

Kent Beck：我不是一个特别好的程序员，我只是一个有着一些特别好的习惯的还不错的程序员。

由于预先做出良好的设计非常苦难，想要既体面又快速地开发功能，重构必不可少。

三次法则：当一段代码出现三次时，需封装处理。

如何把某些更新数据的逻辑与查询逻辑分开，会更容易避免造成错误的逻辑纠缠。

Kent Beck：每次要修改时，首先令修改很容易，然后再镜像这次容易的修改。

代码复审也让更多人有机会提出有用的建议，毕竟我在一个星期内能够相处的好点子很有限。如果能得到别人的帮助，我的生活会滋润得多，所以我总是期待更多的复审。

结对编程：在编程过程中持续不断地进行代码复审。

何时不应该重构：如果一段凌乱的代码，但并不需要修改它，那么我就不需要重构它。如果重写比重构还容易，就别重构了。

重构的唯一目的：就是让我们开发更快，用更少的工作量创造更大的价值。

重构应该总是由经济利益驱动。

代码所有权：接口的使用者与声明者必须彼此独立，声明者无权修改使用者的代码。旧的接口可以标记为不推荐使用，等一段时间再下架。但有些时候，旧的接口必须一直保留下去。

测试：人总是会有出错的时候，不过只要及时发现，就不会造成大问题。既然每个重构都是很小的修改，即便真的造成破坏，我也只需要检查最后一步的小修改，就算找不到出错的原因，只要回滚到版本控制中最后可用版本就行了。

自测的代码不仅使重构成为可能，而且使添加新功能更加安全。

软件开发式意见复杂而微妙的事情，涉及人与人之间、人与机器之间的复杂交互。

哪怕你完全了解系统，也请实际度量它的性能，不要臆测。要有证据支持。

优秀的程序员肯定至少花一些时间来清理自己的代码。

第三章 代码的坏味道

神秘命名、重复代码、过长函数、过长参数列表、全局变量、可变数据、发散式变化、散弹式修改、依恋情结、数据泥团、基本类型偏执、重复的switch、循环语句、冗余的元素、夸夸其谈通用性、临时字段、过长的消息链、中间人、内幕交易、过大的类、异曲同工的类、纯数据类、被拒绝的遗赠、注释。

关键不在于函数的长度，而在于函数做什么和如何做之间的语义距离。

函数式编程：完全建立在”数据永不改变“的概念基础上，如果要更新一个数据结构，就返回一份新的数据副本，旧的数据仍保持不变。

设计api时，就可以使用将查询函数与修改函数分离，确保调用者不会调用有副作用的代码。

将总是一起变化的东西放在一起。

当你感觉需要撰写注释时，请先尝试重构，试着让所有注释都变得多余。

第四章 构筑测试体系

确保所有测试都完全自动化，让它们检查自己的测试结果。

测试驱动开发的编程方式：先编写一个测试，编写代码使测试通过，然后进行重构以保证代码整洁。

考虑可能出错的边界条件，把测试火力集中在那儿。

由于代码示例太多，可查阅原文链接：mp.weixin.qq.com/s?__biz=MzI0NDAwN...