重构的目标? [英] Goals of refactoring?

问题描述

重构代码的目标是什么?仅仅是为了增强代码结构吗?是否为未来的变化铺平了道路?

What are the goals of refactoring code? Is it only to enhance the code structure? Is it to pave the way for future changes?

推荐答案

可理解性

更直接和组织良好(分解)的代码更容易理解.

More straightforward and well organized (factored) code is easier to understand.

正确性

通过检查更易于理解的代码来更容易地识别缺陷.过于复杂、结构不佳的 Rube Goldberg 风格代码更难以检查缺陷.此外，具有组件高度一致性和组件之间松散耦合的良好组件化代码更容易进行测试.此外，更小的、格式良好的被测位减少了测试用例之间代码覆盖率的重叠，这使得测试更快、更可靠(这成为一个自我强化的循环，推动越来越好的测试).同样，更直接的代码往往更可预测和更可靠.

It's easier to identify defects by inspection in code that's easier to understand. Overly complex, poorly structured, Rube Goldberg style code is much more difficult to inspect for defects. Additionally, well componentized code with high coherency of components and loose coupling between components is vastly easier to put under test. Moreover, smaller, well-formed bits under test makes for less overlap in code coverage between test cases which makes for faster and more trustworthy tests (which becomes a self-reinforcing cycle driving toward better and better tests). As well, more straightforward code tends to be more predictable and reliable.

易于维护和改进

精心设计、高质量、易于理解的通用组件更易于使用、扩展和维护.对系统的许多更改现在更容易进行，因为它们的影响更小，而且如何进行适当的更改也更加明显.

Well-factored, high quality, easy to understand common components are easier to use, extend, and maintain. Many changes to the system are now easier to make because they have smaller impact and it's more obvious how to make the appropriate changes.

就代码质量和正确性问题而言，重构代码确实有其自身的优点，但重构最有价值的地方在于软件设计的维护和演变.在向旧的、分解不良的代码中添加新功能时，一个好的策略通常是重构目标代码，然后添加新功能.与尝试在不重构的情况下添加新功能相比，这通常会花费更少的开发工作，并且这是一种提高代码库质量的便捷方法，而无需进行大量天上掉馅饼"的假设优势重构/重新设计工作，这些工作很难证明是合理的到管理层.

Refactoring code does have merit on its own just in terms of code quality and correctness issues, but where refactoring pays off the most is in maintenance and evolution of the design of the software. Often a good tactic when adding new features to old, poorly factored code is to refactor the target code then add the new feature. This often will take less development effort than trying to add the new feature without refactoring and it's a handy way to improve the quality of the code base without undertaking a lot of "pie in the sky" hypothetical advantage refactoring / redesign work that's hard to justify to management.

这篇关于重构的目标?的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！