重构-改善既有代码的设计 读书心得（一）

《重构-改善既有代码的设计》

这本书有些“年纪”了，按理说it界的书都是读新不读旧。但它有点特别，其中的关于重构和面向对象的思想我觉得放到现在也是不过时的。好多时候我们考察一个程序员，都是看他懂多少东西，知道多少概念，做过什么项目，但其实一个程序员最关键的素质是要写出好的代码。好的代码不是一天炼成，往往都要经过大量重构迭代之后才能成型，这本书就是讲怎么去重构代码的。在一线coding的程序员估计对书中的很多观点感同身受。我看完后也受益颇多，想把其中的一些心得记录下来，不一定是原文翻译，其中可能会有一些我自己的感想的“私货”。接下来就开始吧。

第一章

1. 更改变量名是绝对值得的行为，好的代码应该清楚表达出自己的功能，变量名是代码清晰的关键。任何一个傻瓜都能写出计算机可以理解的代码。唯有写出人类容易理解的代码，才是优秀的程序员 。
2. 绝大多数情况下，函数应该放在它所使用的数据的所属对象内。
3. 重构的前提是需要有测试工具和测试用例，每次重构一小部分代码就进行测试，保证在不改变代码行为的前提下重构。
4. 不要对另一个对象的属性用switch，如果要用switch，也应该在自己的属性上用，这样可以解耦，别的对象的修改也影响不到你。
5. 影片可能会根据不同的类型有不同的收费规则，所以影片可以根据类型有不同的子类，但是有个问题，影片如果换了类型，但是class是不能换的，所以可以考虑影片没有子类，但是影片包含一个Price的类，这个类可以根据不同类型有不同子类。Movie有一个Price类的引用，不同的类型对应不同的Price子类，调用Price类的方法来计算收费。

第二章

1. 两顶帽子：添加新功能和重构。首先尝试添加新功能，然后意识到如果把程序结构改一下，添加新功能会方便很多，于是你换顶帽子，做一会重构。然后把帽子换回来，继续添加新功能，如此循环往复。
2. 完成同样功能，设计不好的代码往往需要更多的代码量，这是因为不好的代码在不同的地方使用相同的语句在做同样的事情，当你修改了一处忘了另一处就容易出bug，所以消除重复代码，保证同样的逻辑只出现一次，这正是优秀设计的根本。
3. 重构是软件更容易理解：代码的第一个读者是计算机，你必须写出让计算机能理解和执行的代码。代码的第二读者是未来的某个开发者（很有可能是你自己），你需要写出他能理解的代码，这样才不会只修改某段代码就花上一星期。
4. 重构帮你提升开发速度。良好的设计是快速开发的根本。如果没有良好的设计，可能一开始进展的很快，但是马上就会被大量bug淹没，导致你花很多时间去debug，打上一个又一个补丁，新功能又需要更多代码才能实现，恶性循环。
5. 重构的时机：不要安排固定的时间进行重构，而是开发阶段随时随地进行重构。
   三次法则：第一次做某件事时尽管去做，第二次做类似的事产生反感，但还是可以去做，第三次再做类似的事情，你就必须要重构了。
   添加新功能的时候是最常见的重构的时机，重构可以让开发者理解需要修改的代码，同时也让增加新特性更轻松一些。调试的时候也经常重构，一是可以增加可读性，二是能够帮忙找出bug。代码review的时候也可以进行重构，它能让你把代码看的更清楚，提出更多的有建设性的建议。
   程序有两面价值，今天能为你做什么和明天能为你做什么。很多时候我们只关心今天能为你做什么，修复bug添加功能，其实很少关注明天。当明天发现今天的设计不能满足要求，那我们就开始重构吧。
   重构也会有一些领域很难推进：
   1.数据库。数据库的结构很难改变，一旦改变意味着你不得不迁移数据。
   2.修改接口。如果接口的调用都是可控的，那对接口的重构很简单。但是接口如果是已发布接口，那你就必须维护新旧两套接口。尽量用旧接口调用新接口而不是复制代码。在一个功能包定义一个异常基类，这样就可以避免增加异常类型导致编译错误。
   何时不该重构：重写的一个信号是：当前的代码根本不能正常运作。而重构的前提是代码能在大部分情况下正常运作。项目的后期也不该重构，因为很可能会赶不上项目的deadline。项目的重构就像