重组项目以进行扩展/重用

Question

我正在进行的项目的范围正在扩大。该应用程序相当简单，但目前针对的是非常具体的利基市场。在不久的将来，我被要求分叉该项目以瞄准新市场，并继续同时开发这两个项目。

这两个项目在功能上是相似的，因此有很强的动机去推广许多项目 胆量 原始项目的。此外，我确信我将在不久的将来瞄准更多市场（市场是地域性的）。

问题是该项目的先前维护者做出了很多假设，将其与原始市场联系起来。将通用代码与市场特定代码分开需要进行大量重构。

为了使事情变得更加复杂，关于如何为不断增长的市场组织项目提出了一些建议：

1. 每个市场都是一个单独的项目，项目之间的共性被移至共享库，项目独立部署。
2. 扩展现有项目以瞄准多个市场，根据购买的许可证限制功能。
3. 创建父应用程序并将项目重新设计为插件，需单独购买

所有这三个建议都有优点，理想情况下，我希望将代码构造得足够灵活，以便通过微小的调整就可以实现其中任何一个。建议 3 似乎是最令人畏惧的，因为它需要构建一个插件架构。前两个建议似乎更合理一些。

有没有关于这些不同架构的优缺点的好资源？

与复制和分叉相比，在项目之间共享代码有哪些优点和缺点？

Answer 1

分叉通常在一开始会给你带来更快的结果，但几乎总是会在维护中困扰你——一个分叉的错误修复和功能增强会在其他分叉中丢失，最终你发现自己扔掉了整个分叉并且必须将它们的功能重新添加到“最佳”分叉中。如果可以的话避免它。

继续：所有三个选项都可以工作，但它们在构建复杂性、维护成本、部署、通信开销和需要进行的重构量方面需要权衡。

---

1.每个市场都是一个单独的项目

如果您要同时针对多个市场进行开发，这是一个很好的解决方案。

优点：

• 它允许市场 A 的开发人员打破 A 构建，而不会干扰 B 市场正在进行的工作
• 这使得市场 A 所做的更改不太可能导致市场 B 出现错误

缺点：

• 您必须花时间分离出共享代码
• 您必须花时间设置并行构建
• 现在，对共享代码的修改会产生更多开销，因为它们会影响两个团队。

2.扩展现有项目以瞄准多个市场

可以使其正常工作相当长一段时间。如果您打算与一个小团队一次针对一个市场进行发布，那么这可能是您最好的选择。

优点：

• 无论如何，许可工作可能很有价值，即使您转向 (1) 或 (3)。
• 单一代码库允许跨所有市场进行重构。

缺点：

• 即使您只是在为市场 A 开发一些东西，您也必须为市场 B、C 和 D 构建并发布代码——如果您的代码库很小，那还可以，但是当您的代码库数以千计时，这会变得越来越烦人。类
• 一个市场的变化可能会破坏其他市场的规则
• 一个市场的变化需要重新测试其他市场

3.创建父应用程序并将项目重新设计为插件

技术上感觉很不错，并且可以让您共享更多代码。

优点：

• (1) 的所有优点，可能还有：
  • 更清晰地分离共享代码和特定于市场的代码
  • 可能允许您转向公共 API，这将允许您将一些工作转移给您的客户和/或销售利润丰厚的服务项目

缺点：

• (1) 的所有缺点，加上需要更多的重构。

---

我猜想，除了许可之外，您现在所处的位置就是（2）。我认为在那里停留一段时间是可以的，但是要努力朝着（1）迈进——将共享代码移到一个单独的项目中，即使它们是一起构建的，例如，试图确保来自市场的依赖关系代码到共享代码都是单向的。

你最终是处于（1）还是（3）取决于。大多数情况下，这取决于谁“负责”——共享代码，还是特定于市场的代码？插件和配置某些共享组件的控制器类之间的界限可能非常模糊。我的建议是，让代码告诉你它需要什么。

Answer 2

1）不！您不想管理同一代码库的不同分支......因为尽管代码可能很常见，但您会想要进行彻底的更改，并且一个项目“目前”不会像其他项目那么重要，然后您将得到一个分支比其他分支增长得更快......插入雪球。

2）这或多或少是行业标准。大配置文件，根据许可证/配置限制事物。它可能会使应用程序有点麻烦，但只要代码抱怨相互排斥的东西，并且所有开发人员都在不断地沟通新功能以及它们如何在整个应用程序中产生影响，那么您应该做得很好。如果这是一个问题的话，这也是最容易被黑客攻击的。

3）这也“可以”工作。如果你使用C#，插件相对简单，你只需要担心依赖地狱。如果插件有机会变得循环相互依赖（即，a 需要 b 需要 c 需要 a），那么这将很快爆炸，您将（很容易）恢复到#2。

你拥有的最好的资源可能是你的同事过去在不同项目上的经历，以及人们在这里或 Slashdot 或其他地方抱怨的经历。当然是最便宜的。

共享代码的优点：一项改变改变一切。统一数据模型。只有一个真理。（每个人都更容易在同一页面上）

共享代码的缺​​点：一个改变改变一切..当心。如果其中存在一个错误，就会影响一切。

复制/分叉的优点：通常可以更快地为特定客户实施特定功能。当您意识到假设 A 仅适用于市场 B 和 C，而不适用于 D 时，破解速度会更快。

复制/分叉的缺点：由于代码缺乏内聚力，一个或多个复制的项目最终将失败。正如上面所说：彻底的改变需要更长的时间。

祝你好运。

Answer 3

你说“复制和分叉”，这让我想到也许你没有考虑过将这个“分叉”作为像 SVN 这样的版本控制系统中的一个分支来管理。通过这种方式，当您重构分支以适应不同的行业时，您可以借助修订控制系统将这些更改合并回主干。

如果您遵循迁移到单个应用程序的长期策略，其中所有变体都由配置文件（或 SQLITE 配置数据库）控制，那么这种方法将对您有所帮助。在您确信已将其推广到两个行业之前，您不必合并任何内容，因此只要您需要，您仍然可以构建两个独特的系统。但是，您并没有把自己逼到墙角，因为所有内容都在一个源代码树中，即传统行业的主干，以及每个新行业的一个分支。

如果您的公司确实想进军多个行业，那么我认为配置数据库解决方案无法满足您的所有需求。您仍然需要某种特殊的代码模块。插件架构是一件好事，因为它会有所帮助，特别是如果您将 Python 等脚本引擎嵌入到您的应用程序中。但是，我认为当您进入“数千个类”规模时，插件将无法满足您所有的代码变化要求。

您需要采取务实的方法，让您能够为新行业构建一个单独的应用程序，同时又可以相对轻松地将改进合并到现有应用程序中。您可能永远无法达到拥有数千个类和多个行业的单一主干的涅槃，但您至少会驯服复杂性，并且只需要处理行业需求存在真正差异的真正重要的变化。

如果我处于你的立场，我也会查看应用程序中可能被视为“报告”的任何和所有功能，并尝试将它们分解出来，甚至可能放入现成的报告工具中。