分层与分模块开发

分层与分模块开发,是开发时经常选用的两种方式,应该说分模块开发是较多被采用的方式,但一直以来都觉得其实分层方式自己是比较欣赏的方式,对于两种开发方式分别的看法是:
分层开发
优点:
1、保持系统分层结构
      分层开发在这点上无疑是可以保证的,同时有利于保证系统层次的职责的清晰以及分离。
2、面向接口的编程
      由于采用分层开发,各层次之间采用接口依赖的方式就更容易被执行了。
缺点:
1、容易造成瓶颈现象
      由于分层开发各个承担人员的任务难度不一样,很容易形成瓶颈现象。
2、对于系统设计的要求更高
      这点应该说不能算是缺点。
3、容易出现扯皮现象
分模块开发
优点:
1、系统功能更容易被完成
      由于采用分模块开发,开发人员从头到尾负责,一定程度上来讲减少了沟通以及协调成本,使得系统功能能够被更容易的完成。
缺点:
1、容易造成系统的分层结构缺失
      通常在项目实际的赶工情况下,很容易形成系统的分层结构缺失的情况,开发人员为了完成功能完全不顾分层,不顾层次职责的分离的保证,这点在实际的项目中往往不是那么好控制。
2、面向接口编程的贯彻不力
      这点也通常是由于上面的原因,当然,其实这里面最根本的原因是开发人员本身的素质不够高....

在开发人员水平参差不齐的情况下,我认为分层开发方式更有利于保证系统的质量,尽管在具体实施的时候可能会碰到一些问题,希望能听听采用过分层开发方式的朋友们的看法。
 

posted on 2006-03-19 21:11 BlueDavy 阅读(7244) 评论(26)  编辑  收藏 所属分类: Java

评论

# re: 分层与分模块开发 2006-03-19 22:31 fisher

很高兴又有人对这个问题感兴趣了,说说我的看法
任务分解不应该以系统功能为主视角
而是考虑以人为本

任务分解,是一个面向人而不是面向任务的过程
这个问题实际上是对系统横向切分和纵向切分的问题
很多项目管理方面的书要么对这个问题采用了一种偏致的做法
比如《PMP:Project Management Professional Study Guide》中采用纵向分解方法并罗列了很多好处
而有些书籍则再这个问题上捣浆糊,如WBS在这个问题上罗列出N种方案却没给出任何实际意见
且,很多人认为任务分解的终极目标为减少对交流的依赖

在这个问题上,我认为应该以团队特色设计任务分解方式
而终极目标,则不是减少依赖,而是让依赖可管理
即软件结构设计影响任务分解,而任务分解影响组员间的依赖关系
反之,只有符合目前团队的风格的任务分解才能高效运行,而该任务分解将影响架构师的架构抉择。其实,这正是XP中团队设计的根本原因。
这也是软件项目管理上的一个重大特色,就是软件结构设计同团队结构设计的不可分割性。也是软件开发难以实行工厂化的原因。

如果你在开始就积极的开展设计,并且把设计的过程持续下去,你的任务的划分就会成为一个纵横交错的动态的调整的过程。而应该注意的师,模块并不是任何任务划分的一个约束,而只是为不同的人协同书写相同的模块提供的一种约束。

而如果以任务为视角,无论横向分解还是纵向分解,都会在某种情况下陷入困境。
实际上,由于国内目前的软件项目普遍不大,所以对于交流的有效性的感觉并不强烈
这问题在多个公司合作开发的过程中尤为突出

  回复  更多评论   

# re: 分层与分模块开发 2006-03-19 23:02 fanta

我的经验是相反,对于不成熟的团队,分层可能是灾难吧。  回复  更多评论   

# re: 分层与分模块开发 2006-03-20 09:35 citysir

在保证分层的情况下再分模块,这有什么问题吗?  回复  更多评论   

# re: 分层与分模块开发 2006-03-20 09:35 破门

