重构，改善既有代码的设计（第2版）读书笔记

背景

如同改代码、阅读代码，我们需要明确自己所工作的GIT仓库对应的分支一样，我们也记录下所阅读的书籍信息。

书名：《重构，改善既有代码的设计（第2版）》

作者：【美】马丁•福勒（Marthin Fowler）著

译者：熊节 林从羽 译

出版社：中国工信出版集团 人民邮电出版社

印刷版次：2019年5月第1版

说明

在阅读本笔记时如果发现有任何不合适的地方欢迎评论，因为每个人对同一个事情理解观念不一样，所以，评论时请好好说话这样有利于大家交流，看到评论我也会尽快闭环，尽快思考不足之处。

笔记中如果涉及到引用原文，会尽量注明页码，方便自己查询，也方便大家查询。

开动

1. 重构很重要
2. 重构不是一次到位的，在个人开发初始阶段精力时间允许的情况下尽自己最大努力去做到设计符合扩展有利于学习，在真正需要去重构的时候无需太过于纠结扩展性。
3. 小步前进

   刚接触重构的人看我用很多小步骤完成视乎可以一大步就能做完的事，可能会觉得这样很低效。但小步前进能让我走的更快，因为这些小步骤能完美地彼此组合，而且---更关键的是-----整个过程中我不会化任何时间来调试。（原文第46页）

4. 不用的代码删掉，而不是注释。借助GIT版本管理工具和比较工具（比如开源的KDIFF3），可以很快很方便的定位到代码所经历了什么，如果真的要注释，在项目组允许的情况下加注释到git commit信息中
5. 开发过程中尽量做电子版笔记，记录下一些自己可能会频繁去请教其他人的事情，按照操作系统的架构方式保存现场，因为工作中很有可能被更重要的事情中断或者需要把自己手上的事情交给其他人去做。
6. 在基于遗留代码的基础上进行问题定位解决bug和新需求开发的过程中，我们没有办法去做到一次改掉原来所有的checkStyle和codeStyle，但是我们有能力让自己在移植或者新开发的时候让自己新增的代码checkStyle和codeStyle尽量完美
7. 变量名和函数名尽量做到见名思意，对于开发移植的遗留代码的变量名做到不去创造新的国际化资源文件和不创造新的变量名，变量名尽最大可能与移植代码前保持一致
8. 重构太长的函数，对于看起来就需要深吸一口气去仔细看的函数（算法类的除外）如果发现其有if分支或者switc分支则将其复制出来定义一个private类型的函数。如果发现if中的条件太多，则建议将这些条件复制出来新定义一个函数，然后将这个函数再分类继续定义函数。
9. 保持自信，而又虚心学习，而又基于出错首先在自己的观点。在重构过程中因为是改动其他人的代码，任何改动理论上是要运行单元测试的，而运行的这些测试是需要事先就存在的，但是大部分遗留代码并没有完善的单元测试代码可以运行，在重构前，如有可能先适量的增加单元测试，或者不要动逻辑，参考小步前进。
10. 单元测试，在自己的能力范围之内行动起来，一小步一小步的走。