解耦组件的最佳策略是什么[关闭]

Question

我在新公司遇到了遗留代码库的问题。

基本上，他们有 2 个大代码库/项目或程序集，我会说程序集 A 和程序集 B。此外，我们有程序集测试 A 和程序集测试 B。

我在这里遇到的问题是程序集测试 A 正在使用程序集测试 B 中的一些类。程序集测试 B 正在使用程序集测试 A 中的一些类。但没有完成，程序集测试 A 正在使用程序集 B 中的一些类。真的很恶心，我知道。这就是现在技术上的原因，我们有 2 个独立的项目，但实际上我们将它们放在一个包中。那么你可以想象，每次我们部署 A 时，我们都必须部署 B。

我的任务是将这些程序集解耦或将它们拆分为 2 个单独的程序集/项目，以便将来部署和测试等等。

我制定了一个缓慢的策略，但它可以确保我们仍然保证功能。我最初的策略是，我将在测试程序集 A 中慢慢删除程序集 B 的依赖项，并通过测试程序集 A 使测试通过。这意味着我正在从程序集 A 中删除程序集 B 的依赖项。下一步对程序集执行相同的方式B，最后我们将完成 2 个单独的组件。

对我来说，我相信这不是一件容易的事，但我不介意去做。但是，我需要您对我的初始策略提出意见或建议。我不想冒险在那种项目的中间回到起点。

那么你们能否就这项任务给我任何诚实的意见或建议？

我非常感谢。

谢谢

Answer 1

老实说，我觉得描述有点混乱。所以，我会一点一点的来。

基本上，他们有 2 个大型代码库/项目或程序集，我会说程序集 A 和程序集 B。

此外，我们还有组装测试 A 和组装测试 B。

我假设Test A 依赖于A 并且Test B 依赖于B：

测试 A 正在使用程序集测试 B 中的一些类

测试 B 正在使用来自程序集测试 A 的一些类

测试 A 正在使用程序集 B 中的一些类

---

好的，我可以推断出这张图：

• A 和 B 是接收器（如果您愿意，可以离开）。理论上，您可以单独部署它们。我猜你部署Test A 和A 和Test B 和B 会导致问题。快速修复：不要部署测试。

• 有一个循环：Test A -> Test B -> Test A

最初我对Test A -> Test B -> B, Test A -> B 做了一些评论，我正在抓挠，它与这种情况无关。

---

循环依赖Test A -> Test B -> Test A 是主要关注点。如何解决它是一个经济学问题。

我在 cmets 中说您可能允许重复代码，稍后您必须对其进行重构。 这只是我想到的第一件事。 这样做会增加技术债务，但可以让您在更短的时间内归档分离。如果您需要现在分离项目，我会说您这样做。如果有时间，你可以更加务实。

要修复循环依赖，您需要了解Test A 不需要Test B，而Test A 只需要Test B 的子集。同样Test B 只需要Test A 的子集。

此外，我们可以说Test A 和Test B 都需要这个子集。借用Bradley Uffner's comment我会打电话给TestCommon。

您可以从创建一个空的TestCommon 程序集开始，将依赖项添加到Test A 和Test B 并开始在那里移动代码。最终，您将能够删除从 Test A 到 Test B 以及从 Test B 到 Test A 的依赖关系。 TestCommon 内部有可能继续存在循环依赖（没有详细的依赖关系图，我无法判断）。无论如何，提取TestCommon 将使代码更易于维护和重用。

---

提取TestCommon 将导致以下结果：

到这里：

全图：

这更好。现在您可以部署Test B 和B（和TestCommon）而不会出现重大问题。但是，您仍然需要使用 Test A 部署 B，因为它直接引用它。

有一个从Test A 到B 的链接。我将假设更多细微差别的情况，这是Test A 使用 B 的地方（稍后我将探讨其他情况）。按照我们提取TestCommon 的方法，我们需要引入另一个程序集。我会称它为Utility（我不知道里面有什么，只是Test A 需要它），并允许你从这里开始：

到这里：

---

至此，我们已经成功分离项目。我们可以在完整的图表中看到，可以在没有Test B 和B 的情况下部署Test A 和A，反之亦然。

全图：

部署A：

部署 B：

---

¿Utility 是什么？

请记住，Utility 最初是 B 的一部分。这是B 的一部分，我们需要使Test A 工作。虽然我对Utility 了解不多。然而，我知道我不知道的......

A.我不知道Test A 是使用还是测试Utility，我假设它使用它。

B.不知道Test B是使用还是测试Utility

C.不知道B是否需要Utility

让我们探索可能的情况：

1. Test A 使用Utility，Test B 使用Utility，B 需要Utility

   Utility 必须是一些适合性代码，每个人都可以使用它来使事情变得更容易。 Utility 中的缺陷将是两个项目中的缺陷。在新的Test Utility 中对其进行测试。

2. Test A 使用Utility，Test B 使用Utility，B 不需要Utility

   Utility 仅用于测试。合并到TestCommon。

3. Test A 使用Utility，Test B 测试Utility，B 需要Utility

   这是所有情况的更多细微差别......

   B 和 Test A 仍然需要此代码...此代码服务于两个主控器 Test A 和 B。这没有错。你可以保持原样。

   未来您可能希望对其中一个项目的 Utility 进行更改，但该更改会在另一个项目中引入错误。

   目前Utility 的测试在Test B 中，A 的工作人员可能并不担心。因此，将Test Utility 与Test B 分开是一个好主意。

   如果将来Test A 和B 的要求差异太大，他们将需要两种不同的解决方案（此时您可以将它们合并到各自的项目中）。

4. Test A 使用Utility，Test B 测试Utility，B 不需要Utility

   删除B 对Utility 的依赖，并将Utility 的测试从Test B 中分离到一个新的Test Utility 中。

5. Test A testsUtility, Test B 使用Utility, B 需要Utility

   Test A 不应测试来自B 的代码。将该代码迁移到Test B，并将依赖关系从Test A 删除到Utility。您现在可以将Utility 合并回B。

6. Test A 测试Utility，Test B 使用Utility，B 不需要Utility

   删除B 对Utility 的依赖关系，并将Utility 的测试从Test A 中分离到一个新的Test Utility 中。

7. Test A 测试Utility，Test B 测试Utility，B 需要Utility

   Utility 的测试分为两部分。提取它们并将它们放入新的Test Utility。

8. Test A 测试Utility，Test B 测试Utility，B 不需要Utility

   Utility 未被使用。您可以将其连同其测试一起删除。

---

最后说明：我使用yUML 制作了图表。