程序员修炼之道第六章读书笔记与感悟

程序员修炼之道第六章读书笔记与感悟

重写、重做和重新架构代码合起来，称为重构。

当代码出现以下特征，就应该考虑重构了：

出现重复内容，违反DRY原则。

非正交的设计。

知识过时了，或者你对某部分的了解更深一步。

对性能造成了影响。

重构的原则：早重构、常重构。重构面临的敌人通常都是时间，但这个借口并不成立，因为之后由此引发的时间额外消耗很可能更多。如何重构。

不要试图在重构的同时增加功能。

重构之前，确保拥有良好的测试。

采取短小，深思熟虑的步骤，不要一次改动太多内容。、软件 IC 是人们在讨论可复用性和基于组件的开发时喜欢使用的比喻。意思是集成电路芯片可以很容易的进行组合，我们希望软件开发也能达到这个效果。芯片的设计有完善的测试，同样的软件开发也可以做同样的事情。

针对合约进行测试及为测试而设计，即 TDD 测试驱动开发。

编写单元测试，对比较大的项目，将每个测试都放进一个子目录。

使用测试装备。构建一套完善的测试体系，它能够记录测试状态，分析输出结果是否符合预期，以及选择和运行测试。

推进测试文化，尽可能完善地测试你的软件，否则你的用户就得替你测试。

这里的向导指的是那些用于帮助我们构建程序自动生成的代码，通常他们还被称为脚手架。为什么称向导（wizard）是邪恶的呢，这是因为通过工具生成的代码，很容易被我们忽略，在这种情况下你编写的过程更倾向于靠巧合编程。

这里不是抵制向导代码，而是在强调，不要使用你不理解的向导代码。如果使用，一定要清楚它的机制。

开发每天都在使用不完全理解的事物，比如集成电路的工作原理，处理器的中断结构、用于调度的算法、各种系统库的工作机制等。需要注意的是，这些属于底层依赖，他们也是向导，但不是应用本身的一部分，我们可以对这部分有所了解，但他们不属于邪恶的向导。

比如我们常常使用向导生成漂亮的界面和背后的大量代码，只要再加入具体的应用功能，软件就可以交付了，但这往往是愚弄自己，除非我们真的理解那些替我们制作的代码，否则就是在靠巧合编程。向导是一条“单行道”——它们为你制作代码，然后就走了，如果它们制作的代码不完全正确，或者情形变了，需要改变代码，那么就只能靠我们自己了。我们不是在反对向导，但如果你真的使用向导，就要理解它制作出的所有代码，这样才能很好地控制并维护自己的应用。虽说除了依赖我们不理解的向导，我们也在依赖其它很多不理解的事物，比如集成电路的量子力学、处理器的中断结构、用于进程调度的算法、系统提供的API等。但向导与它们是有区别的，因为向导生成的代码变成了我们应用的组成部分，它们一行一行地与我们编写的功能交织在一起，最后它不再是向导的代码，而变成了我们自己的代码，没有人应该制作自己不完全理解的代码。所以不要使用你不理解的向导代码。