这个命题我个人认为可能永远出不了结果,只能以刀剑之争来比喻一下:究竟是胡家快刀厉害,还是苗家剑法无双?
事实上,我觉得还是应该就是论事,发挥各自的长处,最终道理都是相通的,就像胡一刀可以和苗人凤互换兵器,依然要争个三天三夜还是会旗鼓相当一样。

说白了点,为了达成目标,你长于架构可以先分层再来支持模块。如果你长于业务,自然先分模块再考虑重构系统分层。可叹的是,我们往往只取其一。做产品的,只管分层,不管应用;做应用的只看模块,不看架构。最终,都是死路一条!  回复  更多评论   

# re: 分层与分模块开发 2006-03-20 11:15 小陆

项目的初期,应该用较少的人力,设计开发系统的框架,建立底层的开发平台。这个时候主要是分层。
当这部分工作完成的差不多了,就可以大批的人上去,开发具体的功能点,直接实现用户的需求。这个时候主要就是分模块了,每个功能点都要有直接的负责人。  回复  更多评论   

# re: 分层与分模块开发 2006-03-21 17:29 guitarpoet

分层开发的最重要的特征是层与层之间的松耦合。松耦合所带来的结果是,各层之间都可以有自己的基础模块,可以实现本层内部的重用,在底层发生变化的时候(变化协议、变化技术、甚至变化介质),上面的层是可以花费很小的成本进行适应的(比如操作系统和应用程序层)。

商业开发必须考虑开放成本,而有效的重用是降低成本的方法之一。

模块化开发,估计每家做企业级应用的公司都必然会采用这个方式。拿用电系统来说,客户服务模块和电费管理模块业务差距非常大,非业务专精人员,很难在短时间内写出高效和高质量的代码(光是业内常识就有的学的,而且各处业务还都不大相同)。

fanta的话是有问题的,对于不成熟的团队,如果没有成熟的技术框架进行支持和有能力的项目负责人进行管理的话,生产的软件产品质量和工期就没有办法得到有效的保证。  回复  更多评论   

# re: 分层与分模块开发 2006-03-21 17:46 guitarpoet

@fisher

软件开发必须以人为本,但是所谓的“团队特色”是一个伪命题,团队中的人总会流失(升迁、跳槽、借调),总会有新的人加入,这是业内的常识。如果针对团队作出良好设计的人或是一个对各种技术十分精通的人被别的公司高薪翘走了,怎么办?

合格的软件公司都要有一定的应急机制,这也是对软件质量保证的手段之一。这样就不会因为某一个开发人员跳槽而造成手足无措的情况。

怎样才能 达到这一点?那就是有效的分层,有效的把损失局限在某一个范围内,就算是临时拿新人顶,他也可以迅速的接替流失人员的位置。

当然,Brooks说过:“无论怎样,项目肯定会延期”。但是要要尽最大可能的把损失降到最小。

太多的软件工程书不顾现实的情况了,完美的人是不存在的,技术全才一般是不愿意只做技术的(这个东西真是有趣啊),我们得面对现实。  回复  更多评论   

# re: 分层与分模块开发 2006-03-21 20:22 fisher

@guitarpoet

首先
以人为本!=团队特色
任何团队都会有特色,但不是任何团队的开发过程都以人为本
所以,你说的显然是个伪命题

另外,如果某一开发人员的离开对你的团队和公司有如此打击,只能是项目经理失职
同任务分解和任务分配的原理没有任何关系

还有,你提到的例子中,混淆了模块和模块划分的区别
我前面说过,模块并不是任何任务划分的一个约束,而只是为不同的人协同书写相同的模块提供的一种约束。
而模块划分,则既不是业务问题,也不是技术问题,它受到实现技术、任务和人员配置的三角关系的约束。
所以,在架构及开发任务分解这方面,没有万试万灵的灵丹妙药,最重要的是如何管理依赖,所有的依赖。所以,从技术上来说,其重点在于,架构师和项目管理者对有影响力的各个方面的动态依赖的认识及协调能力。  回复  更多评论   

