重构代码的目标是什么?它只是为了增强代码结构吗?它是为未来的变化铺平道路吗?
易懂
更简单,组织良好(因素分解)的代码更容易理解.
正确性
通过更易于理解的代码检查来识别缺陷更容易.过于复杂,结构不合理的Rube Goldberg样式代码更难以检查缺陷.此外,具有高一致性组件和组件之间松散耦合的良好组件化代码更容易进行测试.此外,测试中较小的,格式良好的位使得测试用例之间的代码覆盖重叠较少,这使得更快和更可靠的测试(这成为推动更好和更好测试的自我强化循环).同样,更直接的代码往往更具可预测性和可靠性.
易于维护和演变
精心设计,高质量,易于理解的通用组件更易于使用,扩展和维护.现在,系统的许多更改都更容易实现,因为它们的影响较小,而且如何进行适当的更改则更为明显.
重构代码在代码质量和正确性问题方面确实有其自身的优点,但重构代价最高的是软件设计的维护和发展.将新功能添加到旧的,代码性差的代码中通常是一种好的策略,即重构目标代码然后添加新功能.这通常比在没有重构的情况下添加新功能需要更少的开发工作,并且它是一种提高代码库质量的便捷方式,而不需要进行大量的"天空中的馅饼"假设优势重构/重新设计工作很难证明管理层.