标准版的软件，客户要定制某些功能，有什么好办法？

[贰月]

使用场景：
我们有一套标准版本的软件，C/S的，销售给很多家公司使用。
但是同一个模块，有某家公司需要单独定制修改一下。
我不想为了这一个定制模块，把整个代码单独复制一份来帮他修改。
大家有没有什么好办法处理？

[CqCoder]

可以参考下依赖注入的思想 来达到解耦的目的 demo:

注入:
 builder.RegisterType<Log4netUtil>().As<Ilog>().SingleInstance();//log4注入
  builder.RegisterType<NLogUtil>().Named<Ilog>("NLogUtil").SingleInstance();//nlog注入

访问实现
  var log4 = EngineContext.Current.Resolve<Ilog>();
   var nlog = EngineContext.Current.Resolve<Ilog>("NLogUtil");

[以专业开发人员为伍]

比如说 ATM 机假设有10种类、1000各厂商，银行卡假设有5个业务大类、10000种，那么一个软件也能容纳得下这么多。那么假设我们发布时只支持其中十分之一，也是可以的；发布全功能的产品，也是可以的。起码从软件工程设计上，每一种机制都只是描述一下它跟其它类型的差别就足够了，而它通过自己的父类（以及更高层父类）接口来跟外界发生逻辑关系，并不是一旦有差异就重写一个全新的东西跟外界发生关系。

[贰月]

引用 1 楼 guwei4037 的回复:

1、使用git/svn版本库，建立分支，进行开发。 2、将定制模块以服务接口的方式接入系统。 3、将定制模块以插件的形式接入系统。

svn用了。是要定制版本，不是控制代码的版本

[贰月]

引用 3 楼 diaodiaop 的回复:

引用

我不想为了这一个定制模块，把整个代码单独复制一份来帮他修改。

其实就算你这样改 也只是改部分代码而已...反正就只给这个客户用 我到是觉得没什么. 反正别人也用不到..我觉得可以. 如果你想做那种通用的 其实你设计的时候就比较费劲了. 比如功能模块都是公告DLL的方式进行动态加载.. 整体功能不变只开发对应的DLL 但是这个的话 后期维护扩展比较方便 但是前期你重整 我觉得比较费劲. 如果采用copy改的方式. 开发速度快. 但是一旦项目整体要更新 你就需要对多个项目更新. 所以你自己选择吧...

目前已经改用dll方式了，但还是不够用

[贰月]

引用 4 楼 sp1234 的回复:

软件本来就是可扩展、可继承、可多态使用的东西，不像一幢大楼只能推倒重来，而软件是1分钟就重新建立起来的、具有抽象功能功能的。 你说的问题，证明你们在系统上就不具有抽象和扩展能力，不理解面向对象设计技术，只会一点结构化设计知识。

感谢回复！ 现在已经是整改过的版本了，抽象+扩展，有一部分有这意思，但整体还是有点麻烦

[zbdzjx]

如果是小的改动，就在源码中改，增加一个选项作为开关。 如果是大的改动，通常都是将整个代码都复制出来，再改的，这个没办法。除非就是告诉用户不能改。 之前帮朋友改过一个考勤相关的软件，几乎一家就是一套代码。各家的差异太大了。

[贰月]

引用 5 楼 xuzuning 的回复:

MEF

MEF不怎么懂，等下补补课

[贰月]

引用 8 楼 xuggzu 的回复:

同意楼上，设计时扩展性考虑不周，必然有此结果。 但已经如此了，只能抽出代码来修改，换谁都没招。但建议乘此机会将项目功能改成模块比如dll，或者服务也可，免得再出现类似情况。

现在已经是整理过的版本了，可能整改不彻底

[贰月]

引用 12 楼 sp1234 的回复:

具体如何设计，那要看到你的产品设计细节才清楚。只有当你有了设计图纸才知道该如何抽象、扩展和结构化才比较好。所有的最终说成是某种 EXE 或者 DLL 的概念，都首先依赖于你的在编写代码之前就应该有的抽象部分有关，如果有没有必要的抽象和多态，就没有真正合适的扩展的实现，最终不管说了多少技术名词儿结果还是重写一套东西。 所以虽然你没有具体的设计能拿出来，但是粗粗地分析是：你没有运用面向对象的抽象扩展，造成了无法重构和深入。

确实如此！里边用了一部分，不过不彻底 感谢

[Mooyi_水]

我觉得很有可能是因为后期可能有公共的东西需要更新升级，要是客户定制化东西太多的话可能会实现一个功能要在好多个版本同时实现，人力耗费挺大的

引用 3 楼 diaodiaop 的回复:

引用

我不想为了这一个定制模块，把整个代码单独复制一份来帮他修改。

其实就算你这样改 也只是改部分代码而已...反正就只给这个客户用 我到是觉得没什么. 反正别人也用不到..我觉得可以. 如果你想做那种通用的 其实你设计的时候就比较费劲了. 比如功能模块都是公告DLL的方式进行动态加载.. 整体功能不变只开发对应的DLL 但是这个的话 后期维护扩展比较方便 但是前期你重整 我觉得比较费劲. 如果采用copy改的方式. 开发速度快. 但是一旦项目整体要更新 你就需要对多个项目更新. 所以你自己选择吧...

[贰月]

