J2EE团队开发经验？？

一个人做倒也是一种解决办法，如果，其他实施人员工资给我的话。：）
可惜，我们的PM不让我一个人做，让我当什么实施组长，带着几个java、jsp都是刚刚接触的实施人员，累死了。
上面老是催进度，对下面又要做技术指导，帮助调试程序，本身我还有ejb和中间层的程序要编，再加上设计又经常发现有不合理的地方，还要跟设计人员商榷是否改动设计，您说我能不累死？

你用mvc模式的话，jsp基本上没有什么内容，如果页面做好应该很快的；中间控制层当然要等ejb完成后才能开发的。

做单元测试极其重要，首选JUnit，不过你的测试理念可能需要改变，就是不再是写完代码在测试，而是先写测试类，然后边写代码边测试，养成这一习惯带来的优势是显然的。我觉得你这样按层次分工势必带来接口衔接上的困难，若你的项目时间仓促，强烈建议按功能模块分工。首先生成全部EntityBean，然后一个模块从SessionBean到MVC全由同一个程序员负责，这样接口衔接上的效率大大提高（除了模块与模块之间的接口），坏处就是一对程序员的要求较高，不同层的技术都要掌握，二是每个程序员对构架的理解可能会有出入，造成维护上的困难。这就靠你来权衡利弊了。

我认为ZeroC(笨小孩)说的有道理。我觉得团体开发中，接口的设计很总重要。接口确定了，可以开始的功能可以简单一点。比如做一个财务报表的模块，虽然中间的实现很复杂，但是结果只是一张报表。那么，在合作开始的时候，对客户端的请求，只返回一个或几个特定的报表，这样，相关的其他模块就都可以同时进行了。

我上个月开发过一个项目是jsp+ejb的,我负责开发jsp部分，开始以为做jsp部分速度应该比ejb快得多,结果发现不是那末回事，做ejb的只考虑他们的方便，在编码时，原来定好的接口一改再改，害的jsp页面改了好几次,所以我很赞同上面的观点，最好jsp+ejb一起做

要ejb与中间控制层开发协调起来是有些困难，一个问题是时间的控制上，另一个问题是调试问题，能不能用桩模块来暂时替代，至少可以区分问题出在哪一块。

为什么要做成ejb呢，接口改来改去，一看就不是为了重用设计的，还不如开始就不用ejb，然后在代码的重构中再用。ejb本来就是支持连接多个事物，分布式的交易安全性。不要乱用。

支持cybercell() 的说法。在项目开发前期应该多花时间在接口设计方面的工作，这样后来的开发工作才能同步和按计划的进行。如果开发过程中有问题再进行讨论修改。但是你的公司竟然用JAVA新手来做项目，还要边培训边干活，实在想不通啊。那样还不如用别的技术而不要用J2EE这种对开发人员要求较高的技术呢。

我们以前可是一起做，EJB+中间层＋JSP，蛮好的嘛，问题是大家开发模式要差不多就可以了！

同意 coaa(我吃多了) 的说法。我们也是这样做的。

先规定好接口，减少改动代码的机会。
先写好中间层，这层相对简单，然后同步展开ejb和jsp.
譬如做jsp测试的时候，如果ejb没写好，可以暂时塞一些假的数据
入中间层而不是通过ejb访问，这样可以做一个大概的测试，当然
仔细点还是等以后ejb写好啦。上面谈到junit做测试。
我曾经看过一些资料，当然没有太多深入的研究。虽然这个架构很好，
可是暂时对ejb/jsp/servlet的测试还没有很好的方法。
而且这个架构比较多都是基于断言(assertiong)的测试，
那么譬如我一个函数在函数过程中执行了一系列逻辑操作，这样
的测试似乎还是不能进行。

JUNIT TEST确实很早就听说了,但自己重没用过,有那位熟悉的朋友介绍介绍!

关于JUnit,我赞同前面Washine(鸟王) 的说法，关键要养成“先写测试类，然后边写代码边测试”的习惯。一开始你会觉得再浪费时间，他其实是通过加强项目开发时的测试（而不是程序编完了再来测试）来保证系统的可靠稳定，而总体上项目的开发时间也不会增加，同时加强了项目的可控性。
详见：http://www.junit.org/

看了几天JUnit的资料了，可就是没有用到现在这个项目中去，项目已经做到一半了，没办法。

