User interface 为多个区域和客户端提供一个代码库

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

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

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

---

还有什么办法可以解决这个问题呢？

很难回答这样的问题，我怀疑你能得到比“视情况而定”和“选择你的毒药”更好的答案，但我会尽我最大的努力

我能想到的主要方法是：

独立的代码库和发布管道。这似乎是你目前的做法

• 优点：
  • 独立发布-没有其他团队为我们对加拿大做出的更改这样的意外
  • 可能更简单的代码库-更少的配置，更少的“if（region=='CANADA'）…”
  • 独立QA—如果您只测试一个环境，那么自动化测试就简单多了
• 缺点：
  • 正如您已经注意到的，重复工作

一个代码库，由配置驱动的更改

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

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

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

我曾经做过这样的项目，但总是会有问题——如果你让它超级可配置，它就会变得不可读和过度工程化。如果将其分开，则必须在许多地方进行更改，而在许多地方维护单元测试之类的东西是一场噩梦。 由于您已经开始采用方法1，并且您提到了其他地区即将到来，因此我建议您按照当前的策略，慢慢地将常见的部分抽象为单独的回购（朝着第三种方法移动）。 我认为最重要的一点将使这些更改变得更容易，那就是一个相当高水平的测试自动化——无论是对于你的应用程序还是你创建它们时的普通模块

我能给你的一条建议是务实。某种程度的重复是可以的，特别是如果替代方案是一个复杂的规则引擎，没有人理解，也没有人想碰它，因为它在任何地方都被使用

---

我希望这有帮助，祝你好运

软件的本质是可配置的。你为什么不让它可配置？@Flimzy我知道它应该是可配置的。正如我提到的，一种方法是使用规则，在服务器上呈现页面时，可以根据规则切换组件。要定义/编辑这些规则，我们肯定需要一个用户界面。非常感谢您提供如此详细的答案，我同意您的看法，即为此类产品构建规则引擎将非常复杂，并且在将来不易维护。同时，每个客户机和区域都有一个代码库会有太多的代码库，我不确定这是不是一个好办法。