[讨论]三层模式开发的团队分工问题

1.有些时候开发的形式，并不是最主要的问题。这跟你的公司文化，或者开发传统，管理模式有关系。渐进是的改革是一个好的选择。
2.开发中最主要的问题是职责，这个主要是对事情（不是针对个人）。比如说需求，设计应该到达什么程度算是一个阶段，如何测试，如何集成，怎么算是完成，完成的好坏等等。一个人作还是几个人作关键是事情要做好。
3.很难找到一个很好的方法，需要自己逐渐的摸索。可以看看PSP，TSP，XP中一些建议。逐渐实施，切勿全盘照搬。
4.三层应用最难的地方就是如何作才算三层应用。主要要回答这两个问题
a.业务逻辑是否分离。
b.你的应用是否可以分布。
5.其实模块的复用是个比较高级的目标。关键是不是能够适应变化，然后才是复用。一点点拙见。

底层和中间层独立开，实力较强的担当，先设计好想到的模块，客户端与中间层的联络有专人写，就是公用类和方法与中间层的沟通，这里是关键，要经验丰富，客户要求高的话，底层一个procedure和triger都不能写，所以地层没什么，中间层和逻辑构架关系紧，客户连接层和编程技巧联系紧，界面层和审美能力相关，最好让天天摸发油的小年轻担当，比老的利害，有思想，

三层到底是指,技术上还是架构上,
如果是clientdaset->RemoteModule(ado)->DBS,算3层吧
客户端全是调用server的接口方法

michael_king(戴着戒指)的意思应该就是中间层及服务器端直接抛开模块划分的形势，找专人开发。这当然是最好的，但是有一个前提，就是这个开发队伍已经形成一个成熟的梯队，分工比较明晰了.如果现在开发队伍还没有形成这种成熟的梯队呢？就是说停留在按模块划分任务，程序员从调研到分析到设计都参与的开发梯队该如何转型？大家水平都差不多呀.

多建几个datamodule名字取一样的，各自做好分好的基本数据访问，到综合的逻辑部分再拼起来，客户端多些人，各建一个public单元访问中间层的方法，如果人多的没处用，就搭些窗体的模版供继承用，这样分格一至，好。

我公司是很少，開發人員才4個人，在開發這樣的多層架構的程序時，我們隻是在架構上區分為：clientdaset->RemoteModule(ado)->DBS（MS SQL）,主要分工為：一個人主要負責DBS（MS SQL）數據庫的維護及建立，還包括做RemoteModule 把數據引出來，一個人主要做界面，如背景圖、圖標、及說明書、Help等各種文檔，剩下兩個人主要寫ClientDataset 。並在規定的時間內合並，測試。咱們也坐下來聽聽

To:BlueTrees(蜗牛)
you说得很对，“千军不是那么易得，但一将更难求呀！”，我们现在是大家伙一起摸着石头过河，三层这东东没有一个真正意义上的领军人物，按层次分工很难。
多谢各位参与，请继续，分不够到时再开一贴200分。

蜗牛说的是一个非常经典的问题。呵呵如果可以实现的话。我建议那些高手再写一个象vcl或是Clx或是MFC一样的东西，让我们大伙来用。

非常同意yuanjunjing(※挪威森林※) 的观点，3层的问题最主要的事一定要设计的好，也就是所说的，需要一个统令大家的人，能做好协调和分配工作。同时把各个模块分给不同的人来负责，从调研，具体设计，都由这个人负责，来完成。模块的重用性很重要，一个好的模块不但控件的名称要用重用性，而且要多留几个接口，方便以后的时候调用，也利于扩大适用面！

