重构改善既有代码的设计—— 读书笔记

虽然本人是计算机专业 毕业，但是也学过软件工程这本课程的。但是在开发这几年中，听到架构二字，心中总是充满敬畏。

后来和公司后端部门的架构师聊了以后，发现其实架构并没有那么神秘，给我的建议是——人人都可以做架构师。最起码一位合格的程序员都要有一颗做架构师的心。

拿破仑曾说—— 不想做将军的士兵不是好士兵。重构项目之后，也有了一些心得体会，所以再来拜读重构改善既有代码的设计 这本业内经典。

1. What’s 好的程序员？

任何一个傻瓜都能写出计算机可以理解的代码，唯有写出人类容易理解的代码，才是优秀的程序员。

2. What’s 重构

所谓重构(refactoring) 是这样一个过程：

在不改变代码外在行为的前提下，对代码作出修改，以改进程序的内部结构。重构是一种经千锤百炼形成的有条不紊的程序整理方法，可以最大限度地减少整理过程中引入错误的几率。本质上说，重构就是在代码写好之后改进它的设计。

对此，I can not agree more…

重构确实是一个长期的过程，而且重构不是什么非得把代码大刀阔斧地改进一番才叫重构。在日常开发中，我们修改一函数名使之便于理解，也算是重构。

而且书中提到：

重构技术就是以微小的步伐修改程序，这样如果犯错，可以立即发现并纠正它。

对此，我深有体会，我在重构项目中，有时候会修改大量的代码，最后编译运行以后报错，无奈只能回滚代码。

2.1 容易被忽略的重构行为

更改变量名是值得的行为吗？
书中给出我们的答案是：绝对值得

因为好的代码应该清楚表达出自己的功能，变量名称是代码清晰的关键。这就暗示我们，在阅读自己的代码时，也时刻保持着重构的心。

相信我，遇到变量名乱起的代码，你会发疯的。

书中也提到，合理地使用临时变量，因为它往往会引发问题。

3. Why 重构

1. 改进软件设计；
2. 使软件更容易理解；
3. 帮助找出BUG；
4. 提高编程速度；

良好的设计是快速开发的根本。

---

Kent Beck “两顶帽子”的比喻：

1. 添加新功能；
2. 重构

4. When 重构

在现实开发中，往往出现开发者对CTO提出重构需求，然后申请时间去专门处理重构这件任务。然后夹杂着新需求，痛不欲生啊…

书中的作者也提到：反对几乎任何情况下专门抽出时间进行重构。重构应该随时随地地进行。

这里作者贴心给我们一个三次法则——事不过三，三则重构。

1. 第一次做某件事只管去做；
2. 第二次做类似的事会产生反感，但无论如何还是可以去做；
3. 第三次再做类似的事，就应该重构；

在项目开发过程中，什么时候去考虑重构：

1. 添加新功能时重构；
2. 修复问题时重构；
3. 复审代码时重构；

---

审视一下自己的代码是否需要立刻重构：

1. 难以阅读的程序，难以修改；
2. 逻辑重复的程序，难以修改；
3. 添加新功能时还需要改动已有代码的逻辑，难以修改；
4. 带复杂的判断条件的程序，难以修改；

5. 个人总结

团队最好能先制定一些开发规范，避免代码差异化过大；
团队成员应该时刻关注自己的代码质量；
书中有些方案不错，但是在现实中实行起来却非常困难…