提升编程效率：重构

提升编程效率的大致可以分三类：任务拆解（Tasking To Action）、使用高效的开发工具/框架、关注高效的工程实践。

其中任务拆解，我们在【实战TDD（2）：Tasking To Action】(视频版) 中介绍了过了。

开发效率的工具/框架也才不但涌现，例如：Spring Boot、Spring Cloud、Elasticsearch 、Intellij IDEA 等为开发提供了不同领域的高效工具。

工程实践的也涉及到很多，比如：TDD、重构、Clean Code 等。

在过往的工作经历中，发现很多开发仅仅关注工具对开发效率的提升，当谈及如何写好代码时却没有像工具/框架那样能够侃侃而谈，究其原因是没有关注这方面的内容。

本文将聊聊提升编程效率的一个利器：重构。

为什么重构能够提升开发效率？

主要是以下五方面原因：

1. 重构能够持续守护代码结构，避免了设计的腐败。

2. 重构能帮助代码更容易被理解

3. 重构能够提升编程速度

4. 重构能够降低 Bug 修复时间。

5. 重构能够提供的更快的应对变化的能力。

01 重构能够持续守护代码结构，避免了设计的腐败。

代码结构的流失是累积导致的，越难看懂代码要表达的意图，就越难保护代码中的设计，原本的设计也就流失的越快，设计就会腐败的越快。

小步重构能够持续不断的改善代码重点问题，将“大泥球”的代码通过一个个小的重构动作，让原本的设计而已维护，或者所设重构结构的清晰，让原本没有什么设计的代码，能够更清晰的表达短期意图。

日常工作让重构不能持续的一个原因就是短期目的。短期目的很重要，让我们始终聚焦在重要且紧急的任务上，但是问题是“只是关注短期目的，而忽视长期目的”。我们可以通过技术债来让 ROI 更高，但是同样也需要关注长期的 ROI。因此日常工作中，我们可以借助可视化等手段，维持重构的习惯，避免让原本花过心思的代码变得别人嘴中腐败的代码。

02 重构能够帮助代码更容易的被理解

就如同重构的定义：在不改其行为的情况下，改善其内部结构，从而提高可理解性、降低维护成本。

我们都知道，重构的结果产生的代码，具有良好的可读性，并且与业务上下文相呼应。

其实，重构的过程，也能够让代码更容易被理解，也更容易理解原本的泥球代码的意图。一边读代码，一边讲发现的代码的坏味道消除掉，读完了代码也有了更加清晰的代码的结果。

《重构》一书中有这样一句话：

Ralph Johnson 把"早期重构" 描述为”擦玻璃窗户上的污垢，是你能够看的更远”。

03 重构能够提升编程速度

一个人 / 团队并不是只写一个方法，一个类，一个接口就结束了。而是要在一个项目中经历几周、几个月、甚至几年。项目过程中持续的重构能够持续不断的改善代码的设计，并使之干净。团队中并不会因为某段代码晦涩难懂而不敢修改、不愿修改（因为需要花费大量的时间去做一件产出很低的事情，但是很难做）。

相信很多团队都遇到遗留的代码，而那些到处散布着坏味道的代码，正是因为这样的代码让开发效率低下，甚至停步不前。

重构能够提升编程速度，并不难证明。通过几个迭代的产出的结果就可以轻松的证明，对比一下没有重构的团队、有部分重构的团队、持续重构的团队在几个迭代后的产出结果，就会发现，持续重构的团队产出的内容每个迭代的结果都是相对稳定的，而没有重构的产出结构会越来越少，甚至无法响应业务提出的需求。

在遇到的开发者中有的人甚至对重构持反对看法，甚至更加偏激。问题往往是出现不清楚重构的技巧、重构的手法、重构工具的使用，和重构的实际。了解这些知识能够让重构事半功倍。

重构也不提倡偏激的“纯重构，为了重构而重构”，面对现实工作中任务的轻重缓急，重构也有自己的原则，例如“事不过三，三则重构“。

04 重构能够降低 Bug 修复时间

试想一下在一大坨代码中找一个 bug 并修复容易，还是在结构清晰，意图明确的代码中定位 bug 并修复的成本高。

相信绝大部分情况都是后者。重构的结果就可能是生成一些小的方法，职责单一的类，层次结构相同的代码，在这样的代码中不用的担心不了解而不敢改动，看懂了代码即可修改。每个 bug 的上下文范围都小，修改后的代码影响范围也小。总的修复时间当然小。

05 重构能够提供的更快的应对变化的能力

现在工作中经常听到的一句话就是”拥抱变化“。开发者如何拥抱变化？加班加点？只能说是精神可嘉，但是方法不对。

重构产出了持续演进的代码设计，并消除日常代码中的坏味道，那么当新的需求到来，或者原油的需求需要进行更新调整，原来重构的结构能够帮助团队提升需求的变化的响应能力。

也是复杂的业务，清晰的代码设计所带来的复用和响应的能力的表现也就越强。