JAVA项目成败攸关的纯技术方面的问题，想了几个，请教大家的看法
－是否用EJB
对性能有重要影响的问题
-数据库表-对象映射方案
-数据库查询返回方案
-随意的数据库连接
-对session的随意使用
对开发速度有重要影响的
-采用不熟悉的JAVA新技术
-清晰的控制流程
-模块的划分，公共模块的开发
-在JSP中放置太多代码，造成调试的不方便
对整个系统有重要影响的问题
-权限设计不合理
对维护有重要影响的问题
-大对象
-使用facade模式
－代码注释差
－－
配置管理对项目的成败也很重要，但其是JAVA技术之外的，所以不算在内
The most important: people, everything else is second.
If you get to know how IT people in Wall street development applciations, you will be surprised that how many things they have done wrong based on "text book". But they deliver in much higher percentage than peers in othe industries. Why, those guys are sharp!
I have some opportunities to work with some of those guys, their work really open my eyes.
-Wanchun
> The most important: people, everything else is
> second.
> If you get to know how IT people in Wall street
> development applciations, you will be surprised that
> how many things they have done wrong based on "text
> book". But they deliver in much higher percentage
> than peers in othe industries. Why, those guys are
> sharp!
>
> I have some opportunities to work with some of those
> guys, their work really open my eyes.
>
> -Wanchun
谁能够帮忙翻译一下：
最重要因素的是人...
对维护有重要影响的是害怕 “过分耦合性”，系统稍微一修改，bug就很多，这说明这个系统基本失败。
降低耦合性对java项目成败是很关键的一个问题。但是大家也要知道一些java高效编程的原则：
如：
重载类的toString()
当一个类要用于哈希表的存储时，重载hashCode()和相应的equals()方法
不要过分依赖重载finalize()来释放系统资源，最好的方法是另外提供个方法来释放资源(close()),供使用者调用,使用者可以在try{}finally{Class.close()}
......
I recommend this book: <<Bitter Java>>, precise and comprehensive coverage.
There is another more recent one: <<Bitter EJB>>
free download btw
guess it does not like double "<"
the book name again: Bitter Java and bitter EJB
重载类的toString()
当一个类要用于哈希表的存储时，重载hashCode()和相应的equals()方法
不要过分依赖重载finalize()来释放系统资源，最好的方法是另外提供个方法来释放资源(close()),供使用者调用,使用者可以在try{}finally{Class.close()}
为什么要重载？
如何重载？？
请指点，谢谢！
最重要的是：人!其它的都在其次。
如果你知道华尔街的IT人们是如何开发软件的，你会惊奇地发现，他们有很多东西都是用“记事本”做出来的。但是，他们所达到的百分比要比其他行业的同类人要高得多。为什么呢？因为这些家伙非常精明能干。
我曾经和他们有一些合作，他们的工作真的很让我开眼界。
> 最重要的是：人!其它的都在其次。
> 如果你知道华尔街的IT人们是如何开发软件的，你会惊奇地发
> 郑怯泻芏喽鞫际怯谩凹鞘卤尽弊龀隼吹摹５牵撬
> 达到的百分比要比其他行业的同类人要高得多。为什么呢？因
> 庑┘一锓浅＞髂芨伞?> 我曾经和他们有一些合作，他们的工作真的很让我开眼界。
老大能不能说详细一点啊？我很感兴趣啊
"低耦合"是系统设计/实现的一个追求目标。到项目后期，太多的耦合导致的后果是:一点小的修改就要引发众多模块的修改，以及测试--最要命的是所有模块都要测试。如果这个后果出现，就等于宣布这个项目失败。
设计/实现过程的一个原则是：最好0耦合；不行就追求单向耦合。
怎样追求低耦合--总结出几种情况，(个人浅见，欢迎讨论)
1. 子系统A和子系统B之间没有逻辑联系，相对独立--0耦合，最好
2. A和B都要依赖于一些共同的东西，A<-->B。能否转换为如下结构？
A-->C; B-->C
如果能，OK，单向耦合。
3. 如2的情形，如果不好抽取C模块出来，那么能否将A的一些功能转移到B中，形成A依赖于B,B依赖于本身?
A-->B;B-->B ==> A->B
如果能,OK,单向耦合。
4.如3情形，如果不行，则考虑模块内是否分层次？(一般会有的，例如:Businesslogic -->domain -->DAO)，那么能否将耦合的层次降低：从businesslogic 耦合 -->变成domain耦合 -->变成DAO层耦合?
5.如果都不行，那就要回过头来想想整个设计方案哪里出问题了。是整体设计方案不合理，不在本贴考虑范围之内了。
persistence 技术(entity bean, ojb等等)大家都爱用，但这个技术在某些情况下不适用。例如在"查询"模块，因为查询说到底是sql语句的干活，而sql语句的优化是和不同数据库紧密相关的，一定需要DBA参与的。另一方面，查询不需要修改数据，那就用不上persistence的好处了。
--说这个，是想说明一点：做软件的既要有先进的技术理论，还需要就事论事，遇到什么事情就出什么招。就象"设计模式"那么强调"context"一样。否则项目难免失败。
"设计模式"强调其适用的情景，而其中有个最重要的"情景"好象容易被人忽略。
----明确的功能需求
----定义明确的接口
----定义明确的Entity Relation
----and more...
一味强调“设计模式”容易陷入舍本逐末的状态。
有明确的系统定义，不一定项目就成功；但没有有明确的系统定义，项目一定会失败，不管我们设计模式用得多精巧。
--数据库表-对象映射方案
是说这方案不好么？
那最好是怎么样处理数据库表与对象的关系呢？
拜托，不懂不要乱译好不好，人家是说
你会惊奇地发现，他们甚多东西都不是按本子办事（原文直译：做了很多书本上会规划为错误的做法），但是，他们的办事效率要比同行们高得多....