关于重构的自问自答

作为一个程序员，已记不清第一次听说重构这个概念是什么时候，只记得读下面这本书的时候我还在学习用C语言开发。

重构——改善既有代码的设计

近几年学习使用Java语言开发，再看时已是这书的译者之一熊节后来单独翻译的一版。作为程序员，无论是C还是Java，无论是在编程演练还是在产品开发中，自以为一直都在践行重构。作为组织的敏捷教练，时常会遇到重构在团队内落地的困难。

熊节在知乎上关于重构的回答
看了译者的解答，还是应付不了自己的一些疑问：

1. 何谓重构？

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

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

从《重构》一书的定义可以重点关注一个词“改变”。然后，看改变的是什么？是内部结构。不改变的又是什么？是可观察行为。其实也就是对边界的定义。
那么现实中我们遇到了新的问题是：边界是否可以再定义？重构是否可以订制？
比如为了切换第三方库、为了降低内存成本、为了提升性能、为了支持新特性？
这就引入了第2个疑问。

2. 为何重构？
   这个问题在定义中也有答案，就是提高可读性，降低修改成本。
   可读性和可维护性看起来比上面说的简单，但是如何才能确保重构是朝着这些方向进展的呢？难免就要综合考虑下面3、4、5、6几个问题。

3. 如何重构？
   如果教条一点的答案就是：遵循重构原则，依照重构手法。
   然而每个人各不相同，无法保证重构的方向、结果和时间与预期吻合。

4. 何时重构？
   以下是和同事常讨论到的重构时机，就不一一解释了：

• 三次法则

• 修复bug

• 扩展功能

• 代码走查

• 注释悖论

• 测试保证（这个是保障条件）

以下是不应该重构的时机：

• 应该重写时
• 期限临近时

我们发现上述这些有的条目并没有清晰的界定，需要个人把握。

5. 何处重构？
   如果说有坏味道的地方就应该重构，那么有很多坏味道的地方呢？
   对有些人来说哪里的代码都可以重构，对另一些人来说哪里都不行。还是很难一概而论。

6. 谁来重构？
   这个问题可以肯定的说，首选是代码的原作者；退而求其次，是代码的守护者；再其次，是具备重构技能的程序员。

到这个问题我突然有了茅塞顿开的感觉：执行重构的程序员才是关键。如果程序员没有意愿重构，那么重构将注定是一场灾难。让我们再回头看看刚才问题的答案：

• Q：重构是否可以定制？
  A：由程序员对边界风险评估结果决定。
• Q：如何把握重构时机？
  A：程序员想要重构的时候。
• Q：何处重构？
  A：程序员觉得应该重构的地方就可以重构。
• Q：如何控制重构过程？
  A：程序员按照个人思路重构，并且可以随时终止。

回到最根本的问题：为何重构？
手工匠人为何要反复雕琢？艺术家为何要精益求精？为了可以卖个好价，或者名垂千古。
那么程序员为何重构呢？如果说把一件事情做好是看在钱的份上，那么把事情做到优秀肯定是与钱无关。
我认为重构是优秀程序员对编码持续追求而养成的个人习惯，代码质量提升只是重构的附属产物罢了。
如果组织层面想要提高代码质量，那就只有一条路可走：选择有优秀品质的程序员，培养、用好、并留住她/他们。