这不是一篇谈论重构技巧的文章，它要谈的是我感悟和信奉的重构基本原则，在某些时候，它能帮助你拨开层层的代码迷雾。
开始前的准备
作为一名教练，被指派去支持、指导一些团队的代码重构是家常便饭，在这过程中我会接触到形形色色的开发人员和开发团队。每一次的经历都不一样，既碰上过意气相投也遭遇过抵触，起初我很少去想为何会被人抵触，直到有一次重构时被要求“只添加测试，不要修改原代码，即使可能写的不好，除非是那些真看不过去的”时才触动了我的思考。
它提醒了我一件容易被遗忘却又十分重要的事：要尊重别人的劳动成果，在过去的很长时间里这一点都是被我忽略的。之前我多多少少都会带着点居高临下的意味去找到研发人员或团队，因为在我看来既然请我来指导重构就一定是现在的工作状态有问题。一旦有了这种想法，对外部状态的观察就会觉得哪里都有问题，例如对遗留代码会产生一种到处都有“臭味”的错觉。
这种不认同的偏执会导致无法认真地理解代码，忽视他人代码中的闪光点，而是一味粗暴地涂抹别人的代码，时间长了就会陷入越改问题越多的泥淖（因为你看哪里都是问题）中去，更有被团队成员抵触的危险。如此恶性循环，最终的结局大概率是任务失败，更糟糕的是惹怒了整个团队。造成这种局面的原因就是完全凌驾于别人之上彻底旁路了团队，并且残忍地否定了团队之前的成果。所以先给自己心里留一条红线，时刻提醒自己：
无论现在的结果如何，都要坚信这是当时情况下能够获得的最好结果
当真正地开始尊重代码所有的人和团队后，得到将是对方的诚心参与，他们会帮你去了解代码，去承认他们犯过的错误，去修正他们自己的过失，在最后重构结束的时候，回顾整个过程，研发人员和团队就会惊奇地发现所有的改进都是来自于自己的努力，这才是最好的结果。
实施时策略
纸上得来终觉浅，绝知此事要躬行 —— 陆游 《冬夜读书示子聿》
测试是件很有意思的事，有意思是因为这件事看上去很简单，但操作起来却很不容易。任何一个参加过几次测试用例培训或是看过几本讲述测试书籍的人都会讲出好些有关测试的条条框框来，但事情有时候就是这样，越是看起来简单的事，越是不容易做好，尤其是面对遗留代码的时候。
为何遗留代码做测试不容易，因为首先要会意。会意是个沟通过程，包括与代码沟通、与维护人和团队沟通，并且后者比前者更重要。我很幸运，所有经历的重构中代码的原作者都还尚在团队因而沟通成本大大降低，但如何遇到了那种原作者离开团队或者代码从别处转交过来的情况，那就需要花更多的时间和精力去沟通，最好的情况其实是你立刻停止重构，因为这样的重构失败的可能性远远地超过了成功。
会意的“意”是关键，刚开始先不要急于去添加测试，最好是先坐下来为原作者泡杯茶，请他(她)讲解下代码的流程。先从作者的角度去看代码，了解作者的意图并多问问为什么，让自己成为他(她)的徒弟，先别在意细节。接下来沿着作者的思路去试着切割代码，想办法把代码分成几个大块功能，同时记录下来再向作者确认。在确认的过程中，逐步修正自己的想法达到与作者尽可能的统一。
有了按作者意图切割的大块功能，就可以检查下哪些功能块是可测试的。先从可测试的入手，重复上面的会意过程，仍然是切割，切割的是边界，边界将是测试的参考点，沟通仍然所有过程的重点。
当完成会意之后就可以开始测试了，不过在这之前还有两件重要的事情要做：
- 建立版本控制
- 请作者和你一起
为了保证不破环原有代码的特性，必须先建立安全网也算给自己留条后路。千万别觉得麻烦，在很多时候它可以挽救你。
让作者和你坐到一起添加测试就发现很多时候作者会比你快一步给出测试的构造，特别是当他(她)在了解了测试的过程之后，甚至很快你就可以在一旁看着作者自己添加测试，而只是在必要的时候给他(她)一点有关边界场景的提醒，这就是为何我要坚持让作者和我坐到一起添加测试。
作者通过引导和观摩会了解到测试不是一件特别高深的事物，如果掌握了一定的技巧实施的难度会很快下降。实际上大多数时候遗留代码没有测试是因为开发人员对测试存在误解，认为测试复杂不易掌握且浪费时间。
让作者和你坐到一起添加测试的另一个重要原因是当你真的不得不修改原代码时，获得作者对修改代码的肯定是件十分重要的事，没什么比建立信任更重要了。
结语
我所感悟到的重构原则就只有两条：
- 尊重他人的劳动成果，这是一切的前提
- 充分沟通，协调一致，不要把它当成自己的负担
这远比重构的技巧要重要，没有它们，可能你连展示你那精妙、优雅、独步天下的重构技巧的机会都不会有，因为你早已十分彻底地把自己站到了你要服务对象的对面去了。