# re: 分层与分模块开发 2006-03-21 21:22 BlueDavy

^_^,好多评论..

软件过程以及开发方式都是为了降低人的因素来实现项目的可控性。
虽然这点一定程度上来说已经在强调不是以人为本的问题......
分层和分模块开发,一个实际的不同的例子就是当运用在一个水平相差很大的团队中的时候,分模块很容易造成模块的质量上难以保证的问题,分层则一方面可以保证这问题,另一方面可以发挥团队中各人特长,同时对于团队成员的培养也是有很大的好处的。
当然,我的意思不是说分层的开发方式就一定更好,就像破门所说,这个是剑刀之争,需要根据不同的情况做出不同的选择..
或者可以去好好的总结什么样的情况下适合分层开发方式,什么样的情况下更适合采用分模块开发的方式  回复  更多评论   

# re: 分层与分模块开发 2006-03-21 23:05 fisher

@BlueDavy

似乎我说的太多了:)
因为我对这个问题真的感兴趣
也多次与人交流,在实践中,我发现无论哪种方法都会有问题

你说“软件过程以及开发方式都是为了降低人的因素来实现项目的可控性。”
我认为这是不对的,从管理学角度来讲,管理的目标是建立行为规范
而行为规范是用来规范人,而不是用来规范过程的

我发现技术人员总是认为以人为本是个讨巧的话题
其实正相反,在团队管理中,用人绝对是一个技术活
是要通过分析得出正确结论的。这需要理论、模型、计算以及权衡裁决
其实跟软件设计是一回事,这也是为什么管理学到最后也是数学的原因
管理不是感觉、而是技术和数学

anyway,说回分层的话题
无论分层还是分模块,你都会依赖你的团队来完成
而无论分层还是分模块,都会有不同的依赖模型
不知道我这么说是不是很扫大家的兴^_^
但我还是那句话:从技术上来说,其重点在于,架构师和项目管理者对有影响力的各个方面的动态依赖的识别及协调能力。

ps.
恰巧,本人目前正在运行中的两个项目
一个是分模块开发,一个是分层开发的。
  回复  更多评论   

# re: 分层与分模块开发 2006-03-22 09:04 guitarpoet

@fisher

也许我们的想法相似,只是表达方式上有所不同。在IT行业,熟练的团队的工作效率是要比非熟练的团队的工作效率高数十倍甚至上百倍的。

但是,别忘了,良好的分层架构、模块封装使得可以充分利用社会分工机制(开源组织、组件和工具供应商)对工作效率的提高也是数十倍甚至上百倍的(而且更可靠)。

JavaEE就是这么一个分层的概念。

管理是一门艺术,涉及到的地方就比较多了。改天我们再对它进行探讨(邮件的方式最好)。现在要探讨的是技术架构上的问题。

哪个成熟的软件公司没有自己的软件开发过程?没有自己的基础软件开发架构体系?没有自己的技术价值观?

没有这些东西,谈什么公司开发文化都是妄谈。  回复  更多评论   

# re: 分层与分模块开发 2006-03-22 10:46 破门

@fisher
“在实践中,我发现无论哪种方法都会有问题”,完全同意!:)
因为实践中没有哪一个项目是完全相同的,所以我说,分层与分模块只是技术,不要把它们当做“银弹”。
实践是门更深的艺术!
所以,选择技术架构、路线和管理手段的方法完完全全来自你面临的实际情况,你的项目目标,你能找到的资源,你所在的管理环境等等.....
因此,讨论任何一门技术方法的时候,不能只讨论技术本身,千万不要忘记了它们适用的场景,否则,太容易带来误导了。  回复  更多评论   

# re: 分层与分模块开发 2006-03-22 12:39 BlueDavy

@fisher

^_^,觉得你误解了我所说的
"软件过程以及开发方式都是为了降低人的因素来实现项目的可控性。"
这句话所表达的观点和你所说的
"行为规范是用来规范人,而不是用来规范过程的"
是一个意思,都是为了降低人的因素造成对项目的影响。

