就目前而言，这个问题不适合我们的问答形式。我们希望答案得到事实、引用或专业知识的支持，但这个问题可能会引起辩论、争论、投票或扩展讨论。如果您觉得这个问题可以改进并可能重新打开，visit the help center为指导。
8年前关闭。
重构代码的目标是什么？仅仅是为了增强代码结构吗？是为 future 的变化铺平道路吗？
最佳答案
易懂性
更直接和组织良好(分解)的代码更容易理解。
正确性
通过检查更易于理解的代码更容易识别缺陷。过于复杂、结构不佳的 Rube Goldberg 风格代码更难以检查缺陷。此外，具有组件高度一致性和组件之间松散耦合的良好组件化代码更容易进行测试。此外，更小的、格式良好的被测位减少了测试用例之间代码覆盖的重叠，这使得测试更快、更可靠(这成为一个自我强化的循环，插入越来越好的测试)。同样，更直接的代码往往更可预测和更可靠。
易于维护和演进
精心设计、高质量、易于理解的通用组件更易于使用、扩展和维护。对系统的许多更改现在更容易进行，因为它们的影响更小，而且如何进行适当的更改更加明显。
就代码质量和正确性问题而言，重构代码确实有其自身的优点，但重构最有值(value)的地方在于软件设计的维护和演变。向旧的、分解不良的代码添加新功能时，通常一个好的策略是重构目标代码，然后添加新功能。与尝试在不重构的情况下添加新功能相比，这通常会花费更少的开发工作，并且这是一种提高代码库质量的便捷方法，而无需进行大量“天上掉馅饼”的假设优势重构/重新设计工作，这些工作很难证明是合理的到管理。
关于refactoring - 重构的目标？，我们在Stack Overflow上找到一个类似的问题： https://stackoverflow.com/questions/498651/