《重构-改善既有代码的设计》第四、第五章读书笔记

《重构》第四章读书笔记

构筑测试体系。重构的前提是要有可靠的测试环境，可靠的测试环境可以检测重构之后的代码是否有问题，即便是用工具重构代码，仍然需要测试。因为每次重构完就测试可以快速定位bug，避免了了后面花费大量时间找bug，因此测试可以极大提高编程速度。

测试代码的价值。程序员在开发的过程中，可能会出现很长时间都在调试的现象，修复错误本身并不会花太多的时间，但是要找到这个错误，要花很多时间精力在上面。作者提供给解决这个问题的办法，就是测试，根据作者总结的经验：每个类都应该有自己的测试函数，并且用程序来对比测试函数产生的结果与预期的结果，自动化判断测试是否通过。而且每次编译都应该测试，这样做的好处是，如果在测试的过程中发现了错误，那肯定是在上次测试与本次测试过程中的代码有问题，因而bug会比较容易定位。

另外，写测试最有用的时机是在写代码之前，作者这么说的原因是，这样程序员可以注意力更加集中在接口而非实现上面，开发的目标更明确。

总结：1.测试可以帮助我们快速找到bug，避免了后期花费大量时间调试，提高工作效率。2.明确开发目标。

Junit测试框架。作者推荐了一个测试用的框架，可以用Junit框架来进行单元测试。看了网上Junit测试框架的说明和教程，方便使用，并且测试结果很直观。除了单元测试，还可以进行功能测试，功能测试有别于单元测试，功能测试更注重程序的功能是否能正常运作，发现bug后可能还需要单元测试定位bug，总之，一收到bug就进行单元测试来暴露这个bug。

添加更多测试。观察类应该做的事情，对可能失败的情况，可能出错误的地方进行测试，测试每一个可能出错的函数，但是添加更多测试并不是要去测试每一个函数，很多简单的不太可能出错误的函数，就没必要一一测试看，我们需要把有限的精力和时间用在关键的地方。作者这么说，大意是测试并不需要大量完善的准备，如果一个完美的测试环境需要大量准备，花费你太多时间太多精力，不如立马进行一些简单的测试。好像还是没说清楚。总之，我理解测试是为了写代码或者重构服务的，不应该喧宾夺主，占用太多的精力和时间，当测试达到一定量而让程序员气馁，影响工作，得不偿失。总结一下，就是测试是服务于业务的，测试应该放在可能出错的地方。

《重构》第五章读书笔记

本书在介绍重构的时候，采用了一种标准格式，每个重构手法都有五个部分。1.名称（name） 2.简短概要（summary），简单说明该手法适用场景，功能。 3.动机（motivation），为什么需要这个重构和什么情况下不该用。 4.做法（mechanics），该手法的重构教程。 5.范例（examples），用例子来解释重构手法。

很多重构需要找到某个函数、字段、类的所有引用点。现在可以用IDE，文本工具来找到。

重构的基本技巧，小步前进，频繁测试。本书中的重构手法，都是作者使用过的手法，将其提炼出来去匹配其他人遇到的问题，也许不一定能完全匹配，因此我们在使用的时候，要知道自己在做什么，对自己的代码清楚了解，让这些重构手法来适应自己遇到的情况，而不是盲目套用。