我要被老外气崩溃了

tmd我一直都以为老外都是IT行业中的精英加高手....
最近和我们一起做项目的老外真是让我彻底的faint

我们的项目是c/s结构, 所以在规划的时候规划了四个子项目:
client/common/server/web

老外居然一直在说用一个项目就可以了, 在包名上分开. 经理跟他们解释了半天也没用.
以前我们公司的几个项目是一个大项目就做下来了, 但是调试极其痛苦, 而且有人在server端引用客户端的类. 运行的时候才发现问题.

我觉得开发调试应该尽量贴近运行状况. 如果用SLF4J的设计模式也会好办一些....

唉, 我还没想按照功能分成无数个子项目呢, 按理说将来公司的产品也应该按功能去分别部署...这个他们可能更要晕菜...

评论

53 楼 steeven 2009-05-18  

补充一下，那边的老外是在美国混饭的印度人～～
啥都不说了,我把sun项目规范blueprints找出来都没用。
http://java.sun.com/blueprints/code/projectconventions.html#65002

52 楼 dch1287 2009-05-15  

yuxie 写道

ray_linn老大不在，哈哈
其实lz的问题在Visual Studio里边很easy的，一个solution下多个project，客户端、服务器甚至安装程序都可以作为子project，而且都可以统一管理，重构什么也很方便，svn也是一颗代码树..这个貌似啥netbeans、eclipse都做不到哦

eclipse 里面类似 solution 的概念叫 working set 这只是小技巧而已

关键是离开了IDE 还是要依靠Ant, Maven这种东西来组织项目构建发布过程 所以有必要一开始就在物理上逻辑上分配好

51 楼 yuxie 2009-05-15  

steeven 写道

yuxie 写道

ray_linn老大不在，哈哈
其实lz的问题在Visual Studio里边很easy的，一个solution下多个project，客户端、服务器甚至安装程序都可以作为子project，而且都可以统一管理，重构什么也很方便，svn也是一颗代码树..这个貌似啥netbeans、eclipse都做不到哦

再瞎说就揍你！Netbeans/eclipse的J2EE开发都有类似logic, 最后打包成EAR.

vs跑这里来找扁啊

打包成EAR跟客户端、服务器端、安装程序多个项目同时管理有啥关系？
EAR里边就是WAR和EJB，都是服务器端部署的程序，差海了去了。Java有不足的地方就要多学习，瞎嚷嚷不解决问题滴。

50 楼 steeven 2009-05-15  

yuxie 写道

ray_linn老大不在，哈哈
其实lz的问题在Visual Studio里边很easy的，一个solution下多个project，客户端、服务器甚至安装程序都可以作为子project，而且都可以统一管理，重构什么也很方便，svn也是一颗代码树..这个貌似啥netbeans、eclipse都做不到哦

再瞎说就揍你！Netbeans/eclipse的J2EE开发都有类似logic, 最后打包成EAR.

vs跑这里来找扁啊

49 楼 yuxie 2009-05-15  

ray_linn老大不在，哈哈
其实lz的问题在Visual Studio里边很easy的，一个solution下多个project，客户端、服务器甚至安装程序都可以作为子project，而且都可以统一管理，重构什么也很方便，svn也是一颗代码树..这个貌似啥netbeans、eclipse都做不到哦

48 楼 steeven 2009-05-15  

daquan198163 写道

我觉得所谓的多个工程，本质上是看它是否有多个build脚本。
eclipse可以指定任意多的src目录，所以你搞一个或多个eclipse工程没有本质区别。
至于版本控制系统下，一颗代码树要简单得多。
你们的分歧到底在哪里呢？

多少个工程对ant/maven都是小菜一碟。对于maven,可能多个项目会更简单。

如果混合在一个eclipse项目里面，运行客户端会带上server端的class, 同样运行server端会带上客户端的class.
俺们server不是war, 是自己写的main方法启动。
对于俺们的项目来说，代码量很庞大。一个大项目会很笨重，refresh一次就要很久。
另外客户端打包成client.jar，依赖common.jar, server端运行server.jar, 依赖common.jar

