返回列表 发帖

对于软件版本控制的几点思考



刚刚看到有人提问如何进行版本控制,这个问题我也遇到过,同时也问一些公司,有几种方法,供大家参考。


1、一份源代码。
     软件功能设计时需要多考虑可配置的地方,尽量做到灵活多变,多采用xml技术。
    文档要详细,做好需求跟踪矩阵,不能将不同医院的需求搞混。
    要做版本控制,版本号不能少,不管是内部测试版本还是医院上线版本,均要做好做好BUG修改和功能修改的文档记录。
    优点:一份代码,可以减少冗余,bug问题只需要修改一次;

                有利于产品化实现;
                有利于积累。

    不足:文档要求较好,不然不同医院需求可能会搞混。

                   时间跨度比较长的医院升级较麻烦。
2、产品研发中心研发出整体产品,但不同医院采用不同代码。貌似很多大型公司都用这种方式。这种方式对整体设计的要求可能会比较高,产品研发时对需求的了解要比较详尽。

     优点:相对独立,方便不同医院实施人员自行修改代码,不会出现不同医院之间的相互影响。当医院达到上千家时,优势应该是很明显的。


     不足:如果早期设计不足或后期做重大调整时,工作量会比较大。


3、采用分支结构,SVN和微软的TFS貌似都有这个功能,不过我没有用过,用过的朋友可以在回复中帮助补充。软件的主体核心功能、内部框架采用一份代码,对于需求变动较多的代码或项目,可采用分支结构。寻求前2种方法的一种平衡。但哪边该冗余哪边不该冗余,需要好好思考。
收藏 0
誓与医疗信息化共存亡!

采用分支结构是最明智的选择,核心代码为主,其他个性化需求单独建立分支管理
乘天地之正,而御六气之辩,以游无穷。

TOP

其实没有一种方法是完美十全十美的方法,看具体情况了,版本控制是必须的,分之多了也很凌乱
PACS, RIS,DICOM,生存之本
IHE,区域医疗,兴趣方向
I am mouse

TOP

支持分支结构

TOP

其实没有一种方法是完美十全十美的方法,看具体情况了,版本控制是必须的,分之多了也很凌乱 ...
mouse 发表于 2015-3-18 20:34

个人赞同上述观点,版本多有时会造成管理上的混乱。
[img][/img]

TOP

回复 5# haibo20102008


   版本多是必然的,只能从管理控制上多花心思,多下功夫,多想办法,我们都需要抱着如下态度来做事:办法总比问题多。。。否则怎么做下去呢
PACS, RIS,DICOM,生存之本
IHE,区域医疗,兴趣方向
I am mouse

TOP

赞一个。。。。。
学习是一种信仰,分享是一种美德,交流是成长的阶梯,你我一路前行!

TOP

现代电脑技术就是发达啊,就是苦了那些软件开发的
www.sitongbxg.cn彩色不锈钢板
www.sitongbxg.com佛山不锈钢板

TOP

方法总比困难多

TOP

其实维持一个版本是可以做到的,关键在于你的构架是否合理,合理的构架,一套代码可以应付所有医院,不合理的构架,只能不同的医院用不同的代码

TOP

我们的HIS一直都是采用自动升级,保持所有客户版本相同

TOP

返回列表