java 看程序哪段效率低,为什么一些JAVA EE / J2EE 工程是效率低上或者至少是效率欠佳的（翻译）...

有道理啊

很多项目在做决策的时候不是考虑实现成本，而是考虑技术先进性和一些不知道什么时候会被用到的特性。

Nighthaven 写道

英文原帖地址：http://www.adam-bien.com/roller/abien/entry/why_some_of_the_java

1.架构师对于PowerPoint的熟练程度要远远胜过流行的Java IDE。

2.光是部署基本环境(比如应用程序服务器和数据库)就需要若干张ＤＶＤ和几个小时。

3.一些流行的服务器需要几分钟去启动和部署，而你每天要重复这一过程若干次。

4.为应用服务器的bug立案(并且重现问题的所在)往往比你自己修复它需要的时间更长(当然，如果你有源代码的话)

5.很难为开发者们找到一个可以高效运行那些“企业级”开发工具的硬件，而且因为这些开发工具十分昂贵，想要弃他们不用也很困难

6.架构师热爱分层，光是从持久层传递一个持久实体到表现层，就需要若干次mapping。

7.一切都是可配置、可替换、可建模的。ＸＭＬ的负担十分巨大。问题是：上一次你真正的需要在工程中替换某些东西是什么时候？

8.无论是瀑布式还是敏捷式都充满各种专业术语和奇怪的规范。两者都可以非常的低效。看上去只做最基本的有时真的很难。

9.开发者有的时候非常极端：不是用成千上万的模式和最佳实践把所有东西都过度设计，就是直接了当的使用“意大利面条”式的开发风格。

10.“快感已经不再”很多开发者、构架师和经理们已经失去了他们的狂热和激情。这也是为什么许多工程如此低效的原因之一。

11.即使像留言板这样的程序，也要考虑高可用性(译者：就是不掉线～)、集群。复杂性统治一切。

12.奇怪的质量保证规则(比如文档化很明显的getters／setters方法)加大开发和维护成本。

这个文章的评论里面有人总结出来第１３条：

构架师和开发者热爱框架。即使对于最简单的增删查改类的程序，也要用到internet://**/*.jar，而不是Ｊａｖａ　ＳＥ或者应用程序服务器提供的ＡＰＩ。

译者：我不是推卸责任，虽然都在点子上，但是原文作者的文笔确实一般，我基本忠于原文，所以文笔也就只能这样了。

最后奉上我自己写的仿《大腕》经典对白：

一定要找那最流行的框架，

用功能最强大编辑器，

做就要做最复杂的系统，

轻量级的绝对不行，

框架最简单也得是ＳＰＲＩＮＧ，

什么ＥＪＢ啊，ＨＩＢＥＲＮＡＴＥ啊，ＳＥＡＭ啊，能用的全都得用上，

表现层要可配置、持久层要可替换，

程序最好能用一万年，

客户一见面，甭管有事没事，

都得问人家：您准备换框架不？

系统还得能够集群

访问量再小也得同时开１０几台服务器

一天２４小时在线

火星撞地球了都能提供服务

服务器上跑得都是weblogic、websphere

你要用一jboss，都不好意思跟人家打招呼

你说这系统，得做多长时间？

(怎么地也得５年吧？)

５年？那是一期工程，

１０年起，

你得揣摩老板的心理，

愿意花５年开发一套系统的老板，

根本就不在乎再多等５年，

什么是软件工程你知道么？

软件工程就是，搞什么都不用最好的，用最复杂的

所以我们口号就是：

不求最好，但求最复杂。