对了，server还有一些code-gen, 不build不会有code-gen的代码出来，编译不过，客户端也跟着遭殃跑不起来。。。。。

47 楼 daquan198163 2009-05-15  

我觉得所谓的多个工程，本质上是看它是否有多个build脚本。
eclipse可以指定任意多的src目录，所以你搞一个或多个eclipse工程没有本质区别。
至于版本控制系统下，一颗代码树要简单得多。
你们的分歧到底在哪里呢？

46 楼 steeven 2009-05-15  

抛出异常的爱 写道

java7以后可能楼主的问题会少很多
原引 自 :http://www.infoq.com/cn/articles/java7-module-system

谢谢，我也喜欢看infoQ, 虽然能看懂的不多
用module方式开发，可能需要更多的项目啦～～

45 楼 steeven 2009-05-15  

举个例子，在common项目里面可能会存在一些通用工具，依赖于client/server下面的实现。就像SLF4J那样。
另外，像log4j.xml在客户端和server端可能有不同的配置。如果都放在一起，调试的时候就强制用同一个文件，方便吗？打包的时候再分开？

另外client和server端的目录结构会有不同，混合起来也可能造成冲突。

重构的时候的确会有些麻烦，特别是common更改的时候，必须要所有项目checkout出来才能实施，保证不出错。所以只有四个项目。

据说很多外包公司的项目都是两位数。。。。。

像JBoss/Eclipse/Hibernate这样的项目，里面子项目无数，咱们就不去赶时髦了。
这种一个巨无霸的项目好像在以前很流行，严重怀疑是C/C++时代的产物。

比较欣赏前面一位老兄的说法：在制度上就不给他们犯错的机会。这是人治和法制的区别。

44 楼 steeven 2009-05-15  

robbin 写道

不分项目也不见得不好。如果你分了n个项目，用到公共类库或者公共底层数据库的时候，你就非常痛苦了。我见过很多很多大型开发团队，就是因为划分子项目以后，在交叉引用上面痛苦不堪，一改公共代码，波及的范围非常广。

JavaEye网站现在别看二级三级域名这么多，还带有垂直频道，开放API，可就是一个项目，一份代码，修改和部署都非常简单，以后也会一直单项目走下去。

agree, 以前也碰到过这个问题，按照功能模块去划分项目，后来问题太多。但是C/S结构也不划分似乎说不过去。
EJB3.1允许war中存在EJB应该也是归一这个想法。

43 楼 steeven 2009-05-15  

kimmking 写道

" 而且有人在server端引用客户端的类. "

1、这是此人的问题。
2、你们需要规范。

我也在想如果能找到个规范是不是能说服他们。 Netbeans向导和例子生成出来的缺省J2EE架构就是分成这几个项目的。

42 楼 seen 2009-05-15  

night_stalker 写道

注释：

// You are not supposed to understand this.

ken说过的话  谁敢不服

41 楼 lichdb 2009-05-15  

扯淡！ 原因也许不在于分几个项目这个分歧吧

40 楼 小豆冰 2009-05-14  

老外也有3，6，9等，牛的很牛，只是极少数。菜的很菜，占绝大多数， 跟软件民工没区别。老外的办公室政治一点不比中国人少。

39 楼 intelchen 2009-05-14  

topgun 写道

dch1287 写道

可以参考一下 Spring2.5、Hibernate3.3、Tapestry5 的源代码结构
Hibernate3.3、Tapestry5(非常典型) 针对不同模块都分了不同的 project source path
Spring2.5 似乎是同一个 project source path 但是最后生成的jar却是分开的

这几个例子是怎么做到的呢？
使用Maven 来管理，一切问题就迎刃而解了

我甚至认为，以现在企业应用比较复杂的情况，一定要使用Maven 的模块管理
而且，Maven 一定要会用，用好，不要一知半解就说怎么怎么样

不一定是maven，ant也可以处理的。关键是这些脚本最初都要写好，目录结构要规划好。
老外也有低水平的，也有可能是沟通不够，先不抱怨，先沟通:)