呵呵,比较想知道你现在分层和分模块开发的两个项目目前进展来看,你觉得两者更为适合的场景是?  回复  更多评论   

# re: 分层与分模块开发 2006-03-23 13:25 fisher

忙里偷闲上来看看^_^
接jerry的话,我也会来说说我的项目的情况

其实我觉得分层或分模块的说法并不准确
何谓分层?何谓分模块呢?

咱们先绕开这个容易引发争论的定义,来说说实际情况
在J2EE应用中,似乎分层是很自然的想法
简单的说,我们要分:表现层、逻辑层、持久层
然后分模块,则是一个人负责一个功能模块,贯穿所有层

现在,我们来跳出J2EE领域,看看软件开发其他领域是什么样的
比如,一个电信基础业务系统开发
我们假设,包括语音平台、帐务平台、后台主机系统、前端接入系统、计费平台、业务管理平台等
在系统设计中,我们分为语音模块开发、帐务系统模块开发、主机通讯系统开发、前端接入系统开发、计费及业务管理系统开发
那么这是分层还是分模块呢?
显然,一个人做一个业务的全套处理是不可能的(我很想结识能做到的xd),所以,这不会是分模块开发。
如果说是分层,那么逻辑层在哪里?持久层在哪里?另外的问题是主机通讯系统将会贯穿始终,这应该算哪一层?并且帐务处理会使所有层的数据产生强烈耦合。

同样的问题,出现在银行综合业务处理系统
一个银行综合业务处理系统中,我们分为主机系统、主机客户帐分录系统、IBS系统、柜面系统、电话银行接入模块、ATM系统及接入模块、网银系统及接入端点模块
下面我们来分一下层,按照J2EE的惯例,我们分为表现层、逻辑层和持久层
首先表现层为所有接入模块及柜面系统、逻辑层是什么呢?IBS?客户帐系统?还是主机系统?那么持久层呢?按照银行开发的情况,一般来说,数据分别存储在Host,客户帐系统、IBS和网银上。那么我们显然不能够分层开发
那么所谓分模块呢?哦....我还无缘得识这样的朋友

所以说,分层还是分模块,不过是J2EE中的一个idiom
从软件开发出现到现在,软件开发的重点仍然是依赖管理,清晰的接口(无论是java中的interface还是c中的.h文件)使得子系统(无论是一个模块还是一段代码)的开发人员可以只依赖与接口编程,这才是团队开发的重点,如果你没有接口,你就要管理开发人员之间的依赖,如果你有接口,你就要管理接口两端的依赖。总要有个合作工作的基础,我们才能继续前进。

在这点上,似乎英文使用者就不会产生混淆,因为interface这个单词代表了所能表示的所有交界处。而中文,我们有人机界面、接口、交互、分界面、接触面等N种解释

用J2EE的眼光看软件开发,自然什么都要套到J2EE的模子里去
简单的说,手里那个锤子,看什么都像钉子:)

我在上面所说的分层、分模块开发的两个项目,都是部分分层、部分分模块的情况,如同我前面所说,是一个纵横交错的动态调整过程。
分层,也就是说的那个J2EE项目是在大原则是分层的情况下,实际开发中做了许多调整,项目做到最后,也不能说是分层还是分模块了:),把一个人硬按在一个位置上,他是不会产生高效的
而另外一个,则是一个银行综合业务处理系统。  回复  更多评论   

# re: 分层与分模块开发 2006-03-23 16:28 guitarpoet

@fisher

其实你混淆了分层的概念,分层开发就不能分模块了?

分层开发是一种开发方式,目前而言,这种开发方式是非常适合企业级应用的。

但是,它并不与分模块的开发方式互相矛盾。你把系统根据业务分成相应的模块以后,还
可以根据需要进行分层开发的。这同样可以体现出分而治之的原则。

