作为一个程序员，已记不清第一次听说重构这个概念是什么时候，只记得读下面这本书的时候我还在学习用C语言开发。
近几年学习使用Java语言开发，再看时已是这书的译者之一熊节后来单独翻译的一版。作为程序员，无论是C还是Java，无论是在编程演练还是在产品开发中，自以为一直都在践行重构。作为组织的敏捷教练，时常会遇到重构在团队内落地的困难。
熊节在知乎上关于重构的回答
看了译者的解答，还是应付不了自己的一些疑问：
- 何谓重构？
重构（名词）：对软件内部结构的一种调整，目的是在不改变软件可观察行为的前提下，提高其可理解性，降低其修改成本。
重构（动词）：使用一系列重构手法，在不改变软件可观察行为的前提下，调整其结构。
从《重构》一书的定义可以重点关注一个词“改变”。然后，看改变的是什么？是内部结构。不改变的又是什么？是可观察行为。其实也就是对边界的定义。
那么现实中我们遇到了新的问题是：边界是否可以再定义？重构是否可以订制？
比如为了切换第三方库、为了降低内存成本、为了提升性能、为了支持新特性？
这就引入了第2个疑问。
为何重构？
这个问题在定义中也有答案，就是提高可读性，降低修改成本。
可读性和可维护性看起来比上面说的简单，但是如何才能确保重构是朝着这些方向进展的呢？难免就要综合考虑下面3、4、5、6几个问题。如何重构？
如果教条一点的答案就是：遵循重构原则，依照重构手法。
然而每个人各不相同，无法保证重构的方向、结果和时间与预期吻合。何时重构？
以下是和同事常讨论到的重构时机，就不一一解释了：
三次法则
修复bug
扩展功能
代码走查
注释悖论
测试保证（这个是保障条件）
以下是不应该重构的时机：
- 应该重写时
- 期限临近时
我们发现上述这些有的条目并没有清晰的界定，需要个人把握。
何处重构？
如果说有坏味道的地方就应该重构，那么有很多坏味道的地方呢？
对有些人来说哪里的代码都可以重构，对另一些人来说哪里都不行。还是很难一概而论。谁来重构？
这个问题可以肯定的说，首选是代码的原作者；退而求其次，是代码的守护者；再其次，是具备重构技能的程序员。
到这个问题我突然有了茅塞顿开的感觉：执行重构的程序员才是关键。如果程序员没有意愿重构，那么重构将注定是一场灾难。让我们再回头看看刚才问题的答案：
- Q：重构是否可以定制？
A：由程序员对边界风险评估结果决定。 - Q：如何把握重构时机？
A：程序员想要重构的时候。 - Q：何处重构？
A：程序员觉得应该重构的地方就可以重构。 - Q：如何控制重构过程？
A：程序员按照个人思路重构，并且可以随时终止。
回到最根本的问题：为何重构？
手工匠人为何要反复雕琢？艺术家为何要精益求精？为了可以卖个好价，或者名垂千古。
那么程序员为何重构呢？如果说把一件事情做好是看在钱的份上，那么把事情做到优秀肯定是与钱无关。
我认为重构是优秀程序员对编码持续追求而养成的个人习惯，代码质量提升只是重构的附属产物罢了。
如果组织层面想要提高代码质量，那就只有一条路可走：选择有优秀品质的程序员，培养、用好、并留住她/他们。
