观书笔记----《重构改善既有代码的设计》

最近刚看完了程序员的职业素养，但是过了几天了，去回忆这本书，除了能够想起Bob大叔说的测试驱动开发和什么时候学会说不，以及我们说完试试看就等于做了承诺之外，其它什么都想不起来，如果我再去正本阅读，必然兴趣泛泛，这两天又在看重构改善，和读职业素养一样仍然感觉干货满满，读完前两章，自己其实没记住多少知识，所以把它写成一篇自己的阅读笔记

第一章：重构第一个案例

1.何为重构：就是代码写好之后改进它的设计。

其实作者的很多观点与我之前的认识是相悖的，我认为一个项目的好坏最重要的是编写代码之前有一个完美的设计。所以在我的印象中，所有的大牛都是精通23种设计模式业务理解透彻，所以我成为不了我所认为的大湿。读完前两章，我意识到了，自己在思想存在一个误区。

我们一开始拿到需求，力求去设计一个完美的开发模式，但是需求是会变动的，现在废了很大的劲我们设计出来的结构，后期有很大的可能就不满足需求了，而我们要修改这种结构，很可能就需要分很大的时间和精力。

这本书给我们的观点，重构可以取代预先设计。我们一开始编程的时候只需要满足尽量合理设计就可以了，如果实在没有思路，可以不做任何涉及，甚至可以先变编码，后期我们在写的过程中对项目进行重构。

那什么过程中我们在重构呢？

1、在新增相似功能的时候，发现有两处相同的代码的时候，这时候需要我们进行重构了。

2、我们在调试Bug的时候，无法一眼看出bug的所在，那说明我们的编码的可读性是有一定问题的，需要重构。

3、尤为关键的一点，我们审查自己的代码的时候，我们的重构并不应该单独的抽出时间来进行重构，而是在我们平时工作中，我们就应该审查自己的代码。

我们之前的一个公司很不幸倒闭了，我当时刚培训的一名菜鸟进入的这家公司，当时工作就是缝缝补补，一个短信发送的功能如果进行修改的话，我需要修改七八处所有用到短信逻辑的地方，而且这些使用短信的地方，代码相同度达到80%,当时无法意识到问题,也就没有去修改。

现在我来思考公司，整个项目的架构有严重的问题，扩展性太差，我们修改一处代码，需要将所有用到的地方进行修改。当时作为菜鸟的我都能想到这种问题，那么其他人，想不到吗？

毋庸置疑，他们也能想象的到，但为什么没有改？

不敢改！为什么不敢改?

我现在来看，整个业务的代码就是简单的罗列在一起的，你修改一处，不知道影响到什么地方？甚至导致整个项目无法使用。

这是其一，另外没有测试方案，之前如果有相应的测试，我们只需要重构之后走测试就可以了。

还有领导只注重开发速度，而忽略产品质量，一致后面影响开发速度，进而修改任何的一处功能都是小心翼翼，重复的代码黏贴复制。

说了这么多，还没说如何重构？憋着急，这才第一章啊。。

总结：重构的节奏：测试，小修改，测试，小修改。。。这种节奏使重构快速而安全的进行。重申一遍，测试用例必须要写，他甚至比我们真正的业务还要重要。。。。。

第二章：重构原则

因为我是看完前两章才开始写的，所以本书的一些思想我已经写在第一章了。