重构

五星上将麦克阿瑟曾经说过：

“写这段代码的时候只有我和上帝知道它是干嘛的，现在只有上帝’”

相信大部分猿人们都被来自远古的代码气到喷血，为了让自己心情舒畅，咱们自己写的代码要上一些规范，远古的代码要进行适当重构。

我们的目标：

• 高的代码质量
• 代码的可读性
• 可维护性和性能

个人喜欢的原文精句：

1. 傻瓜都能写出计算机可以理解的代码。唯有能写出人类容易理解的代码的，才是优秀的程序员。
2. 重构前，先检查自己是否有一套可靠的测试集。这些测试必须有自我检验能力。
3. 重构技术就是以微小的步伐修改程序。如果你犯下错误，很容易便可 发现它。
4. 谈原理，很容易流于泛泛，又很难说明如何实际应用。给出一个示例，就可以帮助我把事情认识清楚。
5. 大多数情况可以这么做：如果重构引入了性能损耗，先完成重构，再做性能优化
6. 每当感觉需要以注释来说明点什么的时候，我们就把需要说明的东西写进一个独立函数中，并以其用途（而非实现手法）命名。我们可以对一组甚至短短一行代码做这件事。哪怕替换后的函数调用动作比函数自身还长，只要函数名称能够解释其用途，我们也该毫不犹豫地那么做。关键不在于函数的长度，而在于函数“做什么”和“如何做”之间的语义距离。

重构的定义

改进现有代码的质量、可读性、可维护性和性能，而不改变其外部行为。

何时应该重构

1. 代码复审（Code Review)

• 代码复审是一个重要的重构时机。当其他开发人员审查代码时，他们可能会提出改进建议，例如提取方法、重命名变量等。

2. 新功能添加或缺陷修复

• 在添加新功能或修复缺陷之前，可以考虑重构现有代码以确保代码的质量和可维护性。这可以防止将新问题引入代码中。

3. 代码维护

• 定期进行代码维护是一个理想的重构时机。随着时间的推移，代码可能会变得复杂、难以理解和难以修改，因此定期的重构可以确保代码保持健康状态。

3. 性能优化

• 当应用程序性能不符合要求时，可以进行性能优化的重构。这可能包括改进算法、减少资源消耗或优化数据库查询等。

4. 技术升级

• 当您决定升级项目中使用的技术栈或库时，可能需要进行一些重构以适应新的技术。

5. 变更需求

• 当项目的需求发生重大变化时，可能需要对现有代码进行调整和重构，以适应新需求。

6. 测试驱动开发（TDD）

• 在采用TDD的开发方法时，重构是整个开发过程的一部分。在编写测试用例和生产代码之间，可以进行迭代的重构来改进设计。

7. 团队讨论和反馈

• 在团队会议或讨论中，可能会提出关于代码质量和设计的问题，这些问题可以触发重构的行动计划。

8. 代码坏味道（Code Smells）

• 代码坏味道是指代码中的一些常见问题，如长方法、重复代码、过于复杂的条件等。当发现这些问题时，可以考虑重构来去除坏味道。

9. 新技术的采用

• 当新技术或编程语言出现并具有优势时，考虑重构以利用新技术的优势。

何时不应该重构

1.不需要修改的代码

2. 隐藏在一个API之下，只有当我需要理解其工作原理时，对其进行重构才有价值

3. 重写比重构还容易

如何判断此处该重构/代码的坏味道

1. 神秘命名

• 识别标志：变量、方法或类命名不具有描述性，难以理解。（type1 type2 随意的abc 汉语拼音 莫名其妙的缩写）

• 解决方法：改变函数声明、变量改名、字段改名（命名用词要精准，不要缩写）

2. 重复代码

• 识别标志：两段相似的代码
• 解决方法：提炼函数、移动语句、函数上移等手法

---

感谢 s33h0w 的思维脑图

• 代码的坏味道
• 重构手法