重构：使用一系列重构手法，在不改变软件可观察行为的前提下，调整其结构。用户的体验不应该有任何改变。如果我在重构过程中发现了任何bug，重构完成后同样的 bug 应该仍然存在。

重构的关键在于运用大量微小且不改变软件表现的步骤，一步步达成大规模的修改。每个单独的重构很小。

改进软件设计：代码不做重构，会因为每次的小改动导致混乱。类似于房间整理。其中之一就是减少重复代码；

(资料图)

使代码容易理解：让其他开发者能够读懂，他人能够读懂你的代码，就很容易去修改，提高开发效率。减少读代码时考古时间；

帮助找到 bug；

保持代码的清晰和有序，避免代码腐败；

Kent Beck 提出了“两顶帽子”的比喻。我们平常开发时包括两个活动：添加新功能、重构。两顶帽子交替进行，一会开发新代码，一会进行重构。添加新功能时如果发现一段代码可以更好，那就更换帽子，进行重构工作，完成后再继续添加新功能。

以下是几个常见的需要重构的情况：

代码重复：如果你发现有大量的相似或完全相同的代码，那么重构就是必须的，你可以通过抽象方法或类来减少重复。

难以理解的代码：如果代码难以阅读或理解，那么它需要重构，使得代码更易于理解，可以提高团队的生产力。

新增功能：在给现有代码添加新功能前，往往需要对其进行重构，以保持代码结构的整洁。

性能优化：如果代码的性能不佳，那么通过重构可能能找到优化的机会。

一块代码可以正常工作，不需要修改那就不重构；一个功能隐藏在一个 api 下，那就可以不重构；

如果重写比重构容易，那就重写；

紧迫的截止日期：在紧迫的截止日期面前，如果重构可能导致项目延期，那么你可能需要权衡是否真的需要重构；

缺乏测试：如果代码缺乏足够的测试，重构可能会引入新的错误，因此在重构之前，你需要确保有足够的测试用例。

浏览代码；

对照代码坏味道清单，检查是否符合；

如果出现则选择相应的重构方法重构，要注意的是，重构方法只是某种情景下的一种修改代码的方法，而不意味着这样重构在任何情况下的必然正确性。

神秘命名

重复代码

过长函数

过长参数列表

数据泥团

循环语句 Loops

重复的 switch

if else 多层嵌套

全局数据

可变数据

⌘