38 楼 topgun 2009-05-14  

dch1287 写道

可以参考一下 Spring2.5、Hibernate3.3、Tapestry5 的源代码结构
Hibernate3.3、Tapestry5(非常典型) 针对不同模块都分了不同的 project source path
Spring2.5 似乎是同一个 project source path 但是最后生成的jar却是分开的

这几个例子是怎么做到的呢？
使用Maven 来管理，一切问题就迎刃而解了

我甚至认为，以现在企业应用比较复杂的情况，一定要使用Maven 的模块管理
而且，Maven 一定要会用，用好，不要一知半解就说怎么怎么样

37 楼 抛出异常的爱 2009-05-14  

java7以后可能楼主的问题会少很多
原引 自 :http://www.infoq.com/cn/articles/java7-module-system

引用

最近，新的Java模块系统已经受到了大量的关注。在观看过Devoxx关于Jigsaw的一段演示后，我很兴奋，觉得它应该会是针对复杂类路径版本问题和JAR陷阱等问题的解决方案。开发者最终能够使用他们所期望的任何Xalan版本，而无需被迫使用授权机制。不幸的是，通往更加有效的模块系统的征途并不是很清晰。

在研究确实问题之前，我们先来看一些基本概念：
模块化

模块化是解决复杂性问题很重要的工具。把应用分成不同的部分（模块、库、包、子项目和组件），再分别进行计算，是行之有效的方式。模块化的最终目的是能定义出一套API用于模块间的沟通。

如果模块间所有的通讯都只通过这种API来实现，那么模块是松耦合的，于是：

    * 改变某个模块的实现会很容易
    * 开发和测试各个模块能很容易独立开来

面向对象模式也是类似的道理。在OOP中，理想的状况是拥有大量小的、可重用的、简单并分离良好的对象。在模块系统中，就可以完美地实现小的、可重用的、简单并分离良好的模块。它们的想法和最初的动机是完全一样的，只是规模有所不同。
逻辑分离

传统上，Java中有两种办法来实现模块化。逻辑分离是最自然的方式。它包括将应用程序分割成逻辑模块（子项目），最后再部署成一个完整的应用。通过定义正确的包来实现逻辑分离也是可能的，但更通用的办法是把应用分割成一些存档文件（也就是JAR包）。逻辑分离里能促进模块的重用，有助实现模块间的松耦合。你甚至有可能定义一个API，然后宣布所有模块间的通讯都要通过这个给定的API来实现。这样的想法有个大问题，那就是你很难强破大家都采用这种限制性用法，而且没有任何一种机制能够确保这个API的用法。你也没法把那些应用通过给定模块来使用的类和作为公共API一部分的类区分开来。如果一个类是“ 公共的”，那它就可以被任何其他类使用，无论调用它的那个类属于哪个模块。另一方面，受保护的或者包级可见性的类在其模块内部的调用也有限制。通常来说，涵盖了一些包以及包中类的模块需要能够互相调用。因此即使某个应用是由一些逻辑模块组成，但如果这些模块是耦合的，那么分离也根本没有用处。
物理分离

另外一个传统的办法就是物理上的分离。你可以通过将应用分割成不同的组件，然后把每个组件部署到不同的JVM上而实现分离。这些组件间通过远程访问机制进行通讯，比如RMI、CORBA或者WebServices。物理分离实现了分离，也实现了松耦合，但负面影响是开支很大。为实现分离而专门采用远程访问机制，有点杀鸡用牛刀的味道。这会增加开发和部署不必要的复杂性，性能上所受到的影响也不能忽视的。
模块系统

模块系统的作用位于逻辑分离和物理分离之间。它强调模块分离，但各个模块仍然部署到同一个JVM中，而且模块间的通讯由简单传统的方法调用组成，因此不会有运行时的开支负担。在Java生态系统中最流行的模块框架是OSGi。它是一个成熟的规范，具有几个不同的实现。在OSGi中，模块被称作bundle，每个bundle等同于一个JAR。每个bundle也包含一个 META-INF/MANIFEST.MF文件，这个文件会宣布导出哪些包（package）以及导入哪些包。只有那些导出包中的类才能被其他 bundle所使用，而其他包都只面向包的内部成员，包里的类也只能在自身bundle中使用。

