重构代码需要多长时间_如何随着时间重构整体代码库

重构代码需要多长时间

尽管这么多的软件项目起初都是出于最好的意图，例如干净的体系结构，明确的目标和既定的目标，但并非所有人都可以。 此外，在所有这样做的公司中，并非所有人都能永远保持这种状态。

随着时间，功能要求，财务压力，竞争的优先级以及不断变化的开发人员，最初作为代码质量的光辉典范的最终很有可能最终成为一个整体。

就其本质而言，单片代码库很难维护。 这可能有多种原因，包括以下功能：

• 做得太多。
• 知道太多了。
• 承担太多责任。
• 依赖（或过多依赖）全球状态； 和
• 无法测试。

在这些情况下，如果您更改了某些内容，则通常会更改其他内容（在应用程序中与更改的代码没有明显联系或关联的部分）。

由于这些原因以及许多其他原因，代码变得脆弱，人们通常认为最好的做法是从头开始重写应用程序。 但是，重写通常会导致昂贵的失败。

不知道为什么吗？ 然后问自己几个问题以找出原因：

• 重新创建现有功能级别需要花费多长时间？
• 这是比消除现有申请中的技术债务少或多的时间吗？
• 在这段时间内，您是否可以应对缺乏明显的进步？
• 在重写旧系统时，您是否有资源和时间来修复严重错误和安全错误？
• 一个新系统是否会比现有系统更好，还是会重犯同样的错误？
• 新系统是否具有现有系统的功能？
• 您可以维护两个代码库和两个开发团队吗？
• 您是否会重复从旧系统中学到的教训？

我并不是说重构现有系统始终是最佳选择。 但是，虽然不那么浮华或引人注目，但这通常是成本较低的选择，而方法也更为理智。

话虽如此，我现在将带您逐步了解如何重构整体式代码库的要点。

一：您了解应用程序吗？

在执行任何操作之前，您对应用程序了解多少？ 尽管通常很想深入研究并获得编码 ，但这是最糟糕的事情。 您可以做的最好的事情是学习尽可能多的知识。

如果您的巨石像其他许多巨石一样，那么可能没有单一的，集中组织的知识库。 相反，信息将存储在各种各样的非常不同的位置。 这些可能包括以下内容：

• 在以前的开发人员，企业所有者，经理，项目经理和其他利益相关者的心中
• 代码注释
• 代码提交消息
• 待办事项
• 一个或多个自述文件
• 代码文件
• 一个或多个Wiki
• 错误报告工具

您可以找到尽可能多的此类信息，并将它们整合到一个中央位置 。 在执行此操作时，需要回答以下一系列问题，以帮助您尽可能多地发现问题：

• 为什么创建该应用程序？
• 谁想要建造它？
• 谁做的？
• 这意味着做什么？
• 它的主要特点是什么？
• 它有哪些附加功能？
• 它的主要错误是什么？
• 它的补充错误是什么？

希望这份清单能激发您提出一系列后续问题，使您能够了解所有要了解的内容。

二：是否受版本控制？

了解所获取的应用程序后，询问其源代码是否存储在版本控制下。 如果没有，那么就直接在版本控制下获得它！ 您要做的最后一件事是进行任何更改，而无法还原它们。

我强烈建议您使用Git，但如果您不喜欢Git，Mercurial是另一个绝佳选择。 我也鼓励您也将其存储在远程存储库中，无论是GitHub，Bitbucket，GitLab还是其他众多代码托管服务之一。

三：测试套件的状态是什么？

接下来，什么级别的代码覆盖率到位？ 根据应用程序的年龄，从事该应用程序的开发人员的数量（以及他们的技能水平），这些开发人员的使用方式等，可能没有适当的代码测试套件。

在这种情况下，您将必须先放置一个基本的测试套件， 然后才能开始。 否则，您将永远无法确定所做更改的影响。 如果代码覆盖范围已经到位，请问自己以下问题：

• 可以提供什么级别的保险？
• 测试套件需要多长时间才能完成？
• 他们完成还是耗尽了可用的内存？
• 有多少测试失败？
• 跳过多少测试？
• 多少测试已过期？
• 单元测试，集成测试和功能测试是否混合在一起？
• 代码库中是否有没有测试的部分？
• 是否有诸如Quick Hack之类的注释在以后修复 ？
• 是否有诸如“请勿触摸”之类的评论！ ？
• 测试中有哪些评论？
• 测试套件是否在启用完整错误报告的情况下运行？

如果做得好，测试套件应该可以帮助您比直接进入每个类文件更快地了解代码的工作方式。 花时间阅读并彻底理解测试。

