请大家谈谈多人vc程序,界面、代码怎么分工,以及,每人写的代码怎么集中到一个程序中去,请大家积极讨论,希望对大家都有好处。
解决方案 »
- 我的vc++有时linking半天没反应
- 现在笔记本都Win7 64位,那该怎么配置VC 64位编译器啊?
- 磁盘格式问题~~(高分求助)
- 如何生成多节点xml文件
- 如何不用点击TOOLBAR的按钮就能更改其CHECK状态,好象没有类似象CBUTTON的SETCHECK函数???
- 为什么我用CopyFile()复制文件夹的时候就出错,GetLastError()是5(拒绝访问)
- 向工程里添加文件出的措
- 关于动态分配内存的问题
- 请问Unicode 在编程中影响???
- 有没有根据 IP 查出在此IP上的 OICQ 号的工具? 我的 IP 被人盗用,我想查出它的 OCIQ号,跟它聊聊天....
- 组件消息的问题
- 在FormView中摆了些控件,其余地方为绘图区,有没有像Delphi中PaintBox的控件,往它上边画,还是直接往FormView上画?
由一个人来分工,这个人通常叫项目经理,呵
分好美工和民工后,还要对民工进行分配,假如有民工A、B、C、D,
假设现在做的是一个打字系统,民工A负责计算成绩,项目经理要求A写一个模块,输入:时间,正确数,总数,输出:正确率,速度,要求A提供两个接口,就是float GetAccuracy()和int GetSpeed()
然后再安排民工B,要求他写一个。都差不多是这个样子,每个民工到最后完成了各自的任务后,项目经理就按预先的安排,把几个民工提供的接口合并一吓,就是一个程序啦!!真伟大!
如果你连基本的reuse思想都没有
连DIP,OCP,ISP都不能很好的掌握,实践
你搞什么东西?
如果要可测试,就必须对逻辑和界面进行解耦,进行分层
换句话说ultru-thin GUI
首先就是要肯定gui是没有逻辑的,只是一个表现层,
java这一点没有api,mfc这种类库的限制就非常漂亮的能理解,java底下有jemmy可以来进行对界面的测试。c++就很难,被束缚住了。那么对于你的问题应该就能解释了:
请大家谈谈多人vc程序,界面、代码怎么分工,以及,每人写的代码怎么集中到一个程序中去,请大家积极讨论,希望对大家都有好处。你问界面,代码怎么分工,其实就是用过接口(C++里面用抽象基类来模拟)来隔离界面和逻辑。
根据tdd的经验来说,更多的是一个个story,从逻辑到界面的实现都属于一个story中。
一般的流程尤其是小团队来说不需要过度设计,就是应该用xp的方法
大方向定好->story->unit test->coding->Refactoring
当然还必须的就是配置管理,
你的团队中使用了版本控制吗?
使用了持续进行集成测试吗?
使用了每日构建吗?
使用了bug管理吗?艾,很可怕
把造房子那套拿到足球场上肯定是不行的,就像中邦
拿到软件开发上,那就更不可能了
会写代码,会实现功能到做产品简直就是十万八千里
作为朋友,我劝你一句,静下心里,把门关起来,把基础的东西做做好再来做软件,不差那么点时间,我感觉你们还没到要做软件的火候,真心的劝告千万不要拿一个不能保证质量的东西出去SHOW,否则shame on you!
没必要分的那么细吧
用CVS统筹管理就可以了
那么可以放在DLL里,做成COM也不为过
就是用一个web.config来配置举个例子来说
语言设置,这样一个功能在多数的软件中都会出现,我指的语言切换可以参考7zip(sf.net)这种
所以我们可以考虑将这块抽象出来进行开发以便复用,同时方便更新维护
那么可以将这块内容放入到一个DLL中,当收到切换的动作时调用DLL中的方法来打开更换语言的对话框,当对话框关闭时通过接口将更新的数据给exe,我说的不太清楚,其实就是DIP依赖倒置。目的就是为了让语言切换DLL与EXE解耦,依赖于接口,以便复用。exe只是负责根据配置文件进行响应的dll加载工作,根据相应的接口来操作具体的实现方法。
也可以理解为ultru-thin EXE通过抽象来解耦!
建议你看看asp.net会有启发的
对于代码,最好用接口函数的方式实现,拷贝调用也方便;
如果多人同时要控制一个程序文件,灵活+小心运用VSS也是非常方便的;
多人编程,最好有个中间模块实现Set()/Get()的变量控制,这样也很方便;一点体会而已
看来你的理论知识很扎实
你如此的描述就是com的概念了,做成com
只能部分,比如写成COM,写成无界面的某些功能模块。
[前提是使用MFC,如果是java的话可以用jemmy对gui进行自动测试]
没有自动化测试就没不可能敏捷,换句话说就只能按照过去的那套老办法来做
不说完全不能保证质量,但付出的成本绝对要比想办法分开逻辑和界面大得多话又说回来,如果想要让逻辑和界面分开的话,我认为用测试驱动是比较理想,可行的办法
因为你要实现某个功能你就要想办法先能写出自动化的单元测试,然后写出逻辑,最后才是界面,我在MFC面前也只能妥协,不对MFC进行测试,但要想尽一切办法尽可能的来做隔离逻辑和界面的工作,有时候需要花很大的力气来写MockObject,但比起质量来说,这些是值得的,是显得微不足道的。
更想知道的是如何剥离界面和代码的工作。这个问题我认为理论上是办不到的。(除非美工本人就具有较好的程序素养,勉强能做到)
你们说呢?
1、设计的时候首先想到逻辑分层,比如最简单的就是楼主所说的界面层和业务层。
2、虽然个人觉得程序设计编码人员和测试人员要求的素质很不一样,但是因为设计和测试的映射关系,好的设计必然可测试性高。
3、可重用性也是比较基础的软工概念。重视可重用性的设计可能在设计和开始编码的阶段工作量比较大,但是从总体上看,确有事半功倍的效果。
我上CSDN才五天,问了十个傻问题(在我自己觉得不傻,但大虾们肯定觉得傻)
感觉写代码的人还是挺团结的,而且乐于助人,总之让人觉得爽.
现在我的可用分已是0分(问完啦),得再申请一个帐户才行啊
1、在论这个问题的时候,我们首先要考虑语言的特点。C++、MFC、Java这些语言都是有一些实现、封装上的细微的差别的,这些差别往往造成在使用这些语言解决同一个问题的时候,使用的模型、方法、方式上的不同。
2、其次要考虑需要解决的问题的情况。问题的复杂程度往往也是让人在选择实现方式上需要考虑的一个方面。如果解决一个很简单的问题,你能说使用MFC就差于你使用C++强制的将UI和逻辑分离的实现吗?有时候还是需要考虑开发的成本和开发的熟练程度的。
3、再一个就是需要考虑系统平台的因素。不同的OS决定了一些实现上的难度,退而求其次,躲过一些技术上的难点也是开发成本中需要考虑的。
世界上没有绝对的对和错,一切都需要看客观情况而定!
我觉得很多人都太浮躁了。
在mfc底下我们根本就鲜有好的范本可以参考
我用mfc几年看的书无非就是深入浅出,advanced windows,c++ primer还有什么呢
当然还有C++对象模型这类的,很容易的就深入到系统、语言的层面里去了
恨不得搞汇编,搞反编译但事实上我们接触的更多的还是应用软件开发,更多就像楼上说的erp,呵呵
的确,怎么写都是可以的,就像有的人编码是为了事业,有的编码是为了口饭
这种事也不能强求的
因为nonocast而出彩