我觉得EJB的接口设计非常重要，其实归根结蒂是整个项目的详细设计，EJB的接口是针对客户端来设计的，如果能够达到这一步，EJB的开发人员只要确保整个程序内部最优就行了，也就是说写EJB的人的水平必须要好。

多谢，又了解了java多些的东西，java学习中。

改变开发习惯,系统可已分层,作开发为何不分层?
为每个层定义输入/输出参数,各层的开发小组严格实现,不就可以确定问题的所在吗?
j2ee 的体系结构非常优秀!

I attended a show of rational software about Java application in Montreal last week. It provides a new software suite by which we can test jsb/servlet/ejb without any additional codes and has powerful function for test management. It very suitable for team development and test. You suggest you guy try it.

我觉得设计很重要，尤其是详细设计的详细程度
这样设计人员才能基本和coder分离，交互比较少一些接口设计好，定义好。这一句话很好说，但具体做到的没有多少（我接触的项目）概要设计和详细设计比较完善，写代码相对容易多了！当然这样设计时期的维护量也大大增加，改动一个地方就要维护很多文档----因此我理想中的文档是少而精干，但又要全面的（有点矛盾--但一个项目的设计尽量使用同一工具可以使用，比如rose等，可以达到这一点）
如果各层的开发人员不同
那么接口中输入输出部分必须定义详细，尤为重要
偶以为

我的看法：1，开发分工模式是纵向还是横向？
纵向的方式以模块功能分，从ejb到mvc都要管，这样的好处是在于业务熟悉，
接口实现和调用的协调也比较容易。缺点在于需要熟悉各种技术，对程序员
的要求颇高。赞同Washine(鸟王)的大部分说法。最后一点有不同意见，不
一定所有的程序员都要非常熟悉构架，可以用设计规范来约束程序员，不一
定要求他们理解，但是要求他们遵照，这样在开发过程中培训程序员也是可
行的。
横向的方式以设计层分，一部分人只专注页面逻辑，一部分人管后台的业务
逻辑。这样分工明确，从coding的角度说效率高了。不过在接口的设计和使
用就更需要协调。
我们希望接口应该在编码前就基本冻结，可这是不现实的。虽然接口变动是
代价很高，可是如果客户需求在变，接口也有可能跟着：（
2.调试
我觉得页面的调试没有必要真的等到ejb接口正确实现。我们现在的办法也
就是模拟数据对象来测试。
junit我用过，经验还浅，我觉得在代码急剧变化的时候，为了写testcase
工作量几乎double，很是痛苦。jbuilder7集成junit还可以，不过怎么用
test suite我还没时间研究，请方家指点！[email protected]

to Brain(无缺公子)
国内的情况，很难照搬美国的模式，严格按照架构师、系统分析员、系统设
计员、编码员来组织开发。
原因一，没有足够经验的构架师和成熟的PM，
原因二，没有大量的编码员。
原因三，像你我这样的本科程序员心比天高，难沉下一条心专攻一种技术。呵
呵，要你两年全写jsp页面，你干不干？

国内有哪些公司做EJB的开发呢?我想去工作学习.

你忽视了J2EE角色中一个重要的角色：系统配置管理员。
各个组件是通过他来装配发布的。
他通过查看XML文件来了解各个组件的特性和接口，然后炒出一桌好菜。

to: alink(阿林) 急剧变化不止test case工作要double,代码也是,以前的测试(集成and单元)也是,相关文档也是如果你们的团队可以随随便便的让代码"急剧变化",只能说明你们的测试文档做的实在太少,测试文档变化的代价不能大到让你们放弃急剧变化如果客观条件逼着你急剧变化,不得不接受的话,那么测试文档的工作量你也只得接受就怕这种只知道变代码,而放弃文档和测试工作得思想

jew (木鱼) ，是高手啊？呵呵，有么有email？
应该是，先写测试类，然后边写代码边测试ejb组件的开发，我感觉是不能让。。

其实J2EE也仅仅是给我们做了一个大的，范围很模糊的架构，具体实现还是应该结合具体项目而定，参照一些经典的设计模式，比如Proxy,Abstract Factroy,Decrotor,Composition等，还是可以达到较好的灵活性，易维护性，健壮性，推荐书籍：机工《设计模式-可复用面向对象软件的基础》

调试易

J2EE团队开发经验？？

解决方案 »