本文翻译自"Before You Refactor"，来自于《97 Things Every Programmer Should Know》一书中的某个章节。

在某些时候，每个程序员都需要重构现有的代码。不过在你动手之前，请考虑一下下面的内容，因为这可以节省你和他人的大量时间（以及痛苦）。

· 重构开始的最好方式就是对现有代码库及其测试代码进行总结和评估。

这将帮助你理解现有代码的优点和不足，你也可以确保将优点保留住并避免错误。我们总是认为自己做的可以比现有系统更好…直到最终我们没能拿出更好的系统，甚至做得比系统的前身更糟，因为我们没有从现有系统的错误中汲取教训。

· 抵御重写一切的诱惑

最好尽可能多地重用现有代码。无论这些代码有多么丑陋，它们毕竟是经过评审和测试过的。扔掉旧代码，特别是那些运行在生产环境中的代码，意味着你扔掉了经过数月（或者数年）测试且久经沙场的代码，或许这些代码中还包含了一些你所不知道的特定的应对方案和Bugfix。如果你没有考虑到这些，你写的新代码最终就会出现出同样诡秘的bugs，而这些Bug在旧代码中都已经被Fixed了。这将浪费大量时间、精力以及多年来积累的知识。

· 多次增量改变优于一次巨大改变

增量改变可以让你更容易地通过诸如测试等反馈来评估对系统的影响。做出一次改变就导致上百个测试失败，这可不是什么好玩的事。这可能让你更加沮丧，压力更大，并会相应地导致错误的决策。三两个测试失败容易对付，并且也容易管理。

· 每次迭代后，确保现有的测试通过

如果现有的测试无法覆盖你所做出的改动，那就增加测试。不要不经思考就扔掉针对旧代码的测试。表面上其中的一些测试似乎不适合你新设计了，不过深入分析这个特殊的测试被添加进来原因是非常值得的。

· 个人喜好和自大不应该成为障碍  

如果东西没有损坏，为什么要去修正它呢？ 代码风格或结构不满足你的个人喜好，这不是一个重构的正当理由。认为你会做的比之前的程序员更好同样也不是一个正当理由。

· 新技术不足以成为重构的理由 

因为当前的代码落后于今天所有时髦的新技术，并且相信一门新语言或一个新框架可以使代码更优雅，这些都是最糟糕的重构理由。除非成本效益分析表明一门语言或一个框架将在功能性、可维护性以及生产力方面带来显著的提升，否则最好不要理会它。

· 请记住：人会犯错误 

重构并不总是保证新代码一定就更好，或者与以前的代码一样好。我看过并且亲身参与过许多次失败的重构尝试。漂亮并没有错，犯错的是人。

By Rajith Attapattu

也许你经常遇到这类情况：你在代码里使用了别人提供的第三方库，当库升级为新版本后，你的代码在编译时无法通过，提示接口原型错误，经查发现原来是该第三方库提供的某接口的原型发生了变化，比如原接口被删除、增加了参数、参数减少了、修改了参数类型以及返回类型发生变化了等等。你也许会不由自主的大骂一句：F**k。

我们换位思考一下，假如你是某个库的Owner，当你遇到需要修改接口原型的情形时，你应该如何去做呢？这里考量出一些方法供参考：

1、谨慎评估：是否一定非得修改接口原型这么做，是否有其他办法解决此问题，毕竟修改接口原型涉及改造面太大了；

2、退而求次，另立新接口，并告知调用者本库的那个老接口已经被标识为obsoleted了。以后就不要用再用该接口了，而是直接用新的吧；

3、如果实在迫于无奈，只能变更接口原型才能达到目的，那么也要小心驶得万年船：考虑到你的客户，小心翼翼地规划库版本，可将那些无需变更接口的需求放入小版本中，支持快速发布，满足调用者需求；而那些只能通过变更接口才能实现的需求，可考虑都汇总到后续发布的某个较大版本的分支中，这样发布间隔变长，也在一定程度上降低了调用者为适应新库而进行修改的频度。

其实我们很是希望在进行库设计时，一旦接口原型敲定，就再也无需变化。但现实是残酷的，变化是永恒的。我们只能更加关注和完善前期设计，尽量减少而却无法避免接口原型变更的可能。