《重构——改善既有代码的设计》（1）

第一个案例讲了顾客租影片的案例，讲了一个显示函数如果要在两个环境显示文本，可能会造成大量的重复代码，如果评判规则要更改，两个函数都要进行更改，很容易因为一起修改而导致他们之前出现不同而产生bug，所以，要保持代码的高复用性。关于这点，在实习的时候已经感受到了。

后面作者也说了要有自己的一个测试环境，这个东西根据各人岗位习惯不同而不同，需要自己定制，之前我从未考虑过这东西，东西做好都是直接交给测试的，这样很不好，很有可能要花费大量时间去在找bug产生的原因和位置，之前还看过一个叫单元测试的东西，因为使用lua的原因，我要对函数的参数进行值类型的判断（如果是c++或者java这种就不用做这操作了....）。因为我发现大部分的错误都是lua的值类型引起的，逻辑部分的错误反而更容易检测出来。

果然站在巨人的肩膀上走路好过自己盲人摸象搬的探索。。。

好的测试环境是重构的根本！

作者首先将某个计算规则拉出来作为一个函数，然后将变量名改掉。函数拉出来的目的是为了这个规则可以在多个显示环境重复利用，而改变量名的目的是为了，让其它人读懂代码。之前我是很忽略这一点的，直到我读到他人的代码，才会感受到世界对我的深深恶意，为了他人和自己，变量命名一定要好，不能牛头不对马嘴。

之后作者对新增的规则函数进行搬家，搬家的目的在我看来是分类，举例，如实数有加法，子类整数也有加法，当然实数的方法要放在实数，整数的加法也应该放在整数身上，这种分类的意义在于日后的维护，不然随意放置函数就像一个很乱的房子，而整齐的函数就像军营，代码的可读性更强。

后面作者还对临时变量进行去除，好处是降低临时变量会对代码造成的bug，缺点是性能变差。

小布前进

前面大部分工作都是为了去除临时变量

然后还用了类与状态模式的结合，来应对多种策略，还是第一次见到这样的代码，十分便于扩展，因为我现在的想法只到多态的程度，真想看看设计模式是如何在实战中的运用。

多态与状态模式取代条件逻辑，减少if else与switch

还有重构的节奏是一点一点搬移变迁加小测试的，想起我之前从无到有，直接删掉全部再去重写的重构方法真是汗颜。。。十分感激作者分享经验。