发现想一个标题有点棘手,但基本上我的问题是,当需要编写客户特殊代码时,如何使系统尽可能通用(正确的术语?)。
我的场景是我们有一个标准系统,它存在于颠覆的主干中。有时客户想要进行不符合该标准系统的更改,因此我们的做法是通常将代码分支并在该分支上进行开发,但是当主干工作需要包含在客户专用中或者如果客户想要的想法需要同时存在于分支和主干中。
是否有更好的方法或标准来处理此类请求,因为似乎所有编码都非常具体?
在提高代码复用性方面,通常有几个部分:
能够交换应用程序的较小部分是核心语言设计问题。许多语言的设计都采用了最大化可重用性的方法。以下是一些示例(有些是特定于 C# 的):
它们将允许您更轻松地重用您的代码库,但它们本身并不是金子弹。
即使您利用 C# 中可用的所有功能,考虑不足的项目也可能难以互换。我建议任何更大的解决方案都应拆分为合乎逻辑的、独立的子单元。同样,解决方案结构的示例可能是:
MyProgram // Wires up components and subunits.
MyProgram.Core // Contains a core 'kernel' for your application
MyProgram.IO // Contains generic interfaces and implementations for performing IO
MyProgram.UI // Contains UI code that displays and interacts with your core. The core should not depend on UI elements.
MyProgram.Models // Contains structure of databases, data models other components may act on
MyProgram.Models.Serialization // Converts your models for IO etc. Maybe you want MyProgram.IO to be generic enough to reuse.
Helpers // Generic helpers that you tend to use in multiple applications. You will want these to be in a standalone repository so that you can keep the classes validated.
最终,您可能无法处理语言特性和良好项目设计的所有问题。如果您有一个尴尬的客户端请求,有时您可能想要提取(而不是分支)您可以重用的组件并分支您需要编辑的组件。
这当然是一个困难的场景。
一种选择可能是进行配置以规定是否打开某个功能 - 因此该功能进入主分支,但您仅为需要它的客户将配置设置为 true。它仍然有点混乱,但我认为它比每个客户拥有多个分支机构更干净。
在更复杂的场景中,您可以将新功能开发为一种“插件”架构,其中您有不同的实现来实现相同的接口——某种类型的工厂可以决定加载哪个。
我不认为有任何灵丹妙药可以维护一个受不同客户要求影响的通用代码库。