对于公司而言,应该有一个开发人员遵循的统一标准,然后这一个标准还要根据工程和业务模块的需要进行相应的剪裁,你总不希望各个工程和各个模块之间开发没有相同点,开发方式各有不同吧,如果真是那样,你怎么实现项目之间人员的调换?你不能实现人员的调换,怎么保证项目一定可以如期完成?

分模块是必须的,但是应该建立在良好的分层的基础上,否则软件质量的管理不可能达到公司的级别,只能依赖个别优秀的软件开发管理人员和项目架构师,这对一个公司是有风险的。

JavaEE之所以流行就是因为它不是简单的工程师文化,它代表了商业开发的概念和标准,相对而言.NET的工程师文化可能更强一些,但是它们是典型的骑墙派(没有贬义),从C#语言的频繁变化就可以看出来了。

工程师更喜欢概念上的东西,但概念不等同于商业。  回复  更多评论   

# re: 分层与分模块开发 2006-03-23 23:03 fisher

@ guitarpoet

我的意思是说,不要拘泥于分层开发还是分模块开发
而是要认清为什么要分层,为什么要分模块,有什么好处,有什么弊端
以前有人问我某个设计该怎么分层,我说,理解为什么要分层就知道该怎么分层了
不要为了分层而分层
况且,分层不足以描述软件开发的根本问题,它只是解决根本问题的表现手法之一
这我在前面已经说过了
  回复  更多评论   

# re: 分层与分模块开发 2006-03-24 08:34 guitarpoet

@fisher

其实我们的想法相似,只是表达方式上有所不同,呵呵。

很高兴能跟你讨论问题,软件工程作为一门学科,现在离真正的成熟期还远,在一定的时间内,概念的争论是免不了的。

我觉得,在这种条件下,要想真正意义上的进行企业级应用开发,必须脚踏实地的采用注重实效的方法。

而且软件开发还是要以人(客户、开发人员)为本的,不管采用什么概念、技术和实现方法。

很多人都喜欢拿企业级应用类比汽车产业,其实可比性没有想象中那么高,软件开发毕竟是一个概念上的东西,与现实中的物质相比,它跟人的思想和人分析问题解决问题的方法更近一些。

古希腊的时候,人就开始对自身的概念和思维的逻辑进行探讨,但是直到现在,还是没有什么有突破意义的结果。

软件开发更接近于哲学,这就是为什么编程高手一般都非常喜欢古典哲学。

其实,技术哲学也是哲学的一种啊。

计算机科学的发展,最后应该是跟人类的哲学的发展相互依存的。

马克思说的真他妈有道理。  回复  更多评论   

# re: 分层与分模块开发 2006-03-24 11:58 pb

我理解,在目前的中等团队—— 20人左右——情况下,对于一个超过20*60人天的项目,分层+分模块
分层:对于这样一个项目,必然会有其技术要求,会抽取出来很多通用的、底层的、全面的功能或者服务出来;那么,对于这些部分,技术要求比较高,设计上也许要更多的通用和健康,所以需要几个高手来把握
分模块:在此基础上,根据业务功能模块分成若干小组进行业务层面的开发。这里,对于技术的要求比较不苛刻,大部分人可以胜任
如果在此基础上,还有富裕的人力 —— 可能是工作量上的富余 —— 可以把界面和业务层也分开

总之,希望是一个金字塔的形状  回复  更多评论   

# re: 分层与分模块开发 2006-03-25 18:47 fisher

@guitarpoet

^_^  回复  更多评论   

# re: 分层与分模块开发 2006-12-07 15:05 eddy

看到大家谈得这么投机,我也上来说两句!
我个人是偏向分层开发的,但并不是说分层开发一定比分模块开发好,就好比OOP,AOP一样,它们都是各有优缺,其实也不是优缺,只是具体使用那种开发方式要根据多个方面来决定,第一:项目需求,第二:人员配备;第三:团队.

