1,265
社区成员
发帖
与我相关
我的任务
分享这样的项目如何做版本管理？
公司开发新系统，由于现实原因，想做类似平台样的蓝本，然后根据客户的个性化需求再做扩展开发，请问这样的项目如何做版本管理？
比如说：先做出一个大体框架，然后根据不同客户的要求做A公司版本，B公司版本，C公司版本、、、这样的项目该怎么做版本管理阿？头疼阿，好像用分支结构也起不了什么作用，因为如果用分支结构，结局无非是两种：1)合并到主线；2)多版本共存。可是我觉得这两条路都走不通：因为每个客户的版本都有不同，没有办法合并，并且可能都需要后期维护，再说也不要求将其合并；可是如果多版本共存，那维护起来是多么可怕的一件事啊！
是不是这样的设计本身就是愚蠢的？有点像实施工作中的二次开发了，可是我们的现实情况又决定了不可能专门组织一支实施队伍，就是所有的工作其实都是算到我们开发人员的头上，并且后期的维护也会找我们？请大家帮忙分析一下这样的设计是不是自掘坟墓？
比如说：先做出一个大体框架，然后根据不同客户的要求做A公司版本，B公司版本，C公司版本、、、这样的项目该怎么做版本管理阿？头疼阿，好像用分支结构也起不了什么作用，因为如果用分支结构，结局无非是两种：1)合并到主线；2)多版本共存。可是我觉得这两条路都走不通：因为每个客户的版本都有不同，没有办法合并，并且可能都需要后期维护，再说也不要求将其合并；可是如果多版本共存，那维护起来是多么可怕的一件事啊！
是不是这样的设计本身就是愚蠢的？有点像实施工作中的二次开发了，可是我们的现实情况又决定了不可能专门组织一支实施队伍，就是所有的工作其实都是算到我们开发人员的头上，并且后期的维护也会找我们？请大家帮忙分析一下这样的设计是不是自掘坟墓？
...全文
请发表友善的回复…
发表回复
qq78 2004-09-06
- 打赏
- 举报
我还是重开一帖吧，这个帖子结掉。谢谢大家！
qq78 2004-09-06
- 打赏
- 举报
谢谢楼上的，关于这个问题，我问的确实有些文不对题，原因是大家讨论好这样来设计我们的程序，但是会后我又想了想相关的问题，想到版本管理很难做，所以就问出这样的问题了
其实应该还是设计的问题，这个设计也只是大家初步讨论的结果，如果结果是这样设计会导致版本管理的不可行性，那么没办法，只好改设计了。
其实应该还是设计的问题，这个设计也只是大家初步讨论的结果，如果结果是这样设计会导致版本管理的不可行性，那么没办法，只好改设计了。
asj 2004-09-06
- 打赏
- 举报
想做类似平台样的蓝本，然后根据客户的个性化需求再做扩展开发
每个客户的版本都有不同，没有办法合并
如果多版本共存，那维护起来是多么可怕的一件事啊
......................................
这个和版本管理有什么关系呢？根本就是你的思路自相矛盾嘛。要做框架再扩展，不能合并又不想维护。那你希望怎么样呢？有个自动帮您维护的工具？
这样不是死路一条，不过是麻烦一点，时间长了成本增高。不过随着时间和付出的无用功的增加，渐渐的你就会明白怎么进行更好的复用设计，也明白这个目标值得付出多大的代价。至于开发语言的问题，这个是可以改变的，改变的成本也是代价之一。
不用那么悲观的，软件开发就是怀着一个理想的目标，追求一个不算完全失败的结果。脏活累活总是要作的。
每个客户的版本都有不同，没有办法合并
如果多版本共存，那维护起来是多么可怕的一件事啊
......................................
这个和版本管理有什么关系呢？根本就是你的思路自相矛盾嘛。要做框架再扩展，不能合并又不想维护。那你希望怎么样呢？有个自动帮您维护的工具？
这样不是死路一条，不过是麻烦一点，时间长了成本增高。不过随着时间和付出的无用功的增加，渐渐的你就会明白怎么进行更好的复用设计，也明白这个目标值得付出多大的代价。至于开发语言的问题，这个是可以改变的，改变的成本也是代价之一。
不用那么悲观的，软件开发就是怀着一个理想的目标，追求一个不算完全失败的结果。脏活累活总是要作的。
qq78 2004-09-05
- 打赏
- 举报
to klbt:
我们目前是打算做出公共框架，然后根据具体要求再扩充定制内容，各个版本的扩充内容可能不一样。
而对于二，由于我们的现实原因，这样实现起来难度太大了，不得已才退而求其次，在做出公共框架的基础上再扩充的。
请问还有别的设计思路吗？
to stonespace(stonespace) ：
我们也是打算先提取出公共部分，但是由于客户的原因，各家都存在一些不同之处，所以总是要做二次开发的，而我们的开发语言是VB，所以面向对象功能很弱，像对象提取、类的继承等都不太现实
还有没有别的办法呢？难道就真的是死路一条吗？
我们目前是打算做出公共框架，然后根据具体要求再扩充定制内容，各个版本的扩充内容可能不一样。
而对于二，由于我们的现实原因，这样实现起来难度太大了，不得已才退而求其次，在做出公共框架的基础上再扩充的。
请问还有别的设计思路吗？
to stonespace(stonespace) ：
我们也是打算先提取出公共部分，但是由于客户的原因，各家都存在一些不同之处，所以总是要做二次开发的，而我们的开发语言是VB，所以面向对象功能很弱，像对象提取、类的继承等都不太现实
还有没有别的办法呢？难道就真的是死路一条吗？
stonespace 2004-09-05
- 打赏
- 举报
这不是版本管理的问题，是软件重用的问题。
应该严格分开相同的部分和定制部分，相同部分越多越好，可以牺牲简单和可理解性，或者最大限度的可重用性。相同的部分应该严格不能修改。
应该严格分开相同的部分和定制部分，相同部分越多越好，可以牺牲简单和可理解性，或者最大限度的可重用性。相同的部分应该严格不能修改。
klbt 2004-09-05
- 打赏
- 举报
这样的设计是自掘坟墓，同意。
多版本并存不能考虑，未来工作量难以想象。
有两种方案
1 保留公用组件，其他作为扩展部分，为各项目定制；
2 归并为一个版本，通过参数设置维护。
各有利弊，我一般用第二种.
多版本并存不能考虑，未来工作量难以想象。
有两种方案
1 保留公用组件，其他作为扩展部分，为各项目定制；
2 归并为一个版本，通过参数设置维护。
各有利弊，我一般用第二种.