比如下面这个声明：

Manifest-Version: 1.0
Import-Package: net.krecan.spring.osgi.common
Export-Package: net.krecan.spring.osgi.dao
Bundle-Version: 1.0.0
Bundle-Name: demo-spring-osgi-dao
Bundle-SymbolicName: net.krecan.spring-osgi.demo-spring-osgi-dao

这个规范指定了名叫demo-spring-osgi-dao的bundle，它要导入包名为 net.krecan.spring.osgi.common中的类，并导出包名为net.krecan.spring.osgi.dao中的类。换句话说，这段声明表明其他模块只能使用net.krecan.spring.osgi.dao包。相反地，这个模块要使用的则只是 net.krecan.spring.osgi.common包，而且也可能会由OSGi来提供专门的模块负责导出这个包。当然你完全可以在导入和导出声明中定义多个包名。

需要特别注意的是，OSGi的模块化是构建在Java之上的。它不是语言的一部分！这里的模块分离虽然可以由GUI来执行，但不可以由编译器来执行。运行基于OSGi的应用时，你会需要一个OSGi的容器。这个容器可能是运行时环境的一部分，比如在Spring DM服务器中，也可能是嵌入在应用程序中的。这个容器不仅负责提供分离，也提供了其他诸如安全、模块管理和生命周期管理之类的服务。OSGi还提供大量其他有趣的特性，但这些并不是本文所要关注的。

关于JSR-277曾经有很多争议，这个JSR一度跟OSGi有部分重复。连续好几个月，双方的专家都极力辩论谁更优秀，直到JSR-277被宣布放弃，而新的模块系统将会是Java 7的一部分。
JSR-294

这个新的模块系统的第一部分就是JSR-294，即所谓的超级包。也正是这个规范阐释了Java语言的模块部分的概念。

JSR-294引入了新的可见性关键字“module”。如果一个成员拥有这样的可见性，那就意味着它只对同一模块中的成员可见。它会创建一个内部的 API，只有模块本身能调用。就此看来，“public”关键字应当只在声明一个公共的API时才用。而在其他情况下，应当使用“module”或者有更多限制的可见性关键字。当然，一旦语言中有了“module”关键字，那么模块之间的可见性限制将会由编译器来负责检查。

JSR-294也允许定义依赖性。你可以在某个给定版本中，定义某个模块依赖于另一模块。比如：

//org/netbeans/core/module-info.java
@Version("7.0")
@ImportModule(name="java.se.core", version="1.7+")
module org.netbeans.core;

最后一句表明“org.netbeans.core”模块依赖“java.se.core”的1.7版本或者更高。这类似于Maven的依赖性或者 OSGi的导入。你也可以暂时不要管这些语法，因为将来语法可能会另有变化。重要的是，这儿的依赖是在module-info.java中定义的，会被编译成class文件。而OSGi中，依赖则是在普通的文本文件中定义的。
Jigsaw项目

Jigsaw项目是这个新模块系统的第二部分。我预计它会是JSR-294特定于Sun的实现，也会是Sun JDK的模块化实现。既然创建完整的JDK模块化是有必要的，Sun就希望把标准库分装成模块。这直接简化了JRE中的内容整合。整个JRE除了Swing之外的所有内容因此都能够在移动设备上运行。它还有可能为语言引入新的标准API，而无需再等待整个平台的新版本发布。目前看起来，这个项目绝对有希望实现。

但我对此还有个担忧，那就是，a href="http://blogs.sun.com/mr/entry/jigsaw">专有的Jigsaw和JSR标准之间的关系并不清晰，正如Mark Reinhold所说的：

    对Jigsaw的投入无疑会创建出一个简单的、低层次的模块系统，它的设计会严格地朝着JDK模块化的目标而发展。开发人员可以把这个模块系统运用到他们的代码中去，Sun对这个模块系统也会是绝对的支持，但它不会是Java SE 7平台规范的官方部分，也可能不会被其他SE 7实现所支持。

