阅读笔记——《重构》（一）

一、为什么要重构

但项目是要交付给客户的，是可以有效运行的代码，不是用以取悦学究的代码。

诚然，面对紧张的项目周期，抽时间去进行“看似”与上线毫不相干的重构工作是一笔看不到实际回报的支出。但是真正运用重构之后就会发现如果想要使一个项目能够持续运行并且后期易于迭代，重构是必不可少的软件开发流程。

什么是重构？书中给予了答案，重构就是在代码写好之后改进它的设计。没有什么软件的设计是在从0到1的过程中完全不变的，最初做软件时我也有这样的疑问，为什么不在一开始就设计好所有的功能模块然后进行开发？这样就避免了后期需求变更产生的新工作量，后来经过实践才发现没有人能够在一开始就完美的设计好一整个健壮的软件，因此开发与需求变更往往是同步进行的，所以重构就显得更加的重要，防止我们的代码随着不断的变更而堆积如山，难以维护。

而且当代码越来越多的时候，我们的改动往往不如预期一样产生效果，很多时候是因为只修改了一处而忽略了另一处，因此消除重复代码（不仅是物理上的重复代码，有时也是业务逻辑上实现了同样或者相似功能的代码）也是重构的重要一环。

好代码的标准就是人们是否能轻而易举地修改它。

重构的过程尽量小而微，过程中的代码很少进入不可工作的状态。

如果我在重构过程中发现了任何bug，重构完成后的bug应该仍然存在。

书中提到了“两顶帽子”的概念，即软件开发中应该明确的区分开添加新功能和重构，而这点往往被很多人混到一起，试图一次性地完成一个大模块的所有代码，但往往这样的想法付诸实践后会导致一些新的bug产生，或者由于难以梳理自己的逻辑导致代码写到一半后再无从下手，而调查这些新的bug花费的时间则被白白浪费掉了。

• 重构改进软件设计
• 重构使软件更容易理解
• 重构帮助找bug
• 重构提高编程速度

二、何时重构

重构可以在添加新功能之前，重新审视一下自己或者别人编写的代码，第一步是要理解代码在做什么，才能进行重构。

从微小的步子开始，先给几个难以理解的变量改个名，分解一个大的方法，与此同时也要时刻监视者软件是否还能够正常地运行，正是这些细微的操作可以慢慢地理解代码然后迈更大的步子。

肮脏的代码必须重构，但漂亮的代码也需要很多重构。

重构到什么地步？一个方法分解到什么程度才是可扩展的？这就需要结合项目实际的业务需求进行更深的思考，来保证重构的合理性，而有时经验尚浅的开发人员则需要资深开发人员的 code review 来帮助自己进行重构。

三、代码坏味道

那如何判断哪一段代码应该进行重构？想着手重构却又怕“矫枉过正”，作者系统的梳理了如何判断是否需要进行重构，而不是仅仅停留在模糊的认知层面。

• 过长函数

就算只有一行代码，如果它需要以注释来说明，那也值得将它提炼到独立函数中去。

• 霰弹式修改

如果每遇到某种变化，你都必须在许多不同的类内做出许多小修改，你所面临的坏味道就是霰弹式修改。

• 依恋情结

所谓模块化，就是力求将代码分出区域，最大化区域内部的交互、最小化跨区域的交互。

• 基本类型偏执

字符串是这种坏味道的最佳培养皿。

• 夸夸其谈通用性

当有人说“噢，我想我们总有一天需要做这事”。
常常会有这样的情况：你看到一段代码有着长长的注释，然后发现，这些注释之所以存在乃是因为代码很糟糕。

四、小结

针对与“重构”这一概念进行解释，重构能带来什么？何时重构？以及什么样的情况下需要重构等等进行概念上的阐述与说明，对重构有了系统性的了解。

点此访问我的个人博客