虽然本人是计算机专业 毕业，但是也学过软件工程这本课程的。但是在开发这几年中，听到架构二字，心中总是充满敬畏。
后来和公司后端部门的架构师聊了以后，发现其实架构并没有那么神秘，给我的建议是——人人都可以做架构师。最起码一位合格的程序员都要有一颗做架构师的心。
拿破仑曾说—— 不想做将军的士兵不是好士兵。重构项目之后，也有了一些心得体会，所以再来拜读重构改善既有代码的设计 这本业内经典。
1. What’s 好的程序员？
任何一个傻瓜都能写出计算机可以理解的代码，唯有写出人类容易理解的代码，才是优秀的程序员。
2. What’s 重构
所谓重构(refactoring) 是这样一个过程：
在不改变代码外在行为的前提下，对代码作出修改，以改进程序的内部结构。重构是一种经千锤百炼形成的有条不紊的程序整理方法，可以最大限度地减少整理过程中引入错误的机率。本质上说，重构就是在代码写好之后改进它的设计。
对此，I can not agree more…
重构确实是一个长期的过程，而且重构不是什么非得把代码大刀阔斧地改进一番才叫重构。在日常开发中，我们修改一函数名使之便于理解，也算是重构。
而且书中提到：
重构技术就是以微小的步伐修改程序，这样如果犯错，可以立即发现并纠正它。
对此，我深有体会，我在重构项目中，有时候会修改大量的代码，最后编译运行以后报错，无奈只能回滚代码。
2.1 容易被忽略的重构行为
更改变量名是值得的行为吗？
书中给出我们的答案是：绝对值得
因为好的代码应该清楚表达出自己的功能，变量名称是代码清晰的关键。这就暗示我们，在阅读自己的代码时，也时刻保持着重构的心。
相信我，遇到变量名乱起的代码，你会发疯的。
书中也提到，合理地使用临时变量，因为它往往会引发问题。
3. Why 重构
- 改进软件设计；
- 使软件更容易理解；
- 帮助找出BUG；
- 提高编程速度；
良好的设计是快速开发的根本。
Kent Beck “两顶帽子”的比喻：
- 添加新功能；
- 重构
4. When 重构
在现实开发中，往往出现开发者对CTO提出重构需求，然后申请时间去专门处理重构这件任务。然后夹杂着新需求，痛不欲生啊…
书中的作者也提到：反对几乎任何情况下专门抽出时间进行重构。重构应该随时随地地进行。
这里作者贴心给我们一个三次法则——事不过三，三则重构。
- 第一次做某件事只管去做；
- 第二次做类似的事会产生反感，但无论如何还是可以去做；
- 第三次再做类似的事，就应该重构；
在项目开发过程中，什么时候去考虑重构：
- 添加新功能时重构；
- 修复问题时重构；
- 复审代码时重构；
审视一下自己的代码是否需要立刻重构：
- 难以阅读的程序，难以修改；
- 逻辑重复的程序，难以修改；
- 添加新功能时还需要改动已有代码的逻辑，难以修改；
- 带复杂的判断条件的程序，难以修改；
5. 个人总结
团队最好能先制定一些开发规范，避免代码差异化过大；
团队成员应该时刻关注自己的代码质量；
书中有些方案不错，但是在现实中实行起来却非常困难…