复用与现实
问题
- 程序员不知道如何重构
- 如果重构利益是长远的，何必现在付出？收益时，已经不在职位上了。
- 代码重构是一项额外工作，老板付钱时开发新功能
- 重构可能破坏现有程序
思路
先行者和早期接受者感兴趣的是新技术、“范式移转和突破性的思想的愿景”。
早期和晚期消费群体则主要关心成熟度、成本、支持，以及这种新思想或新产品是否被与他们有着相似需求的其他人成功套用。
要打动并说服软件开发者和软件研究者是完全不同的。
必须主管人员精心制定策略，在中阶经理层组织领导会议、项目开发组协商，通过研讨会和出版物向广大研究人员和开发人员宣扬这些技术的好处。比较重要的几件事：对员工进行培训、尽量获取短期利益、减少开销、安全引入新技术。
重构工具
总结
何时该使用、何时不该使用、何时开始、何时通知，这种节奏
如何学习
- 随时挑一个目标
- 没把握就停下来
- 学习原路返回
- 结队
一点点慢慢解决，添加新功能，添加测试，记录清单需要重构的、需要文档的、需要划的图
要点列表
如果你发现自己需要为程序添加一个特性，而代码结构使你无法很方便地达成目的，那就先重构那个程序，使特性的添加比较容易进行，然后添加特性。
重构前，先检查自己是否有一套可靠的测试机制。这些测试必须有自我检验能力。
重构技术就是以微小的步伐修改程序。如果你犯下错误，很容易便可发现它。
任何一个傻瓜都能写出计算机可以理解的代码。唯有写出人类容易理解的代码，才是优秀的程序员。
重构（名词）：对软件内部结构的一种调整，目的是在不改变软件可观察行为的前提下，提高其可理解性、降低其修改成本。
事不过三，三则重构。
不要过早发布接口。请修改你的代码所有权政策，使重构更顺畅。
当你感觉需要撰写注释时，请先尝试重构，试着让所有注释都变得多余。
确保所有测试都完全自动化，让它们检查自己的测试结果。
一套测试就是一个强大的bug侦测器，能够大大所见查找bug所需要的时间。
频繁地进行测试。每次编译请把测试页考虑进去 每天至少执行每个测试一次。
每当你收到bug报告，请先写一个单元测试来暴露这只bug
编写不完善的测试并实际进行，好过对完美测试的无尽等待。
考虑可能出错的边界条件，把测试火力集中在那儿。
当事情被大家认为应该会出错时，别忘了检查是否抛出了预期的异常。
不要因为测试无法捕捉所有bug就不写测试，因为测试的确可以捕捉到大多数bug。
说明
《重构-改善既有代码的设计》Martin Fowler 摘要： 第十三章 复用与现实、 第十四章 重构工具、 第十五章 总结、 后续：要点
你也可以访问：http://txidol.github.io 获取更多的信息