引用 22 楼 qq_34266409 的回复:

我觉得很有可能是因为后期可能有公共的东西需要更新升级，要是客户定制化东西太多的话可能会实现一个功能要在好多个版本同时实现，人力耗费挺大的 [quote=引用 3 楼 diaodiaop 的回复:]

引用

我不想为了这一个定制模块，把整个代码单独复制一份来帮他修改。

其实就算你这样改 也只是改部分代码而已...反正就只给这个客户用 我到是觉得没什么. 反正别人也用不到..我觉得可以. 如果你想做那种通用的 其实你设计的时候就比较费劲了. 比如功能模块都是公告DLL的方式进行动态加载.. 整体功能不变只开发对应的DLL 但是这个的话 后期维护扩展比较方便 但是前期你重整 我觉得比较费劲. 如果采用copy改的方式. 开发速度快. 但是一旦项目整体要更新 你就需要对多个项目更新. 所以你自己选择吧...

[/quote] 后期有公共的东西升级，这个也是一个方面。现在主要是单独为某个客户修改模块麻烦

[贰月]

引用 18 楼 zbdzjx 的回复:

如果是小的改动，就在源码中改，增加一个选项作为开关。 如果是大的改动，通常都是将整个代码都复制出来，再改的，这个没办法。除非就是告诉用户不能改。 之前帮朋友改过一个考勤相关的软件，几乎一家就是一套代码。各家的差异太大了。

已经做了很多个开关了。但还是有要单独定制某个模块的

[贰月]

引用 12 楼 sp1234 的回复:

具体如何设计，那要看到你的产品设计细节才清楚。只有当你有了设计图纸才知道该如何抽象、扩展和结构化才比较好。所有的最终说成是某种 EXE 或者 DLL 的概念，都首先依赖于你的在编写代码之前就应该有的抽象部分有关，如果有没有必要的抽象和多态，就没有真正合适的扩展的实现，最终不管说了多少技术名词儿结果还是重写一套东西。 所以虽然你没有具体的设计能拿出来，但是粗粗地分析是：你没有运用面向对象的抽象扩展，造成了无法重构和深入。

太对了！就是抽象扩展这一块做的差，折腾的太累了

[oEssence1]

根据开放封闭原则，以前代码不变的前提下，开发新的功能。通过接口文件，xml,等形式进行新旧功能模块的信息传递。

[贰月]

引用 14楼以专业开发人员为伍 的回复:

比如说 ATM 机假设有10种类、1000各厂商，银行卡假设有5个业务大类、10000种，那么一个软件也能容纳得下这么多。那么假设我们发布时只支持其中十分之一，也是可以的；发布全功能的产品，也是可以的。起码从软件工程设计上，每一种机制都只是描述一下它跟其它类型的差别就足够了，而它通过自己的父类（以及更高层父类）接口来跟外界发生逻辑关系，并不是一旦有差异就重写一个全新的东西跟外界发生关系。

这几天忙，没时间上来，不好意思。 比如说工具栏上某一个按钮，就有客户想定制补充一些功能，或者某个客户又想在这个工具栏上单独加个按钮，增加的按钮，其他客户又用不到。这样的情况，该怎么处理才好？

[思篆者]

1、加一个配置，用来描述特定的按钮的外观，及对应的功能。 2、程序加载时，读配置来个性化显示需要的按钮。

[wang_peng_yl]

哥们，不想为了这一个定制模块，把整个代码单独复制一份来帮他修改， 那也得这样做，我们公司现在就面临这问题，一样一样的，每天铺天盖地的各性需求 200家客户，200个需求，98%相似度，你说为了那2%你怎么解决。200个2%呀。 我们公司现在就是放在一起的， 为了那200家的2%不同，代码越来越乱，为了这家开发个功能，只添加一点点功能 就把其它家的同样功能搞不稳定了。现在天天在维护这些不稳定的功能。 还不如一家一个项目，最起码出问题也不是大面积的 什么可扩展、可继承、可多态使用的东西，这些东西想想还行，或者说架构方面思想的东西。 不适合用在细节上。

[wang_peng_yl]

楼上们说的全是思想，对于现在的你没什么现实用处。 29楼是个方法，你评估一下改动量，如果小的话，可以这样用。

[cyg17173]

建议： 面向接口，封装窗体成DLL，每一个独立的窗体都是一个DLL。如果是定制的窗体，放到定制模块。 定制模块根据数据库记录，动态加载窗体。 导航栏和菜单栏也可以动态加载。 问题就这样解决了。 参考国内某ERP。 斑竹，回帖看验证码，看的眼睛都要瞎了。

[zcysk]

做开发的和做业务的思想是不一样的。 楼主的问题我觉得不是存在技术上的缺陷，是存在业务上的难题。 标准版软件易于维护和管理，如果都是定制版，每家跟每家的都不一样，后期维护和升级会存在很大的隐患。 因为每个客户的产品都是不一样，如果这样的话得需要强大的售后人员来支撑起来你的个性化定制，很多企业宁愿价格便宜卖标准版软件，也不愿为了一个定制费用满足客户随意的个性化需求。 说了这么多，其实我也没有什么好的办法，标准版软件也需要根据市场需求进行定期更新，来满足客户的共性问题，这样才能发展的长久一些。 做软件开发的公司和做软件产品的公司是有区别的。