catthunder给我回的短信息，贴上来给大家一起分享:
--------------------------------------------------------
这种模式有什么好处呢?
  1.解决各个模块间通讯的风险.各个模块间通讯的风险其实也就是各模块负责人通讯的难题。当大家都忙着写自己的模块，没时间来和其他人沟通时，问题就会出现。但现在因为每一层的设计和编写都涉及这一层开发人员的共同努力，大家集思广益可以开发出复用性比较高，模块间通讯比较统一的系统。
  2.开发效率.因为各人专注于统一的编程方法下，写Business service就一直写  Business service,写Data service的一直写Data service，多写几个程序以后，开发速度相比第一种模式会大幅提高。
  这种模式有什么不好的地方呢?
  1.这时层与层之间的通讯就成了风险了。但是我觉得这不会成为困扰你们，因为层间通讯要比模块间通讯好处理多了。大家是开发人员，对技术的理解要远超过business的理解。所以模块间通讯的风险（也就是business的风险）一旦降下来，那么层与层通讯的技术风险就很容易被你们解决了。
  2.测试和写程序的风险。如果大家经常用R&D用惯了，会产生依赖情绪，好象写程序如果不是从界面开始就会不知所措。测试也是这样，好象没有一个好的界面，就不知该如何来做测试。我以前转变时也会有这种困难，后来写过一两只程序以后就水到渠成了。
  3.再就是学习曲线的问题了。大家都在新学，技术风险肯定要比平时大，如何让团队能很好的面对学习时的困难和开发方法的改变将很大程度决定项目的成败。
  希望听到你们更多的消息和喜讯。

catthunder给我回的短信息，贴上来给大家一起分享:
--------------------------------------------------------
不知你们会不会采用MTS技术？会采用什么样的开发工具?不知你们的设计做到什么程度了？
    我想三层架构的好处是效率，如果采用一般的c/s架构，那三十个用户同时上线就会使速度下降很快。因为一般的数据库，哪怕是oracle，连接超过三十个用户，效率有成很大的问题。
  三层架构有好处，但切忌做成两层架构似的三层架构，那样对效率的改进没什么好处。所谓两层架构似的三层架构,就是指原来写在客户端的逻辑全部移到应用服务器端，造成一个个巨大的应用服务对象(大家徒省事一般都会这么写,^-^)。要写三层架构一定要重新规划系统设计，我想采用OOAD的方法应该是比较好的.(当然也要看系统的大小和开发的时间压力)。
  如果我没猜错，你们的开发模式会是
  A programmer 负责 A module(包括UI service,Business service,Data service)
  B programmer 负责 A module(包括UI service,Business service,Data service)
  我建议你改进成
  A programmer 负责 Business service
  B programmer 负责 Data service
  C programmer 负责 UI service
  这种模式.

To catthunder:
你所说的　Business service、Data service、UI service
具体指什么，不同的人来负责，是否会缺乏全局的观念而导致问题？

To chenooo(起起落落来来去去的风),
  Business service是指商业逻辑
  Data service是指数据访问和提供
  UI service是指界面

To catthunder:
对Data service是指数据访问和提供　和　UI service是指界面
都有了概念，但对　Business service是指商业逻辑　感觉还是比较模糊，没有实战经验，在设计时如何对这东东进行规划呢？
望不吝赐教。也希望大家一起讨论。

其实做三层开发最主要的是系统级别的把握：在我们公司这里，已经完成形成了一个工厂化的开发模式！在上个月我们做一个系统时，我们首先是在做设计，由公司的高级系统分析员，设计人员已经程序员来设计，程序员参加！这样大家在一起讨论时，程序员（最后的代码书写人）就对系统比较清楚了！注意在设计阶段时：最主要是以下几个工作重点：
  1：分析提起整个系统的公共部分
  2：系统之间的各个类之间的联系这样在程序员开始编码时：我们是这样做的：  根据产品定义和系统设计文档所有的程序员（15个）一起画界面--每个人估计10个的样子！在初步的界面画完之后，由公司专门的界面设计人员来美化界面！  在画完界面之后，整个系统就开始写代码！  这个代码的写法是这样的：Business首先写完！  在这个过程中，所有的借口都是根据设计中来实现！包括对数据库层存储过程的调用！  在完成了Business之后，系统完成界面的调用！
  整个系统就算完成了！
  至于整个系统的整和那是系统分析院的事情了！  对程序员来说：只需要管自己的代码的调用的出口参数和入口参数！  其他的没什么了！
  我觉的这个方式很好！
我们公司就经常出现系统分析员在一个大厅中走过来走过去！
程序员在底下写啊写！效率很高的！

要做一个成功的系统，系统分析是相当重要的，如何抽象出Business　service　我想更是三层架构的重中之重了。有经验的朋友能否说说经验之谈？

