也谈软件版本控制的问题

这应该是一个老话题，一套软件由于不同用户的需求不同分裂成n个版本，这对开发人员而言，简直是个噩梦，海邦HIS系统多年来坚持一个版本原则，面对不同医院形形色色不同的要求始终能保持所有医院同一套版本，那么，我们是如何做到的呢？

1.从客户的需求出发，有以下几种情况

A.用户的需求是原有系统没有的

这个最简单，直接增加，并推送给所有用户

B.用户的需求是原有系统的扩充

例如：某张表希望增加一个字段，这种情况也相对比较简单，直接增加，并推送给所有用户，但不强制用户必须输入

C.用户的需求是原有系统的增强

例如：原来患者电话号码允许空，但有用户希望必须输入，那就是增加配制，默认允许空，但可以配置必须输入

D.用户的需求是对原有功能测底的改变

例如：低值易耗品增加批次管理，这个对原有系统是一个颠覆性的要求，对于这种需求，需要准确分析新旧两种工作方式的差别，经过认真分析，我们认为原来的管理方式是基于批次管理的一个特例，基于批次的方式是每次入库需要产生一个新的批次，而原来的方式，可以认为也是产生一个新的批次，但这个批次和原来的批次相同，为了降低设计复杂性，不基于批次的管理，始终生成一个编号为0的批次，而对于希望给予批次管理的客户，根据配置，产生一个新的批次编号即可，这样用心的构架兼容原来的构架。

2.从技术的角度谈一谈如何保持版本唯一性

A.增加新的配置，改配置默认保持原有的行为，例如：原来患者电话号码允许空，但有用户希望必须输入，那就是增加配制，但默认值允许空

B.模块化，并基于接口的方式进行开发，如果不同用户的需求差异实在太大，那就用不同的接口实例来实现，但系统配置使用原来的实例，用户可以选择新的实例

C.基于总线的方式来实现，例如：不同用户可能使用的合理化用药软件不一样，这导致接口也不一样，具体的做法就是，单独开发每种软件的接口模块，前台程序每次封存医嘱向总线发送医嘱封存消息，不同的用户通过总线配置程序挂载不同的总线插件即可，对于没有合理化用药的客户，不挂载即可，这样，前台程序可以对所有用户升级，而不会有兼容性问题

D.采用小幅度增量升级，便于控制程序更新规模，方便在发生错误时能够及时修正

E.采用实时升级技术，确保每次升级，让所有用户都能更新至同一版本，例如海邦HIS就要求用户必须提供升级用的前置机，确保每个用户都在第一时间得到最新版本

F.一个不是技术的问题，就是不要太小气，不要因为某项新功能想着收钱就故意不升级，这个我感觉在限制用户的时候，也提高了维护成本，按这种方式，很快用户就得到了分化，如果一个用户长期得不到升级，突然来一个大的增量升级，很可能是灾难性的，我想阅读此文的读者一定深有体会。