【译】重构之前

每一个程序员有时候都需要重构已有代码。但在这么做之前，先思考一下下面这些事情，这可以节省你和其他人大量的时间（和苦恼）：

• 开始重构的最佳方式是了解现有代码库并针对这些代码编写测试。这有助于你了解这些代码目前的优点和弱点。这样你就可以在避免错误的同时保留写得好的部分。我们都认为我们能够做的比现有系统好…直到最后，由于我们没有从现有系统的错误中吸取教训，导致相比之前没有什么提升，甚至更糟。
• 避免重写的诱惑。最好的方式是尽可能的重用，无论多么丑的代码，至少它经过了测试、审查等等。抛弃现有代码，尤其是在现有产品中的代码，意味着抛弃几个月（可能是数年）的测试，久经沙场的代码可能包含一些你不知道的临时方案和 bug 修复。如果你没有考虑到这些，你新写的代码可能就会重现那些在旧代码中已经修复的离奇问题。这将浪费多年来所花费的大量时间，精力和收获的知识。
• 大量的迭代更新比一次巨大的改动更好。增量更新可以通过反馈更轻松地衡量对系统的影响，比如通过测试。当你修改了某处后，看见数百个测试失败，这一点也不好玩。可能让你很有压力并且感觉很糟糕，可能导致做出更糟糕的决策。少量的测试失败比较容易处理，而且有很多处理的办法。
• 在每次迭代后，确保现有测试都通过很重要。如果现有测试不够覆盖你的改动，就补充新的测试。千万不要轻易删掉旧的测试代码。表面上看这些测试似乎对你的新设计没什么用，但是深入地挖掘为什么要添加这些测试很有价值。
• 不应该带入个人偏好和一些主观的内容。如果这些代码没有问题，干嘛要动它？代码风格或结构不符合你的偏好，这不是一个好的重构理由。自认为你可能比之前的人做的更好也不是一个正当的理由。
• 新技术不是一个充分的重构理由。一个糟糕的重构理由是，因为现有代码还没有使用当前最酷的技术，而且认为新的语言或框架可以做的更优雅。除非有成本-效益分析显示新语言或框架，在功能性、可维护性和生产效率上有显著提升，否则最好保持原样。
• 切记，是人都会犯错误。重构不能保证新代码总会更好，甚至不如以前。我见过也亲身经历过几次失败的重构。它不完美，但人力可为。

原文：Before You Refactor · 97 Things Every Programmer Should Know