重构的目标?[闭门]

更直观、组织良好(考虑因素)的代码更容易理解。

正确性

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

易于维护和升级

功能完善、质量高、易于理解的通用组件更易于使用、扩展和维护。对系统的许多更改现在更容易进行,因为它们的影响更小,而且更明显的是如何进行适当的更改。

就代码质量和正确性问题而言,重构代码本身确实有其优点,但重构带来最大回报的是软件设计的维护和改进。在将新特性添加到旧的、分解不好的代码中时,通常一个好策略是重构目标代码,然后添加新特性。这通常比在不重构的情况下添加新特性所需的开发工作要少,而且这是一种提高代码库质量的简便方法,而无需进行大量“天上掉馅饼”的假设优势重构/重新设计工作,这很难向管理层证明。

重构是用来支付你的成本的 Technical Debt

1. 消除/减少“代码气味”
2. 任何开发人员都更容易理解代码
4. 增加内聚力和减少耦合”

在一个非常基本的层面上,目标是改进代码,使其更可读、更少耦合、降低错误率等等。

代码重构是观察变化不可避免这一事实的必要条件。它的主要目标是增强当前的代码或设计,使其符合新的功能性或非功能性需求,或使其更能容忍更改。

1. 引入新的业务规则,要求将当前设计抽象到新的层次;
2. 认识到可以修改当前设计,以便更好地观察 SOLID
3. 当需要增加代码的可测试性时——这与上面的2有关。

重构的目标?

逾越节?

说真的,我这样做是为了:

• 当我看到它时避免代码重复(如下所示 DRY (原则)
• 简化代码(删除不必要的特殊复杂性,请参阅 KISS )
• 消除副作用

• 降低单个功能的复杂性-使测试更容易
• 消除重复代码—减少出错的机会

• 提高代码可读性
• 简化代码结构
• 提高可扩展性

开始重构的原因通常取决于您遇到的问题。

现在,如果您改进文档、代码的可读性和代码的结构,您也将获得更好的可维护性。。。

当然,当您确信永远不必再碰一段代码时,就没有必要重构该代码。

但大多数时候,你必须再次触摸它,因为你必须添加功能、修复bug或优化它。

降低变革的成本。

一般来说,我只会重构生产代码以重用它,或者在需要修改时进行重构。

例如,出于性能原因,我需要更新一个函数,但没有一个简单的测试接口,因此我将其重构为一个单独的模块,该模块可以更容易地进行单元测试,然后进行更改,以便重新运行测试,并显示它与以前一样工作。

重构不需要更改的代码会导致灾难;它肯定会引入bug。

对我来说: 表演

简言之去臭代码。