如何在代码库中处理许多不同的自定义？

Question

我们创建了一个用于SaaS业务的Web应用程序。 简单的定制可以通过CSS覆盖甚至简单的插件来完成。

但是，我们有许多具有“企业”定制需求的更大的“企业”客户。 这些自定义包括对UI的更改，新屏幕，不同的屏幕流，不同的后端，永远不会进入主应用程序的新功能，将来可能会进入主应用程序的新功能等等。

对于应用程序的那些较大更改，我们会为每个客户提供服务。 在分叉中，我们只是根据需要更改事物。 代码库不断发展，我们合并并熟练掌握了一些东西，以使它们与主要开发树中发生的重要事情保持同步。

它可以工作，但是我们都想知道它从长远来看将如何扩展。 我想知道哪种方式最好的方式是处理对定制有很高要求的客户。

我看到三个选择。

极端模块化

例如，这就是原子编辑器的工作。 原子中的几乎所有内容都是通过插件和定义明确的接口完成的。

这样做的好处是可以非常独立地进行自定义。 您不需要大的叉子，而是需要多个较小的子组件，然后通过另一个package.json其组装在一起。

这带来了复杂性的缺点。 尤其是在涉及UI方面，您需要具有可靠的接口以及良好的挂钩。 我想知道什么对Atom有效，对任何复杂的UI是否有效。 毕竟，Github不会面对必须维护为不同客户定制的许多不同版本的atom的挑战。 他们实际上会处于更好的位置吗？ 最后，它可能归结为维护大量的分叉，而不是仅保留几个。

git分支

这就是我们今天要做的。 分支，改组，合并，挑选樱桃，让Git做艰苦的工作，并祈求不要让分歧太大。

功能标记

我对这件事感到很震惊。 从GitHub到FlickR的许多公司都广泛使用功能标志。 asana还提到他们使用它们仅向部分客户推出功能。 从理论上讲，如果我们仅将所有自定义项隐藏在功能标志后，并与​​一个通用代码库保持和平与和谐，这听起来就很好。 我们甚至可以确保从最终编译中剔除未使用的功能。 这也是EmberJS所做的。

但是其他人警告说，从长远来看，功能标志确实对维护性不利，在功能最终证明稳定之前，只能将其用作临时工具。 如果我们要使用功能标记来隐藏自定义项，则必须将其维护很长时间。

您将如何解决这个问题？