个人观点：客户端由几个有网络经验的人写、写中间层要有com+的经验，数据库的维护和开发不必投入大量的人，关键是要有数据库方面的高手。总体当然要多次交流并有项目经理协调开发。

NewDelphier(我是新手) :
你在什么公司？我要投奔你老板!!!

visual C++ 里有一个Visual Safe Source工具 is perfect to do this!

小一点的系统可以大概分为:
   Business service
   Data service
   UI service
   大点的系统可以大概分为:
   Business Rule    ----商业规则
   Business Facade  ----采用Facade模式，减少应用服务器端对象间的耦合度。
   Business Data    ----商业数据
   System   FrameWork  --整个系统的框架,如系统的配置等
   Data     Access  ----不用说，数据访问
   UI               ----用户界面
   第一种应用COM+基本就能很好的实现。如果要按划分，可能非得java或.Net才能适应。
   分工采用横向按层切的方式,而不采用纵向切。
   纵向切的风险是商业风险或称需求风险，而横向切是技术风险。对于开发人员来说，技术风险要比需求风险来的小。
   负责Business层的是那些对商业逻辑比较熟，能很好理解分析设计结果，并提出意见的人。
   负责Data层的是那些对数据库技术比较熟的，特别是对于性能方面有深刻理解的人。
   经过这样的分工后，就可安排那些负责同一层的人坐在一起，方便他们沟通。
特别是那些负责Business层的，让他们在一起合作是项目成败的关键。

深有同感，同志们可以看看以下链接：http://www.delphibbs.com/delphibbs/dispq.asp?lid=1206721

事实上，三层模式开发一般是将视图、商务逻辑和数据进行分离，提高软件的易维护性。
在需求分析结束后，可以由系统架构工程师进行系统架构的选型，将视图、逻辑与数据进行分离，设计三层之间的接口，然后分别由相关的人员进行各层之间的设计。
视图层主要为用户提供统一的视图框架，保证整个系统对于用户的友好，界面的统一。其中对涉及到商务逻辑的部分调用相应的接口。最好由系统分析员、程序员和美工来实现。逻辑层主要是对具体业务中的事务处理进行涉及与实现，实现与视图层的接口。确保当商务逻辑发生变化后，的商务逻辑的变更不至于影响相关视图和数据层的实现。这部分由系统分析员和程序员实现。
数据层提供对于数据操作接口的实现，将处理逻辑与数据库进行分离，保证当数据库的变更不对商务逻辑产生影响。这部分则是DBA和程序员的工作。进行分离的结果是对各层的变更相对于其他各层是独立的，这样当需求并不完全清楚时，对用户的变更请求的反应成本相对较低。一些愚见，望诸位高手指正。

先做横向划分，总体规划
再做纵向编程，分组细化横向重在系统性详细设计文档，
小组利于深入开发。我曾经在华为开发时这样做过，
开始感觉慢，后来写代码时发觉，
效果又快又好，而且很规范。
基本很少BUG,出了错都是在函数里，
很好解决。
仅供参考！

我们的分工dba:1人
商业逻辑层：6人，每人2个模块
每个人负责每个模块的界面，组件，访问的分析，编码等工作。项目经理负责整合整个系统。

duwamish的例子不错大型开发推荐
小case的话,petshop

ketao_78(春来江水绿如蓝) 说的问题是个问题，“有些问题是在具体编程的时候遇到的，怎么避免这些问题”，我一直在想也一直在找答案，如何能解决这个问题？
也许系统设计作细，甚至系统设计人员等人将伪代码写得尽量详细，保证系统设计的可实现和被正确实施，但还是会出现一些突现的技术难题，有些可能是事前试验是可行的技术方案，真正用起来才发现行不通或在某些环境下会出问题，而这些事先的试验环境下是不能或很难发现的，有时就不得不对最初的设计作出调整。
有经验的前辈们，是不是对付这些问题有什么良好的应对方法？

具体的角色分配或是职责分工,应该根据开发团队的规模,开发具体阶段不同而有所不同,我认为一味使用各种CMM或ISO管理模式,而不注重具体情况是行不通的,这里面起到决定作用的应该是项目负责人.

调试易

[讨论]三层模式开发的团队分工问题

解决方案 »