第二章来了！第一章的例子让我们对重构有了一点模糊的印象和非常良好的体验，第二章作者说明了一些重构的基本原则，也没有实际的的重构手法或者拿来就能用的结论，所以这一章还是先浏览一下，有很多不懂得地方也不要紧，在以后的学习中慢慢印证。
看了一部分之后我对写程序这个事情又有了一点思考，古人经常把事情分为“知难行易”和“知易行难”两种，那写程序到底算是哪一种呢？刚开始的时候不理解一点编程理论，可是还是可以写出来“Hello World”甚至于一些简单的程序和代码，那个时候还停留在“知难行易”的初级阶段；而有所了解想好好学一下的时候，就像我现在，正在看《设计模式》，能看懂定义和例子，可是要实际结合项目来做就马上会束手无策，完全摸不到头绪，或许现在就是“知易行难”了。
跑题了，现在开始第二章的读书笔记。
1.何谓重构
作者首先给Refactoring下了一个定义，作者的理解是重构有双重定义，名词定义和动词定义，其中名词定义更加清晰的说明了重构的目的：“提高代码可理解性，降低代码的修改成本”，做程序不可能不修改，能让修改成本降低就是重构也是架构的意义所在。
作者在这里额外提到了“两顶帽子”的比喻，在写程序的过程中我们时而要“添加功能”，时而要“重构”。这并不是冲突的，重构应该融入到日常的编码中去，而不应该独立出来，当然这是建立在非常熟练的重构手法和丰富的重构经验之上的。
2.为何重构？
作者首先提到了“重构可以改进软件设计”，这是毫无疑问的，在第一章的例子里面表现很明显，不知不觉中程序的架构和设计变得井井有条。在这一段中作者额外提到了程序的设计会逐渐腐败这个观点：虽然开工写代码之前有了架构设计，但是不注意维护的话，总做破坏架构的行为，随之而来的就是设计的逐渐腐败和倒塌，最终不免成为烂摊子，而时常遵循设计对代码进行重构可以有效避免这一个情况的发生。
提到这里，作者额外说了一句什么是优秀的设计，我理解的优秀设计就是妥协的产物，减少冗余代码和增强可读性，可维护性，灵活性和健壮性的平衡点就是优秀的设计。
作者其次提到了“重构使得软件更加容易理解”。这个很重要，因为代码的可维护性都靠他来支撑，让代码更好的表达自己的意图，也给以后的修改者一条明路。在这里作者额外提到“随着代码的渐趋简洁，我看到了一些设计层面的东西”，这个很神奇，我个人理解是在重构的过程中更好的理解了程序的意图，然后想出来更加好的设计模式或者看到了一些原有的设计。
再次作者说“重构帮助找到BUG”，“重构提高编程速度”，这两点还没有额外的体会，只有一句话说的不错“良好的设计是快速开发的根本”，要是在开发中误打误撞是非常痛苦的事情，所以做程序要做“谋定战”，三思而行，无利不起早是程序员优良的品质！
3.何时重构？
不要给重构额外的分配时间，这会让重构成为依赖而不是本能。我理解应该把重构和开发融到一起去，虽然在开始的时候可能不会太快速，但是良好的设计会让开发有“加速度”，当你明确的知道自己要做什么的时候，开发的速度是一日千里的。
4.重构的目的
小字段提到了这个，我们希望的程序是这样的：容易阅读/所有的逻辑都唯一指定/新的改动不会危及现在的架构/尽可能简单的表达逻辑，这四个目的第三个是需要架构支持的，其他三个只要做好重构就没有问题。
5.何时不应该重构
在deadline来临的时候千万不要重构。重构要冒着超时的风险，重构也会有一系列的问题，最明显的就是测试，费时而且有时候不是那么管用，在deadline之前做重构是会冒扣工资的风险滴，不管怎样，先跑起来再说。
6.重构和设计的关系
重构和设计是彼此互补的。设计指明了大的方向，但是具体的实施中却布满荆棘陷坑，如果不注意则会在编码中逐渐将好的设计彻底败掉，重构正好弥补了这个方面，不断的比照设计的思路修补代码，让设计的光芒更耀眼一些。
PS.在极限编程以及现在最fashion的敏捷开发中，设计的作用已经明显弱化，弱化就更加需要重构来增加代码健壮性和灵活性，这样才可以在弱设计甚至无设计的时候，保持程序的良好状态，随时应对设计的变更和需求的变更。
7.重构和性能
好吧这一节我唯一的感觉就是我需要一个测试工具，这个测试工具要能测出来生成了多少个对象以及这些对象都做了什么，哪个操作最为耗时。还有一个很好的说法是程序的运行也符合28原则，消耗80%时间的往往是20%的代码，所以在进行性能优化的时候，就要额外对这些进行关注了。
第二章小结：第二章理论性的东西很多，以后慢慢验证吧，希望在看完这本书之后再看第二章，能有更多的自己的体会和更多的新观点。
未完待续。。