2

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

这两个项目将在功能上相似，因此有很强的动力去概括原始项目的许多内容。此外，我确信我会在不久的将来瞄准更多市场（这些市场是地域性的）。

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

为了使事情变得更复杂，关于如何为越来越多的市场组织项目，已经提出了一些建议：

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

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

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

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

4

3 回答 3

1

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

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

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

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

优点：

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

缺点：

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

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

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

优点：

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

缺点：

  • 即使你只是在为市场 A 做一些事情，你也必须为市场 B、C 和 D 构建和发布代码——如果你的代码库很小，还可以，但是当你进入数千个市场时会越来越烦人班级
  • 改变一个市场可能会破坏其他市场的代码
  • 一个市场的变化需要重新测试其他市场

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

在技​​术上感觉很甜蜜，并且可能允许您共享更多代码。

优点：

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

缺点：

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

我猜想（2）是你现在发现自己的地方，除了许可。我认为在那儿呆一会儿是可以的，但要花一些精力朝着（1）前进——将共享代码移动到一个单独的项目中，即使它们都是一起构建的，例如，试图确保来自市场的依赖关系代码到共享代码都是单向的。

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

于 2009-08-12T15:02:09.150 回答
0

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

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

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

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

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

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

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

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

祝你好运。

于 2009-03-25T17:43:46.290 回答
0

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

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

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

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

如果我站在你的立场上，我也会查看应用程序中可能被视为“报告”的所有功能，并尝试将它们排除在外，甚至可能放入现成的报告工具中。

于 2009-10-18T22:27:25.140 回答