《重构：改善既有代码的设计》读书笔记（一）

各位程序老司机对重构肯定不会陌生，程序员的工作离不开重构。那么重构是已经“飞入寻常百姓家”的普通技术能力，还是看起来高大上的杀器？

对于一项技术你并不是天生就会而是需要持续学习的，很多人对重构的认识停留在 DevTools 自带的 Refactor 工具和搜索引擎出来的几篇文章，但是这样得到的知识并不够完善和系统。所以当指点江山、慷慨激昂的重构时，或许你还不会重构。

这个系列文章会记录关于这本书的读书笔记，自己的思考都会在段落前面备注（思考：）。

对代码要有敬畏，教条是教条，重要的是自己的思考、实践和从中收获（与代码的一种默契、与这种场景的合拍，找到一种知音的感觉）。

一、重构、第一个案例

定义：在不改变软件可观察行为的前提下改善其内部结构，提高其可理解性、降低其修改成本。本质上说重构就是在代码写好之后改进它的设计。

想真正让重构技术发挥威力，就必须做到“不需了解软件行为”――听起来很荒谬，但事实如此。如果一段代码能让你容易了解其行为，说明它还不是那么迫切需要被重构。

那些最需要重构的代码，你只能看到其中的“坏味道”，接着选择对应的重构手法来消除这些“坏味道”，然后才有可能理解它的行为。而这整个过程之所以可行，全赖你在脑子里记录着一份“坏味道”与重构手法的对应表。

1.1 起点

如果你发现自己需要为程序添加一个特性，而代码结构使你无法很方便地达成目的，那就先重构那个程序，使特性的添加比较容易进行，然后再添加特性。

思考：发现痛点果断重构。重构分大小，不要把重构想象成都是庞大、旷日持久的工程而不愿开始，每天甚至每个小时都可以完成一项小重构。

1.2 重构第一步

重构前，先检查自己是否有一套可靠的测试机制，这些测试必须有自我检验能力。

更改变量名是否值得？绝对值得， 好的代码应该清楚表达出自己的功能，变量名称是代码清晰的关键。