35

产品版本和分支问题(11.17)

 5 years ago
source link: http://blog.sina.com.cn/s/blog_493a84550102ygs9.html?amp%3Butm_medium=referral
Go to the source link to view the article. You can view the picture content, updated content and better typesetting reading experience. If the link is broken, please click the button below to view the snapshot at that time.

这几年做项目，经常会遇到的一个问题就是面对不同的客户，经常都有一些个性化的定制需求，这往往就导致后期在软件版本上保留了多个软件版本分支，直接导致的问题就是在公共代码部分出现修订的时候往往修改工作量相对大，而且还容易出现错误。

这个问题在很早以前的博客上也谈到过，今天在单独谈下具体的解决思路。

1. 采用组件化和模块化的开发方法进行

这个也是自己经常提到的做法，即产品研发的时候就采用组件化和模块化的方法进行，对于不同的组件在源代码库也分开进行管理。这样的好处就是各个组件都有独立的代码分支和管理版本，对于客户项目需求有变化的时候，只需要对特定的组件外拉分支即可满足要求，而不用对整个软件项目源代码全部新起分支。而对于没有变化的公共组件，本身也不好造成任何影响。

也即是我们说的，在产品化的推进过程中，我们期望的是能够有70-80%的基础组件和代码不变动，而只有20-30%的组件或代码进行变更。这已经可以极大的减少后期的运维工作量。

2. 将个性化需求进行抽象，并在统一的一个版本实现，通过配置进行管理

这个也是常用的一种方法，即针对客户提的一些个性化需求，我们需要对这种个性化需求进行需求抽象，提取出关键的需求逻辑，然后将该需求逻辑做为一个配置项，可以通过配置进行灵活的管理。

比如对于SOA管控平台，客户有个性化需求需要对输入传递的数据字段进行授权控制，这个需求相对个性化，那么我们实现方式是增加这个控制功能，包括元数据维护。然后再增加一个配置功能，即对于客户是否启用数据权限校验。对于没有个性化需求的客户直接选择不启用配置即可。

这种方式可以确保仍然只保留了一套代码，但是里面增加了很多场景规则和配置分支，相对来说代码的复杂度会增加，同时对本身的性能也会有一定的影响。

3. 增加独立的组件来进行适配和代理

如果你开发一个业务系统，你自己本身可能有标准的流程引擎，但是你在做客户项目的时候，经常会出现客户要求使用甲方已有的公共流程平台引擎来进行流程集成。那么这个时候就需要将自己的流程引擎替换掉。或者说你在实施财务共享项目的时候，你会发现你最终生成的凭证，发票等信息都需要在审批通过后导入到ERP系统。这些都需要业务系统和外部系统集成的范畴。

对于这些场景我们看到，没实施一个项目或客户的时候，都需要对这块内容进行定制开发，同时会影响到整个项目的源代码版本。而最好的方法就是将对外接口集成部分单独抽取一个代理服务组件，代理服务组件朝内提供标准的接口和数据给内部功能模块，朝外又去适配各个外部业务系统的接口差异。

通过代理组件的定制可以做到，内部的其它组件功能和逻辑都不需要做任何修改，所有的修改，数据映射，转换和适配等操作都集中在代理组件完成即可。这种方法可以确保产品基础代码版本的一致性。

这块主要集中在外部接口集成，外部门户集成，工作流引擎集成，4A基础数据集成几个关键方面。

4. 完全独立新功能，新增独立组件进行开发

在客户项目实施过程中，如果发现需要完全独立的新增加个性化需求功能，同时该功能又没有任何复用的价值的时候，我们可以考虑新增独立的新组件进行开发。新增的独立组件，独立进行需求，设计，开发，打包和测试，同时和整个产品进行集成，又和原有产品保持足够的松耦合状态。

对于数据库而言则是确保数据库本身不独立版本，直接取所有数据库表的全集。如果数据库再单独不同的版本，那么后续版本管理难度将更大。


report

Recommend

About Joyk


Aggregate valuable and interesting links.
Joyk means Joy of geeK