大家好，又见面了，我是全栈君。

【《重构 改善既有代码的设计》学习笔记2】重构原则

本篇文章的内容来自《重构 改善既有代码的设计》一书学习笔记整理并且加上自己的浅显的思考总结！

上一篇通过一个简单的例子体验了一把重构过程，现在我们需要回过头看一下重构的一些背景、原理和理论。 并思考一下重构的关键原则是什么，以及重构时需要考虑哪一些问题？

一、什么是重构

1、 重构的定义

“重构” 这个词有两种不同的定义！

• 名称形式

重构 ： 对软件内部结构的一种调整，目的是在不改变软件可观察行为的前提下，提高其可理解性，降低其修改成本。

• 动词形式

使用一系列重构手法，在不改变软件可观察行为的前提下，调整其结构。

思考： 重构 就是整理代码吗？

从某种角度来说，是的。 但是重构不止于此，它还提供一种更高效且受控的代码整理技术。 从重构的定义也可以看出，重构的目的是软件更容易被理解和修改。如果可以很好的运用重构技术，你会发现自己对代码的整理比以前更有效率，也将编码中的错误减到最小。【 学习重构的技术和手法，其实就是学习一种思想或者说是编码的技巧，这是我觉得学习这本书的最大意义】

2、两顶帽子

使用重构技术开发软件时候，开发人员的时间分配给了两种截然不同的行为：添加新功能、以及重构。

添加新功能时，不应该修改即有代码，只管添加新功能。

重构的时候，就不能添加新功能，只管改进程序结构。

软件开发过程中，这两顶帽子需要经常变换，但是 不论如何切换，你都应该要知道当前自己戴的是哪一顶帽子。

二、为何重构

重构不是万能的，但很有价值！

思考 ：你有没有遇到过这种情况，就是当修改之前开发好的一个功能的代码的时候，看到这段代码没有注释，一个方法的长度有几百行，你有没有想过去重构它？

1、重构改进软件设计

如果没有重构，程序的设计会逐渐腐败变质。很多时候我们在做项目的时候，为了短期快速完成需求，在没完全理解整体设计之前，就贸然修改代码，程序也逐渐失去了自己的结构，程序员越来越难通过阅读源码而理解原来的设计。【说简单一点，就如我们住的房子，如果我们把东西随意摆放，久而久之，房子越来越乱，到最后不仅是找东西不容易，而且也会破坏房子原本的设计】

所以，经常性的重构可以帮助代码维持自己该有的形态。【类似房子也要经常整理，保持其该有的设计风格】

设计不良的程序在完成同样的一件事情上，往往需要更多的代码。这常常是因为代码在不同地方使用完全相同的语句做同样的事。因此改进设计之一 ： 消除重复代码，重复的代码越多，正确的修改就越困难，因为有更多的代码需要理解。比如你在这个地方做了一点修改，系统却不如预期那样工作，是因为你没有修改另一处代码（另一处的代码做着几乎完全一样的事情）。优秀的设计： 确定所有事物和行为在代码中只表述一次。

2、重构使软件更容易理解

• 可理解性之一：让第二读者更容易懂程序代码

所谓程序设计，很大程度就是与计算机交谈：让计算机按照你编写的代码来做事情。其实除了计算机之外，你写的代码还有第二阅读者，这个第二阅读者可能是几个月后的你自己，也可能是另一个程序员【程序员跳槽比较频繁】来读懂之前写的代码并进行一些修改。我们很容易忘记这第二阅读者，实际上他的重要程度远大于计算机。

• 可理解性之二：让自己更容易懂那些不熟悉的代码

利用重构协助我们理解不熟悉的代码，因为重构是小修改+测试的步伐，给了我们检验自己理解代码功 能是否正确的良好方法。

Ralph Johnson “早期重构” ，描述为 “擦掉窗户上的污垢，使你看的更远”。 窗户擦干净了，看到的世界也透明，清亮了许多。

3、重构帮助找到bug

对代码的理解，以及搞清楚程序的机构，可以帮助我们找到bug，甚至是一些隐藏的bug。

Kent Beck ： “我不是个伟大的程序员，我只是个有着一些优秀习惯的好程序员。”重构能够帮助我们写出更强健的代码。

4、重构提高编程速度

重构帮助我们快速的开发程序，这一点在上一篇的案例中应该就可以看出，当我们新增影片种类的时候，计费方式也不同的时候，能够快速进行编程，这就是提高速度。 良好的设计是维持软件开发速度的根本，重构可以阻止系统的软件设计腐败变质,从而提高编程速度，理所应当！

三、何时重构

何时进行重构，作者说几乎在任何时刻都反对专门时间进行重构（这里的重构指的是代码级别），重构应该随时随地进行，不应该为了重构而重构。

1、 三次法则

第一次做某件事的时只管去做；第二次做类似的事会感到反感，但无论如何还是去做；第三次再做类似的事，你就应该重构。（事不过三，三则重构）

2、添加功能时重构

最常见的重构就是添加新特性的时候，代码的设计无法帮助我们轻松的添加所需的特性。

3、修改错误时重构

遇到bug，解决bug的时候，可以进行重构。

4、复查代码时重构

代码复查过程发现问题，进行重构！

最常见常用的就是添加功能和修改错误的时候进行重构， 复查代码时重构，这个在很多公司还做不到，没有复查这一个环节。

四、怎么对经理说

作者建议在一般情况下： “最好不要告诉经理！”

很多时候我们的项目开发都是业务驱动，虽然“代码质量”要保证，但是更重要是“开发进度”，不会给太多时间让你进行重构，但是有时候你会发现重构后在添加新的功能会更快，那就在开发进度允许的时间范围进行重构吧！

在实际的项目开发中，开发人员也是有一定的话语权的，坚持自己！

五、重构的难题

重构有好处，也有其局限性，同时也有一些挑战。

1、数据库

重构经常遇到的一个领域就是数据库，程序和数据库结构紧密耦合，难以修改！ 在对象和数据库之间，加入一个分割层，隔离两个模型各自的变化。

2、修改接口

重构的时候如果要修改已经发布接口的要小心。如果有新旧接口，那么尽量让旧接口调用新接口。千万不要复制函数实现，陷入重复代码的泥潭中。

3、难以通过重构手法完成设计改动

在项目中很难将一个 不考虑安全性需求的系统重构成具有良好安全性的系统。

4、何时不重构

（1）有时候根本不应该重构，例如当你应该重新编写所有代码的时候，有时候即有的代码太混乱，重构它还不如重新写一个简单。【这里需要进行评估，很多人接收新项目的时候，不愿意看别人写的代码，任何一个需求过来，都是些自己写一遍，说重构还不如自己写】

（2）如果没有足够的时候，不建议重构，或者早就应该重构。

六、重构与性能

重构可能使软件运行更慢，这一点第一篇的例子可以看出，原本一次的循环，改成了三次。但是重构也使得软件的性能优化更容易。

除非对性能有严格要求的实时系统，其他任何情况下“编写快速的软件” 的秘密是：首先写出可调的软件，然后调整它以求获得足够速度。

总结

书中说：程序有两面的价值

• 今天可以为你做什么？
• 明天可以为你做什么？

大多数的时候，我们只关注了自己今天想要程序做什么， 但是程序明天能够为我们做什么也是相当的重要。

值得去思考，要更加关注程序明天做你什么！