这段话说的不是很清楚，当中有很多疑问。他的意思是说创建的模块只能在Sun JRE中运行吗？还是想说，如果开发者写了“@ImportModule(name="java.se.core", version="1.7+")”，那么这个模块只能在Sun JRE中运行，而不能在IBM JRE环境中运行吗？或者他的意思是不是说Sun会以某种方式把它的JRE分割成许多模块，而Oracle会选择另外的方式去分割吗？(译者注：至少现在看来，不太会有这样的可能了，因为Oracle刚刚收购了Sun)。我们希望都不是，因为还有“编写一次，到处运行”的原则。

细究起来问题更多。我们并不清楚Jigsaw项目的主要目标是什么。据项目本身所宣布的主要目标来看，它要实现的是Sun JRE的模块化，但如果纯粹是要实现模块化的话，就不需要对语言做任何改变。Sun可以对JRE进行模块化，而不修改Java语言本身。

这些语言上的变化会不会成为Sun JRE模块化带来的副产品？如果是，那就彻底错了！语言变化必须是一等公民，而不是专属的副产品。
依赖

我的另外一个担心在于依赖性。如果依赖性由模块系统来管理，那就不再需要classpath了。一方面这很不错，因为classpath经常会导致所谓的JAR地狱问题。但另一方面，classpath也是极度灵活的，我恐怕这种灵活性是不可能由一个静态的模块依赖能够拥有的。让我们来看看为什么：
部署时依赖

Java中有两种类路径（classpath）。一个是构建路径（buildpath），它用在构建时。另外一个是类路径，用在运行时。两者几乎相同，但又不完全是。经典的例子就是JDBC驱动。在构建时，你不需要指定JDBC驱动，JDBC接口是Java核心库的一部分。但在运行时，你就有必要确保类路径中有JDBC的驱动。如果某个编程人员需要修改数据库连接，他只需要在配置文件中修改驱动类的名称，并把驱动jar文件添加到类路径就可以了。如果所有的依赖需要在编译时指定，开发者很明显无法做到这点。当然，在Java EE中，他可以使用JNDI数据源，但在Java SE中没有类似的东西，一旦修改JDBC驱动，就不得不重新编译整个应用，这明显很不靠谱。

通常来说，重新编译不太可能。在一些组织中，最终的应用是由所谓的应用装配器的模块组装而成的。开发者没有源代码，他只是把一些JAR放在一起，修改一下配置文件，然后创建最终的包。应用装配器的角色甚至在Java EE的规范中都有提到。
可选依赖

类似的问题就是可选依赖。我们假设我们要做一个像log4j这样的日志框架。这个库可以对JMS记录日志，因此JMS包必须涵盖在构建路径中。但 99%的用户并不使用JMS日志，因此他们不需要把依赖放在类路径中。对于这样的问题，必须要有某种机制来解决。我们需要一个库来构建这个模块，这种依赖对最终用户来说则是可选的。当然，完美的情况是，JMS功能会是个独立模块，可我们并不是生活在一个完美的世界，而且某些时候用这种方式来分割项目也不太现实。
依赖冲突

另外一个大问题就是依赖冲突。如果你用过Maven，就不难理解我在说什么了。大多数企业应用都会用到大约十几个第三方库，它们之间的互相依赖有时就会发生冲突。比如，一个开发者想要使用Hibernate，它依赖commons-collections 2.1.1，他还想用commons-dbcp，却需要依赖commons-collections 2.1。开发者自己或者应用装配器需要决定怎样解决此类问题。他要么决定在应用中只用某个特定版本的库，要么决定在应用的不同部分采用不同版本的类库。重要的是，这些问题无法自行解决。它总需要由某个了解各个模块在应用中如何运作的人来作决定，而这个人又要能识别不同版本间可能存在的不兼容性。

