1,265
社区成员
发帖
与我相关
我的任务
分享请问这样的设计是不是自掘坟墓？
要开发新系统，由于现实原因，想做类似平台样的蓝本，然后根据客户的个性化需求再做扩展开发，目前初步的设计方案是先做出一个大体框架，然后根据不同客户的要求做A公司版本，B公司版本，C公司版本、、、
开始大家都觉得是挺好的方案，可是后来考虑到现实问题，觉得版本管理太复杂了。因为有多个版本要维护，也不好用分支结构吧，因为如果用分支结构，结局无非是两种：1)合并到主线；2)多版本共存。可是我觉得这两条路都走不通：因为每个客户的版本都有不同，没有办法合并，并且可能都需要后期维护，再说也不要求将其合并；可是如果多版本共存，那维护起来是多么可怕的一件事啊！
是不是这样的设计本身就是走不通的？有点像实施工作中的二次开发了，可是我们的现实情况又决定了不可能专门组织一支实施队伍，就是所有的工作其实都是算到我们开发人员的头上，并且后期的维护也会找我们。有办法解决这个版本维护的问题吗？如果不行的话，是不是应该考虑其它设计方案了？
最近在一些设计方面的书上看到框架的概念，感觉应该挺适合我们这个系统的。可是苦于对框架结构了解不多，请大侠指点指点。用VB这样不是真正面向对象的语言来做基于框架结构的程序，可行吗？
开始大家都觉得是挺好的方案，可是后来考虑到现实问题，觉得版本管理太复杂了。因为有多个版本要维护，也不好用分支结构吧，因为如果用分支结构，结局无非是两种：1)合并到主线；2)多版本共存。可是我觉得这两条路都走不通：因为每个客户的版本都有不同，没有办法合并，并且可能都需要后期维护，再说也不要求将其合并；可是如果多版本共存，那维护起来是多么可怕的一件事啊！
是不是这样的设计本身就是走不通的？有点像实施工作中的二次开发了，可是我们的现实情况又决定了不可能专门组织一支实施队伍，就是所有的工作其实都是算到我们开发人员的头上，并且后期的维护也会找我们。有办法解决这个版本维护的问题吗？如果不行的话，是不是应该考虑其它设计方案了？
最近在一些设计方面的书上看到框架的概念，感觉应该挺适合我们这个系统的。可是苦于对框架结构了解不多，请大侠指点指点。用VB这样不是真正面向对象的语言来做基于框架结构的程序，可行吗？
...全文
请发表友善的回复…
发表回复
spidertan 2004-12-20
- 打赏
- 举报
设计与开发中的控制一直是软件开发过程中的难题，引入版本控制多少能解决一些问题，但是在公司需要严格制定一项规章制度并落实实行
许野平 2004-12-20
- 打赏
- 举报
自己开发平台或者框架，要注意许多超出文体表面现象的问题。小心小心再小心！
看看要就发发 2004-12-19
- 打赏
- 举报
这样挺危险的,
“不过我们现实情况有一点优势，就是只要是维护，就会有进账，哪怕这个项目做10年20年，只要用户在提需求，就有人付钱，呵呵。也许PM的立场正是基于这个优势吧，不怕项目组扩大，大不了再多找几个人来维护”
------------这不可能长久的
还是考虑版本控制吧
“不过我们现实情况有一点优势，就是只要是维护，就会有进账，哪怕这个项目做10年20年，只要用户在提需求，就有人付钱，呵呵。也许PM的立场正是基于这个优势吧，不怕项目组扩大，大不了再多找几个人来维护”
------------这不可能长久的
还是考虑版本控制吧
lyguo 2004-11-17
- 打赏
- 举报
你试试把这些工作交给数据库，不同版本的信息在数据库中进行设定和维护！应该可以有一点改善吧！
根据数据库中不同的设置，调用不用的模块，我们以前就这样做的，
不过做起来，呵呵，太麻烦啦
根据数据库中不同的设置，调用不用的模块，我们以前就这样做的，
不过做起来，呵呵，太麻烦啦
wbv98865 2004-11-10
- 打赏
- 举报
你试试把这些工作交给数据库，不同版本的信息在数据库中进行设定和维护！应该可以有一点改善吧！
但这样编程过程中的工作量也是很大的！
（我不清楚你们项目的具体情况，也只是提个建议你们可以试试！）
我也觉得你们的系分功力似乎不太够，在项目的组织和管理方面需加强！
但这样编程过程中的工作量也是很大的！
（我不清楚你们项目的具体情况，也只是提个建议你们可以试试！）
我也觉得你们的系分功力似乎不太够，在项目的组织和管理方面需加强！
liaoqingpeng 2004-11-10
- 打赏
- 举报
“不过我们现实情况有一点优势，就是只要是维护，就会有进账，哪怕这个项目做10年20年，只要用户在提需求，就有人付钱，呵呵。也许PM的立场正是基于这个优势吧，不怕项目组扩大，大不了再多找几个人来维护”
------------这才是关键！
------------赚钱才是硬道理！
------------这才是关键！
------------赚钱才是硬道理！
NightCloud 2004-11-09
- 打赏
- 举报
这些问题已经不是单纯的技术问题了，还有管理方面的问题了。
比如说要进行完善的测试啦。每个版本都要有详细的文档啊。
每块程序都要有详细的注释啦，要有完善的版本控制啦，等等。
我觉得这些都是要跟上的
比如说要进行完善的测试啦。每个版本都要有详细的文档啊。
每块程序都要有详细的注释啦，要有完善的版本控制啦，等等。
我觉得这些都是要跟上的
zhang_yzy 2004-11-06
- 打赏
- 举报
你说的问题，就是做项目的苦恼，你必须尽力的满足每个项目的要求，并保证他可以持续的应用，
这也就是说你不论怎么做，最终的结果一定是多用户多版本的（可能有些武断），
所以也就是说结果几乎是无法避免的，
但是，我们可以通过其他方式控制一下后期的维护工作
比如除了主要的BASE版外，为每个项目作成一个库，由专人负责管理其的修改、分发、更新文档等
（仓促之间，没有想的很具体）
这也就是说你不论怎么做，最终的结果一定是多用户多版本的（可能有些武断），
所以也就是说结果几乎是无法避免的，
但是，我们可以通过其他方式控制一下后期的维护工作
比如除了主要的BASE版外，为每个项目作成一个库，由专人负责管理其的修改、分发、更新文档等
（仓促之间，没有想的很具体）
caire1983 2004-11-05
- 打赏
- 举报
总的说来做软件很累
stonesky 2004-11-05
- 打赏
- 举报
需要一个经验丰富的系统架构设计师
laurecn 2004-11-05
- 打赏
- 举报
我认为主要想法是正确的，但是实施起来可能问题很多；并且每一部分实现起来可能都会与目的有差距，然后合起来就未必是个好产品；毕竟需要很好的设计，并且实现也需要一定的水平；我们目前也在走这个方向，但是实现起来却是很大难度，很多现实问题都于目标有很大差距，其中最主要的问题也许就是人员的问题，并不是指人力资源问题，而是人员平均水平的问题，需要严格的开发管理控制。
虽说比较难，但是也是目前很好的方法
虽说比较难，但是也是目前很好的方法
jianghd 2004-11-05
- 打赏
- 举报
無論如何這到了後期維護肯定是非常累人的。
像我們公司是收集用戶需求，做出一個比較通用的系統拿出去，用戶適合就用，不適合就不用。以後定期做版本升級就好了。
而當前國內的企業管理還是很不健全，每個企業一個管理模式，導致了軟件開發的個體化。
這就是我們這一代程序員的悲哀！
像我們公司是收集用戶需求，做出一個比較通用的系統拿出去，用戶適合就用，不適合就不用。以後定期做版本升級就好了。
而當前國內的企業管理還是很不健全，每個企業一個管理模式，導致了軟件開發的個體化。
這就是我們這一代程序員的悲哀！
cacu 2004-11-05
- 打赏
- 举报
代码不要改，该系统设置
uno 2004-10-25
- 打赏
- 举报
从某个成熟版本中提炼出几个可独立模块化的构件
建立自己的构件库
建立完善的CBSD模式
这样比较灵活
建立自己的构件库
建立完善的CBSD模式
这样比较灵活
lybabyying 2004-10-23
- 打赏
- 举报
同上
BinaryWorld 2004-10-22
- 打赏
- 举报
有很多公司都是采用做base版然后采用二次开发的方法来完成。
base版甚至连界面都没有，都是些核心模块的集成，例如：操作平台，I/O操作，框架，基本消息事件流程，异常错误处理。
界面，少部分可能产生变动的功能，以及用户特殊需求的功能再根据base版提供的接口来完成。
但base版也不是一成不变的，很可能开发中有些特殊需求仅利用base提供的接口会到底效率过于低下，所以也要维护出特殊的base版出来。
至于这么个做法会导致什么样的后果也可能会如楼上的各位前辈所描述维护过于困难等等，但我想这个还是和公司的管理政策有关：
详细的设计流程和开发流程文档（我们公司就是这个东东不够丰富导致现在什么模块都要问别人，影响了自己和别人，还有可能导致大家的理解各不相同，我们做的是oo.o）
员工的责任感（如果接口被定了下来，无论如何要提交的是尽可能最好的或尽可能最优的实现）
客户需求的正确分析（并不是所有的客户需求都是必须满足的，必须华分清哪些是必须做的，哪些是鸡肋，个人意见：只要不是必须做的大可不必做，除非该需求非常简单并且不会涉及到太多的模块。答应了客户却做不出来的，只会给客户留下负面影响，很多时候，只要不是坏的，就是好的）
需求实施经理的正确决策（经理一定要明晰流程，必须确保新实施的功能不会造成影响，然后再下分任务。推荐：需求经理和事实经理联手的方式，这样出来的需求才可能更合理些。）
个人认为公司做的好的产品可以在销售中扩大规模，二次开发的难度会小于一次开发，因为可以通过扩大二次开发队伍的方法来填补维护的困难。但也有一点必须小心：添加人并不是解决问题最好的途径。
base版甚至连界面都没有，都是些核心模块的集成，例如：操作平台，I/O操作，框架，基本消息事件流程，异常错误处理。
界面，少部分可能产生变动的功能，以及用户特殊需求的功能再根据base版提供的接口来完成。
但base版也不是一成不变的，很可能开发中有些特殊需求仅利用base提供的接口会到底效率过于低下，所以也要维护出特殊的base版出来。
至于这么个做法会导致什么样的后果也可能会如楼上的各位前辈所描述维护过于困难等等，但我想这个还是和公司的管理政策有关：
详细的设计流程和开发流程文档（我们公司就是这个东东不够丰富导致现在什么模块都要问别人，影响了自己和别人，还有可能导致大家的理解各不相同，我们做的是oo.o）
员工的责任感（如果接口被定了下来，无论如何要提交的是尽可能最好的或尽可能最优的实现）
客户需求的正确分析（并不是所有的客户需求都是必须满足的，必须华分清哪些是必须做的，哪些是鸡肋，个人意见：只要不是必须做的大可不必做，除非该需求非常简单并且不会涉及到太多的模块。答应了客户却做不出来的，只会给客户留下负面影响，很多时候，只要不是坏的，就是好的）
需求实施经理的正确决策（经理一定要明晰流程，必须确保新实施的功能不会造成影响，然后再下分任务。推荐：需求经理和事实经理联手的方式，这样出来的需求才可能更合理些。）
个人认为公司做的好的产品可以在销售中扩大规模，二次开发的难度会小于一次开发，因为可以通过扩大二次开发队伍的方法来填补维护的困难。但也有一点必须小心：添加人并不是解决问题最好的途径。
cnwww 2004-10-21
- 打赏
- 举报
悲剧天天都在发生，似乎每个人也都知道发生的原因，可是你有尽力去避免他的发生吗？人为因素造成的事，又能够怨谁？
jcaomao 2004-10-21
- 打赏
- 举报
我觉得这是一个设计和管理同样重要的事情。
设计方面大家都说了，管理方面当然也该有一个组件库，库里面不仅仅指由二进制代码和源代码，还应该有详细的组件设计文档。 生成a版本b版本，用不同的组件来组装。
设计方面大家都说了，管理方面当然也该有一个组件库，库里面不仅仅指由二进制代码和源代码，还应该有详细的组件设计文档。 生成a版本b版本，用不同的组件来组装。
天乐_那由他 2004-10-18
- 打赏
- 举报
强烈支持讨论此问题，改日发贴我们再深入探讨。顶一下先
qixiao 2004-10-16
- 打赏
- 举报
同意Eddie005(暴走005)所说，必须要有个设计和升级的计划，所有的程序修改都要围绕这个计划
加载更多回复（30）
