重构二读书记
最近将重构（第2版）看完了，作为曾经的TWer，我司大佬出的书，不看确实不大好意思。
不得不说这本书写的太好了。好在书中提到的重构面临的问题及重构的解决方案与自己在不断编程，做项目中体会到的有很多共鸣点，同时通过阅读这本书，也学到了很多的经验点。
我想这就是好书，就是真切感受到书中所提到的点都是来自于一线的经验总结，而非假大空。
观点摘录
书中的一些观点和手法，细品，对于实际的编程有很高的参考和学习价值。比如下面的一些
- 编写管道运算时，我喜欢让结尾的分号单占一行，这样方便调整管道的结构
- 何时重构：三次法则
Don Roberts 给了我一条准则：第一次做某件事时只管去做；第二次做类似的事会产生反感，但无论如何还是可以去做；第三次再做类似的事，你就应该重构。正如老话说的：事不过三，三则重构。
何时不应该重构
- 并不需要修改时，就不需要重构，只有当理解其工作原理时，对其进行重构才有价值
- 如果重写比重构还容易，就别重构了。
对待注释的态度
如果你不知道该做什么，这才是注释的良好运用时机。除了用来记述将来的打算之外，注释还可以用来标记你并无十足把握的区域。你可以在注释里写 下自己“为什么做某某事”。这类信息可以帮助将来的修改者，尤其是那些健忘的家伙。
尽可能地使用管道代替循环
提炼函数的原则
一个函数一旦超过 6 行，就开始散发臭味。
重构不是某个阶段的产物，而是一直需要去做的事
如果是一个函数内部有返回值，这个返回值变量命名为result,便于快速知道这个函数的意图
断言的使用并不仅限于UT中，JS中对于断言的原生支持只有console.assert,在实际的业务代码中也可以使用，适当加入断言，用于说明情况，并且不要害怕，因为断言应该不会对系统运行造成任何影响。
断言对于发现错误源头特别有帮助.对待deadcode一律移除，假如真的存在找回来的可能的话，可以注释上提交ID，用于找回
好代码的检验标准就是人们是否能轻而易举地修改它。
…
好观点实在太多了，这里只摘录一些。
写在最后
如上所说，好书就是观点与自己的想法不谋而合，我就是如此。读完这本书，有几点想法
- 我一直觉得工程师与码农的区别是一个用脑子，一个不用脑子，这是句调侃，也是实话。工程师会去抽象审视问题，反思总结，而码农更多只是搬砖，无非是时间换钱，除此之外无所收获。但在告诉发展的今天，这个砖还能搬几天呢，我想应该会细思恐极吧。
- 书中序言，熊节大神提到
新一代程序员中，关注新工具、新框架、新商业模式者伙矣，关注面向对象、 TDD 、重构之类基本功者寥寥，是啊，面子技术层出不穷，我们确实也应该学习，但里子更应该重视啊，基本功即内功才是王道。所以序言这句话打动每个有想法，有感受的人心。多少人流于形式，去看了大量API，记忆那些版本号，但有何用呢？ - 我们追求的代码可读性，既定的对象是人而非计算机，所以写代码本身是要有责任感，不仅为自己负责，也要为将来的他人负责。所以不能
就这样吧，能用就行。 - 我自己读完这本书，对于抽象的看法认知，我吸收了大半，但对于具体的重构手法，我没法全部吸收，只能在实际的可以训练中去感受，同时形成自己的一套重构手法。
- 推荐每一个致力于写出好代码的人去看，此书值得一看