user-interface - 为多个区域和客户提供一个代码库

Question

背景： 我们使用 ASP.NET MVC 为美国地区的一个客户端构建了一个数据密集型应用程序，现在我们正在慢慢转向 ASP NET Core。我们需要为加拿大开发类似的版本，我们的方法是维护两个不同的代码库，即使 UI 70% 相同。

问题： 两个代码库似乎可以维护，但如果必须更改通用组件，则最终会做双重工作。现在我们有来自多个区域的多个客户端，并且 UI 可能会因客户端和区域而有所不同，我们对如何仅使用一次代码库构建这样的应用程序感到有些困惑。

我不确定什么是可维护和可扩展的方法。一种方法是让 UI 由能够显示和隐藏组件的规则引擎提供支持。从部署的角度来看，这种方法的可维护性如何？

解决这个问题的其他方法是什么？

标签： user-interfacearchitectureuser-experience

Answer 1

我能想到的主要方法是：

1. 分离代码库和发布管道。这似乎是您当前的方法。

   • 优点：
     • 独立发布 - 毫不奇怪，例如发布另一个团队为美国所做的对加拿大的更改
     • 可能更简单的代码库 - 更少的配置，更少的“if (region == 'CANADA')...”
     • 独立 QA - 如果您只是测试一个环境，自动化测试会简单得多
   • 缺点：
     • 正如您已经注意到的那样重复工作

2. 一个代码库，更改配置驱动。

   • 优点：
     • 在一个地方进行更改
   • 缺点：
     • 许多开发人员同时处理相同代码的机会更高
     • 你很可能会得到可怕的“如果”
     • 分离发布管道可能非常棘手。如果您对加拿大进行更改，则需要为美国测试所有内容 - 这可能需要大量工作，具体取决于 QA 自动化水平和测试场景的复杂性。另外，您是否仅仅因为加拿大有人想将按钮颜色更改为绿色而释放美国？如果你这样做了，那你就浪费时间。如果您不这样做，那么可能未经测试的更改就会堆积在下一个美国版本中。
     • 如果你有其他地区来，这个代码很快就会变得复杂——很多人只是为了让他们的地区工作而投入一些东西，而你最终得到的是意大利面条代码。

3. 使用通用的可配置模块分离代码库。这可能包含您认为不太可能在不同地区有所不同的任何内容：具有核心逻辑的 Nuget 包、具有 javascript 的 npm 包、前端样式等。

   • 优点：
     • 如果做得好，您可以获得两全其美 - 单独的发布管道和单独的（简单）区域特定代码
     • 您可以更改公共模块并决定何时/是否将每个区域分别更新到最新版本
   • 缺点：
     • 更多的基础设施工作 - 您需要每个应用程序和每个包一个发布管道
     • 在应用程序中使用时调试和理解打包代码很棘手
     • 更改公共模块中的某些内容并在您的应用程序中测试它是一件痛苦的事情 - 您必须去公共存储库，进行更改，测试它，创建 PR，合并它，等待包构建并发布，升级您的应用程序...然后您发现更改是错误的。

我从事过这样的项目，但总是存在问题——如果你让它超级可配置，它就会变得不可读和过度设计。如果将其分开，则必须在许多地方进行更改，并且在许多地方维护诸如单元测试之类的东西是一场噩梦。由于您已经从方法 1 开始，并且由于您提到其他区域即将到来，我建议您使用当前的策略并慢慢抽象出常见的部分以分离 repos（转向第 3 方法）。我认为使此类更改更容易的最重要的部分是适当的测试自动化水平——无论是对于您的应用程序还是创建它们时的公共模块。

我可以给你的一条建议是务实。一定程度的重复是可以的，特别是如果替代方案是一个复杂的规则引擎，没有人理解，也没有人想接触，因为它无处不在。