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

Question

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

这两个项目在功能上都是相似的，因此非常有动力概括原始项目的许多 guts 。此外，我确信我将在不久的将来瞄准更多市场（市场是地理上的）。

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

为了使事情变得更加复杂，已经就如何为越来越多的市场组织项目提出了几点建议：

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

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

这些不同架构的优缺点是否有任何可用的资源？

在项目与复制和分叉之间共享代码的优缺点是什么？

Answer 1

分叉通常最初会让你获得更快的结果，但几乎总是会出现并且在维护中咬你 - 错误修复和一个叉子的功能增强在其他分叉中丢失，最终你发现自己扔了整个分叉，不得不重新添加他们的功能到“最好的”分叉。如果可以，请避免使用它。

接下来：您的所有三个选项都可以正常运行，但它们在构建复杂性，维护成本，部署，通信开销以及您需要执行的重构量方面都需要权衡。

---

<强> 1。每个市场都是一个单独的项目

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

优点：

• 它允许市场A的开发人员在不干扰正在进行的B
工作的情况下打破A版本
• 这使得市场A的变更不太可能导致市场B的错误

缺点：

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

<强> 2。扩展现有项目以针对多个市场

可以让它工作好一段时间。如果您打算一次为一个市场开发一个小型团队，那么这可能是您最好的选择。

优点：

• 即使你走向（1）或（3），许可工作也可能是有价值的。
• 单一代码库允许在所有市场中进行重构。

缺点：

• 即使你只是为市场A做一些事情，你也需要构建并发布市场B，C和D的代码 - 好吧，如果你有一个小代码库，但是越来越烦人了成千上万的课程
• 一个市场风险的变化打破了其他市场的代码
• 一个市场的变化需要重新测试其他市场

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

感觉技术上很甜蜜，可能会让您分享更多代码。

优点：

• （1）的所有优点，可能还有：
  • 更清晰地分离共享和特定于市场的代码
  • 可能允许您转向公共API，这样可以将您的部分工作卸载到客户身上和/或销售利润丰厚的服务项目

缺点：

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

---

我认为（2）除了许可之外，还有你现在发现自己的地方。我认为可以暂时停留一段时间，但要付出一些努力（1） - 将共享代码移动到一个单独的项目中，即使它们都是一起构建的，例如，试图确保来自市场的依赖关系共享代码的代码都是单向的。

你是否最终取决于（1）或（3）。主要取决于谁是“负责人” - 共享代码或市场特定代码？插件和配置某些共享组件的控制器类之间的界限非常模糊。我的建议是，让代码告诉你它需要什么。

Answer 2

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

2）这或多或少是行业标准。大配置文件，根据许可证/配置限制内容。它可以使应用程序有点麻烦，但只要代码抱怨互斥的东西和所有开发人员不断沟通新功能以及它们如何在整个应用程序中波及，你应该做得很好。如果这是一个问题，这也是最容易入侵的。

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

您拥有的最佳资源可能是您的同事在不同项目中的过往经历，以及人们在这里或Slashdot或其他任何地方的人们的体验。当然是最便宜的。

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

共享代码的缺​​点： 一个变化改变了一切..小心。 如果其中有一个错误，它会影响一切。

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

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

祝你好运。

Answer 3

你说“复制和分叉”这让我觉得你可能还没有考虑将这个“分支”作为SVN等版本控制系统的分支来管理。通过这种方式，当你重构分支以容纳不同的行业时，你可以借助修订控制系统将这些变化合并回主干。

如果您遵循长期策略转移到单个应用程序，其中所有变体都由配置文件（或SQLITE配置数据库）控制，那么这种方法将帮助您。除非您确信已针对这两个行业进行了概括，否则您无需合并任何内容，因此只要您需要，您仍然可以构建两个独特的系统。但是，你并没有支持自己，因为它只是一个源代码树，传统行业的主干，以及每个新行业的一个分支。

如果您的公司真的想要攻击多个行业，那么我认为配置数据库解决方案不会满足您的所有需求。您仍然需要某种特殊的代码模块。插件架构是一件好事，因为它会有所帮助，特别是如果你在你的应用程序中嵌入像Python这样的脚本引擎。但是，当您进入“数千个级别”规模时，我认为插件不能满足您的所有代码变体要求。

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

如果我在你的位置，我也会关注应用程序中的任何和所有功能，这些功能可能被视为“报告”并试图将它们分解出来，甚至可能是现成的报告工具。