关于Java依赖性，还有许多东西本文不展开讨论，但需要铭记的一点是，它们不是静态的。一个应用的构件可能采用了某套类库，而它的运行却需要另外一套完全不同的库。所有模块系统必须以某种方式把这些问题解决掉。Maven具有大量关于如何配置依赖，以及如何处理依赖冲突等等的选项，但它只是个构建系统。最糟糕的情况是需要手动配置类路径。OSGi则是另外一种情形。它只处理运行时（部署时）依赖，不管构建时。新的Java模块系统会同时支持构建时和运行时依赖（我猜测），甚至会把既有的复杂问题变得愈加复杂。
总结

当然，我相信Sun的工程师并不想要破坏Java本身。我想他们也是为了让Java变得更好、更易于使用，但我担心政治和市场因素会远大于技术影响。再次声明，这不会仅仅是个API的变化或者是特定于Sun的变化。这会是语言级别的变化！一旦语言被改变了，一旦添加了“module”关键字，就不会再有回头路。到那时，Java中会有个模块系统，无论喜不喜欢，我们都非得要用到这个模块系统。真得很难想象带模块化的JVM，也很难想像Java语言中会有个 “module”关键字，而我们还要在这之上使用OSGi。

36 楼 dch1287 2009-05-14  

steeven 写道

我们的项目是c/s结构, 所以在规划的时候规划了四个子项目:
client/common/server/web

robbin 写道

不分项目也不见得不好。如果你分了n个项目，用到公共类库或者公共底层数据库的时候，你就非常痛苦了。我见过很多很多大型开发团队，就是因为划分子项目以后，在交叉引用上面痛苦不堪，一改公共代码，波及的范围非常广。

JavaEye网站现在别看二级三级域名这么多，还带有垂直频道，开放API，可就是一个项目，一份代码，修改和部署都非常简单，以后也会一直单项目走下去。

To Robbin: 他这个项目是C/S的 不是B/S的
客户端代码肯定要单独写 至少会是在一个单独的文件夹路径下

楼主你和这个老外的项目这个名词的定义是不是不太一样
eclipse项目或其他任何IDE项目
产品项目

可能的方案
xxx-project-root
  - common(估计common的build结果就一个xxx-common.jar)
  - client
  - server(如果Server在Web Container中实现的话 可以考虑和Web合并)
  - web
然后上述每个目录都是一个Eclipse项目 然后后面三个项目都把common放入关联项目中

build的时候，这些项目之间的关联用ant搞定。部署速度应该不会是问题，除非你ant乱写。

最后整个xxx-project-root作为一个整体的产品项目来发布

在老外眼中 他只要一个项目 里面文件夹怎么定义随你搞
在程序员眼中 项目就是一个程序的逻辑实体集合 这个集合和其他集合因为最终部署地点的不同 而被称为不同的项目

所以需要耐心的和老外做communication

不知道我有没有误解楼主

可以参考一下 Spring2.5、Hibernate3.3、Tapestry5 的源代码结构
Hibernate3.3、Tapestry5(非常典型) 针对不同模块都分了不同的 project source path
Spring2.5 似乎是同一个 project source path 但是最后生成的jar却是分开的

35 楼 night_stalker 2009-05-14  

注释：

// Magic. Do not touch.

// You are not supposed to understand this.

Catch (Exception e) {
 //who cares?
}

// 这段代码由机器自动生成，所有修改都将被还原，本人不负任何责任
// 楼上的是谁？

34 楼 Jackphone 2009-05-14  

supttkl 写道

我现在搞软件实施了，恨死那些过度设计者了，简单问题复杂化，代码搞了一层又一层，异常包了又抛，抛了又包，一段代码N段时间进行了修改，N个人改。我曾经在代码注释里看见这样的注视，“我也不知道这段代码是干什么的，我今天终于把这托屎给改完了。”最后我得出个结论，什么是赚钱的软件，这样才是最赚钱的，不费那么大力气搞，怎么才能赚钱？

这话笑死我了！