首先,从项目需求来说,要是一个小项目,完成就好,基本不要维护,那么建议用分层开发,反之,如果是一个银行,电信核心系统.它在设计的时候都不知道会被什么人使用.必须提供完善的接口规范,那么建议使用分层开发,保证面向接口编程,为重构提供可能!
其次,说到人员配置,如果team中每个人都是junior developer,不能提供出成熟的设计,那么建议使用分模块开发!因为分层开发对系统框架设计的要求比分模块开发要高!如果team中有几个设计方面的告诉,能够保证系统设计的成熟,稳定性,那么分层开发是必然的选择,何必放着这些高手不用!让他们做junior都能做的事呢?
最后,说一下团队,从团队稳定性的角度,我建议使用分层开发,原因有二,第一,分层保证多人(大于2人)了解同一个模块,即使走一人,其它了解这个模块的人也可用接上手;第二,人尽其才,从古到今,都是这个理!

顺便引用网络的上一段话,我觉得挺在理!
"大家不妨想一下,微软自带的例子,都是分三层,四层的,这意味着什么?好处肯定是有的,否则就不会带这个DEMO给全世界用.NET的IT人员参考啦,就不会放在MSDN中!"  回复  更多评论   

# re: 分层与分模块开发 2007-03-23 15:41 ramon

好久以来我一直都在考虑层与模块的关系,但是从来没有把它们和项目管理挂起来, 我一直觉得它们是属于系统架构设计中的概念, 所有就老纠缠在到底是层包含模块, 还是模块包含层这样的问题中,困惑了许久,今天看到大家的讨论,获益匪浅, 层应该是从架构设计的角度来看 ,是对系统的纵向分解,而模块应该是从功能呢个角度划分,是对系统的横向分解。 模块与层应该是一个垂直正交的关系。
那么在实际中,我觉得分层加分模块比较合适, 比如在一个较大的项目中,定义了表示层,逻辑层和持久层, 我可能愿意只在逻辑层和持久层分模块,表示层可能就交个一个专门的team来开发,必经表示层的开发和后端的开发需要的技术知识领域是有差异的。。。呵呵,随便说说,欢迎大家指正。 因为这个问题实在困惑我很久,又找不到什么资料, 不知道有没有朋友介绍一些其他的关于这方面的经典文章。  回复  更多评论   

# re: 分层与分模块开发 2007-05-24 15:04 jallock17@126.com

看看上面大家的发言,确实是些强人。
那我就我的想法说说:
不管你采用哪种方式开发,都应当基于人(用户、开发人员、管理人员),然后综合考虑项目因素。具体一点说:
我认为,我们大部分开发人员老是基于自身的角度去想应该怎么开发合理,
如果我们换个角度去想想:项目时间不足够,项目资金不足够、没有足够的需求调研、市场因素等综合考虑,你会发现有很多问题我们开发人员太过理想化。  回复  更多评论   

# re: 分层与分模块开发 2007-05-24 15:24 jallock17@126.com

软件工程,流程的开发方式,都是前人的经验总结,
需要根据实际情况来结合自身实际条件来找到一条
适合自己的路子才是最可行的  回复  更多评论   

# re: 分层与分模块开发[未登录] 2007-06-05 17:16 Marine

不懂J2EE
不过分层了,再分模块不好么?个人感觉模块是在层次之下的。每一层有自己的模块。  回复  更多评论   

# re: 分层与分模块开发 2007-12-06 15:45 huangyifu

我的经验是:
分模块开发速度快些
分层开打质量高一些  回复  更多评论   

# re: 分层与分模块开发 2009-07-30 16:23 eric土人

读这位fisher写的东西真是拗口,是不是能按照主谓宾的结构来排排语法,只表达一个观点--对敏捷里面提及的团队合作,在中国,很成问题.  回复  更多评论   


只有注册用户登录后才能发表评论。


网站导航:
 

公告

 









feedsky
抓虾
google reader
鲜果

导航

<2006年3月>
2627281234
567891011
12131415161718
19202122232425
2627282930311
2345678

统计

随笔分类

随笔档案

文章档案

Blogger's

搜索

最新评论

阅读排行榜

评论排行榜