四：进行了哪些静态分析？

既然您已经了解了有关该应用程序的更多信息并掌握了测试范围，是否使用了静态代码分析？ 如果您不熟悉它，则静态代码分析为：

…对没有实际执行程序的情况下执行的计算机软件的分析。 在大多数情况下，对某些版本的源代码执行分析，而在其他情况下，对某种形式的目标代码执行分析。

通过定期在代码上运行静态代码分析器（例如Phan） ，可以帮助确保代码质量提高而不是下降。 您还可以将错误的来源追溯到引入它们的特定提交。

如果您的代码尚未使用，则可以使用许多第三方软件包和在线服务，而与您的软件语言无关。 这些包括：

• 皮林特
• 潘
• 入侵防御系统
• 夹板
• 声纳
• 缺陷查找器 ; 和
• 编纂

五：开始重构

既然您的团队掌握了尽可能多的信息，是时候开始重构应用程序了。 为了正确执行操作，让我们讨论一下我最近遇到的一些明智建议：

没有完美的设计，只有更好的设计

要知道，即使有可能，您的代码也永远不会是完美的。 重构将帮助您不断改进它，使它比以前更简单，更具可读性，更可维护且更具可测试性，但任务永无止境。

您可能总是觉得自己可以做得更好，但是有时您不得不接受这一点，至少暂时如此。

在这一点上，您必须自律离开它并继续前进。 不要陷入“只是使其变得更好”的陷阱。 你已经改善了。 比以前好。 随它去吧。

清理复杂代码库的关键原则是始终在功能服务中进行重构

如果进行的更改是微不足道的或出于美观目的，那么重构可能会带来负面的印象。 但是，有时这种重构是必要的，并且随着时间的推移，这种重构有助于确保代码库的质量更好。

但是，如果仅此而已，则该值值得怀疑。 相反，首先要确保所做的更改是为了明确有效的目的。 其中可能包括创建新功能或修复突出的错误或缺陷。

六：制定重构项目计划

现在您已经完全了解了应用程序的工作原理，是时候开始重构它了。 但是，您必须有一个计划！ 这样的计划有什么内容？ Mozilla的这次演讲提出了五个主要注意事项：

1. 分成一系列可完成的任务。
2. 提出切实可行的时间表和资源要求。
3. 孤立地工作或与其他项目并行地工作。
4. 认真对待它。
5. 如果并行工作，请考虑依赖性。

七：实现机会重构的习惯

接下来，鼓励您的团队养成机会重构的习惯。 如果您还没有听说过这个词， 那是Martin Fowler创造的 。 这是他的描述方式：

每当有人看到一些不尽如人意的代码时，他们应该趁此机会就此进行修复，至少在几分钟之内。 Bob叔叔称这种机会主义重构遵循童子军规则–始终使代码处于比您发现的状态更好的状态。

尽管不是灵丹妙药，但通过进行这些常规的少量清理，代码的质量应该始终得到提高，并且不必将sprint专用于代码清理，因为它将一直处于改进状态。

八：使用专用的重构工具

重构的优点之一是您不需要特定的工具即可进行重构。 正如马丁·福勒（Martin Fowler）所说，这是因为，如果您“采取小步骤并经常进行测试”，那么您应该没事。 就是说，手动重构将是一个较慢的过程，并且需要更多的努力，但是仍然可以实现。

但是，如果您已经具有重构的经验，为什么不节省自己的时间和精力，而使用主要IDE和文本编辑器内置或可用的工具呢？ 但是，无论您采用哪种方法，都请记住慢慢进行测试， 测试和测试 。

另外，在进行每次更改时，请检查测试套件。 需要新的测试吗？ 您是否发现系统另一部分中与您正在处理的内容有关的错误？ 然后为其添加一个或多个测试。 您现有的某些测试不再相关吗？ 然后将其删除。 始终确保您的测试套件保持最新状态。

从这里到哪里？

尽管本文并没有对重构的细节进行过深入的探讨，但它显示了一系列八个原则，您可以遵循它们遵循正确的方法来完成任务。 从头开始重写您的应用程序可能很诱人，但是我提醒您慢慢地得出结论。

是的，这是新潮的解决方案，但并非总是正确的解决方案。 花点时间，了解您的应用程序，确保首先值得这样做，如果您认为正确，那么就这样做。

否则，请按照我提供的建议进行操作，并充分利用该应用程序的宝库，保持服务的连续性，并一次消除一行技术债务。

翻译自: https://www.javacodegeeks.com/2018/04/how-to-refactor-a-monolithic-codebase-over-time.html

重构代码需要多长时间