重构的目标？

Question

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

Answer 1

<强>可理解

更直接，组织良好（因素分解）的代码更容易理解。

<强>正确性

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

易于维护和进化

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

---

重构代码在代码质量和正确性问题方面确实有其自身的优点，但重构代价最高的是软件设计的维护和发展。将新功能添加到旧的，代码性差的代码中通常是一种好的策略，即重构目标代码然后添加新功能。这通常比在没有重构的情况下添加新功能需要更少的开发工作，并且它是一种提高代码库质量的便捷方式，而不需要进行大量的“天空中的馅饼”假设优势重构/重新设计工作很难证明管理层。

Answer 2

重构用于支付Technical Debt。

Answer 3

1. 消除/减少“Code Smells”
2. 任何开发人员都更容易理解代码
3. 使其可维护。
4. 增加凝聚力并减少耦合“

Answer 4

我通常不会重构代码只是为了减少代码味道，或者让它更好/更易于维护。当我需要修复bug时，我会进行重构，并且我想让代码保持比以前更好的形状。其他原因是当我想添加功能时，没有重构就很难做到。第三个原因是使代码更易于测试。有时我会重构学习我不理解的代码： - ）

Answer 5

在最基本的层面上，目标是改进代码，使其更具可读性，更少耦合，降低错误率等等。

另一方面，重构是BigUpfrontDesign的替代品。此外，当在极限编程等环境中使用时，重构也是一种责任。您每天，每小时支付技术部门的抵押贷款。与集体代码所有权原则一起，它还使每个人负责在任何地方重构代码，而不仅仅是自己编写（或共同编写）的代码。

Answer 6

代码重构是观察变化不可避免的事实的必要条件。它的主要目标是增强当前的代码或设计，以使其适应新的功能或非功能需求，或使其更容忍变化。

可能需要重构的场景示例：

1. 引入新业务规则，要求将当前设计抽象到新的水平;
2. 认识到可以修改当前设计以更好地遵守面向对象设计的SOLID原则这一事实;
3. 当需要增加代码可测试性时 - 这与上面的2相关。

Answer 7

  

重构的目标？

Passtime？

说真的，我这样做：

• 在我看到它时避免代码重复（遵循DRY原则）
• 简化代码（删除不必要的临时复杂性，请参阅KISS）
• 删除旧/陈旧/弃用的代码（清除废弃物，更换旧代码后）
• 消除副作用
• 概括和重用现有代码

Answer 8

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

Answer 9

重构可以有多重激励：

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

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

如果您扩展软件并偶然发现错误而无法找到错误的来源，那么您可能会开始重构以简化代码结构，以便开发人员更容易追踪错误。

有时错误来自一个函数/类/ ...，它的使用方式并不像预期的那样。这表明代码不易理解或记录错误。

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

Answer 10

当然，当您确定永远不会再触及一段代码时，就没有必要重构该代码。

但大多数情况下，您必须再次触摸它，因为您必须添加功能，修复错误或对其进行优化。

所以，是的，当然是为未来的变化铺平道路。代码总是在变化。

Answer 11

降低变更成本。

Answer 12

一般来说，我只重构生产代码以重复使用它或需要修改时。

例如，出于性能原因我需要更新一个函数，但是没有一个简单的测试界面，所以我将它重构为一个单独的模块，可以更容易地进行单元测试，然后进行更改，这样我就可以重新运行测试并显示它像以前一样工作。

重构不需要更改的代码是灾难的秘诀;它保证会引入错误。

Answer 13

<强>组织。

Answer 14

对我来说：效果。

Answer 15

简而言之......要解密代码。