killko 发表文章: 2/ 注册时间: 2007年05月13日 17:21

西方人(我指讲英文的那些)一般不分姑姑、阿姨、伯母、舅妈、叔叔、伯伯、舅舅，只统称aunt和uncle,你们认为中国人有必要分得那么细吗？为什么中国人会把这些分得那么细，是大家庭的需要。同样J2EE之所以有这模式，那模式，这框架、那框架的，其实就是大应用的需要。如果你只是做个小应用（特别是一个人可以维护得了的小应用），那你不必去理会那些，只要用pure java就OK了，但你不能说人家做大应用的把东西搞复杂了，人家那些应用本身就复杂些，做的那些东西实质上是“简化”了应用，只是人家简化后的系统还比你做的系统复杂些而已。另外提醒楼主一句，开发不是开发程序，而是开发系统，这个系统是包含人在内的，也是包含管理在内的。

-------------------------------------------------------------
以上为最切题的回复。

另外，软件开发有时候真的需要悟性的，有的人可能只学了几天就能看清问题的本质，有的人花了一辈子都不见得知道自己在做什么为什么这样做。

自己会多少种语言，工作了多少年诸如此类的话说了并不会加重语言的分量和说服力。多思考多研究再挑战主流，有些人总认为自己是众人皆醉我独醒，其实只是井底之蛙。

最近网上好出惊人之语的总是让人失望，没几个有含金量的，都是以自己的无知挑战别人的耐心。

我感觉用冰箱的人和造冰箱的人根本不是一类人。
用冰箱的人可以是任何人。
我们程序员也不能模糊这个概念。
计算机科学博大精深。
我们用windows,qq,msn,IE,...,但我们自然不懂这些玩意怎么造出来的。
但我们只研究某个方面，比如某一种语言:java,某一种平台:Spring,某一种技术:MDD,
你会SQL并不表示你就一定要搞懂BI。
任何一个分支都需要抉择，术业有专攻才是正道。

首先，要肯定楼主的出发点是正确的，至少java也面临竞争的压力，竞争归根到底是人才的竞争，面临诸多选择的时候，新手几乎会选择容易的，如果没有后来人了，java的前途如何可想而知。

其次，想提出一个框架，不知道各位注意到没有---Cocoon2。任何商务活动的焦点并不仅仅是哪一种技术能达到最好的性能而是哪种技术能令公司在最短的时间之内交付稳固的应用程序，Cocoon2在实现了管理、逻辑、内容、风格分离的基础上，让开发任务可分配给擅长某方面技术的人员，他们不再需要熟悉其它方面，使得开发工作就可同步进行。

可惜的是，在Cocoon2中无法实现灵活的软件治理，不然的话，它还真是一个快速开发平台。另外，熟悉xsl的程序员太少限制了它的推广。

我觉得回复的里面很多人理解错了楼主的意思，尤其那些出言不逊的人，楼主表达的主要意思不是一味地去强调框架本身复杂不好，而是说现在的一些框架，为了追求更多的松耦合，适合大项目扩展性而发展为复杂的配置，这些配置甚至重复啰嗦，反而给使用框架的人造成了很大难度，降低了开发效率。（楼主是不是这个意思啊？站出来说一句）为这一点，我是支持楼主的。
我认为，框架可以复杂，框架为使用者服务，使用起来简洁明了为最美，简洁不是简单，不见得程序员失业云云，没有一定功底的程序员别想驾驭这种简洁，现在的一些框架，就是struts我觉得的确有些配置复杂了，而且重复啰嗦（当然除了这点别的都很好），你想想，一个field在jsp里面了（view层），还要在FormBean里面了，用动态bean还要在xml里定义，如果用到validation还要再定义一遍，后面用hibernate还要再定义...这样做是松耦合了，可你把使用者也搞烦了，能不能一个定义搞定啊？答案是肯定的，能！我就花了三个月时间搞了一个简化的struts，请教了很多人，在使用过程中又不断该进，使用简单的定义一遍就可以，虽然没有别人做的艺术，但一点不失struts的扩展性，最重要的是，它减轻了很大工作量。
不说别的了，啰嗦一句：框架可以复杂，但要让使用者简介！

zhaoce，

阿哈哈，你讲话真风趣。。 where r u? Im in Canada.....

楼主被很批啦，表示同情；
不过话说回来，用Java进行Web软件开发是够复杂的；比不上许多传统工具；
其实不是说做项目或产品的大小，导致Java复杂，而是Java（当然不仅仅指Java，包括整个Java领域）开发本身的复杂度是蛮高，否则也不会Java开发的Web软件要比传统CS软件贵，比ASP的也贵；

Java感觉复杂跟开源领域还是有许多关系，太多的东西被加入到Java中，各种技术各种想法都被纳入，好也不好，好是你多了选择，多了可控性；不好就是把Java搞复杂啦，想想看，有多少Java框架在被使用，你做一个项目要掌握多少技术，要去apache上找多少个最新的软件包，要去论坛上查多少资料？等你把一个软件做完了，你会发现你的IT词汇库中多了一落的新词汇，什么Struts,Spring,WebWork...，要命的是每个都不一样，每个的用法都独数一支，每个的XML配置格式都自成体系，而且遇到问题你只有Google/Baidu满天的找...

我接触到的做CS的工程师无一例外的反映Java复杂，想想看，用VB/PB开发你需要掌握熟悉多少技术；当然基于Java语言本身来讲，还是蛮清晰简单的，毕竟Sun把控着

楼主的观点还是支持的，只是楼主提的这个简化的方法不好，不管怎样，复杂还是有复杂的道理的。

>我接触到的做CS的工程师无一例外的反映Java复杂，想想看，用VB/PB开发你需要掌握熟悉多少技术

搞传统C/S的人都觉得Java复杂，Java复杂不是语言本身，而是其代表的思想，思想方法复杂，如果你没有高级的思想方法，使用Jsp按传统过程思路也能编个简单的系统。

Java和OO软件更注重软件的可扩展和替换性，这个目的带来一些初学者感到复杂，这是初学者本身自己的问题，打个比喻：

小学生开始学习1+1=2不觉得难，扳手指头就可以学会， 到了高年级或初中才开始学习x+y=z。x+y=z比1+1=2优点就是可扩展性，不但能够计算1+1=2，而且能够计算2+3=5等各种加法，x+y=z就变成了组件可重用。

如果让小学生一入学就学习x+y=z,我想小学生都要发疯了；Java对于初学者就像x+y=z对于小学生一样。

所以，初学者当然感觉Java复杂。两者不同的是：小学生抓狂后可能不会投诉抱怨；而程序员则会拿着喇叭大声喊复杂啊，吓得其他人不敢碰Java，所以，这个现象要纠正。

[该贴被banq于2007-11-07 22:04修改过]

框架可以很复杂,但框架的使用者应觉得简单。最好是能直接接自然地描述业务需求,而不许过多考虑技术实现细节。比如常见的关联字段输入问题,直接描述那些字段变化时,另外那些字段跟着变化即可,"AJAX、局部刷新"等全部由框架实现。以下程序实现向数据表test输入intFld, strFld两个字段的数据，当输入的intFld值大于60时，strFld的值自动置为"及格"，否则置为"不及格"。

public class TestBean extends ComplexTableDsBean {
DataStore dsMain;

public void onInit() {
dsMain = new DataStore("dsMain", "select intFld, strFld from test", getConnItem());
dsMain.setColLabel("编码,原文");
// 在fld1的输入值变化时，自动刷新浏缆器端strFld字段的显示
setColOnChangeEnable("intFld", "strFld", true);
regDs(dsMain);
}

// 在fld1的输入值变化时，自动触发的服务器端方法，该方法执行完毕后，框架会局部刷新浏缆器端strFld字段的显示
public void onCalcItems() {
if (dsMain.gettemInt(1, "intFld") > 60)
dsMain.setItem(1, "strFld", "及格");
else
dsMain.setItem(1, "strFld", "不及格");
}

}
[该贴被coyizz于2007-11-20 05:34修改过]

复杂不仅仅是java的问题
整个开源领域都已经变得很复杂.不同的项目简单的整合在一起几乎可以引起混乱，都这在开源领域正在发生。
开发软件的目的不就是为了应用吗？用于复杂系统的框架，用于简单的应用,会适得其反.问题在于选择用什么框架，或者不用框架。
然而诸多的框架都企图为一切应用服务,这很大程度上迷惑了使用者.大量的傀儡库使得开发人员不少精力花费在学习框架上,而编程变成简单的零件组装.这意味着决大多是程序员都会转业成为装配工，而只有少数精英开发底层的框架.spring是非常著名的,但是使用过的人都知道他对简单应用的开发也提供了非常好的支持。然而，为了使用其中很少的功能，必须要学习诸多对于简单应用显得复杂的东西。因为对于初学者spring的安装都显得麻烦。
程序员正在变异，由偏向于生产代码向偏向于学习和分析。如果将编程和分析分开，那么编程的空间正在缩小。

业务决定技术,
当业务极其简单时,为什么要选择使用框架,为什么要使用那么多的配置文件.
而我们选择使用框架时,是因为框架能够简化我们的开发,所以我们选择使用
框架.
JAVA开发,让人觉得复杂,是因为JAVA世界包罗万象,当选择了错的决策,对
于框架不熟悉,随意使用,那不复杂才真的奇怪.
一点小见解..

>>业务决定技术

同意，业务驱动服务，服务驱动技术

简化也分成块吧，像spring提供@Repository和@Component的注释语法来执行组件查找，这种东西可以省去xml配置，但是只应该应用于技术范围的组件，像某个dao的实现，而不能用于业务接口上面，业务接口应该是不包括任何计算机技术，只包括此领域的业务人员能看懂的释意。
总的来说我认为应该使用注释语法简化掉技术上的配置，业务上的应该灵活的去用xml装配对象关系。

配置文件绝对没有想象中那么重要， 当然需要配置的东西还是要使用配置文件， 但像目前流行的一些框架来说，就显得太过分了。

虽然做项目使用了很多，其实一直都不是很喜欢使用框架。 而且也并没有感觉到特别好的地方。对于小项目来说是没必要使用框架，自己依赖jdk也能很快的完成。 而一个大项目， 很多公司都几乎是在开发自己的框架。 唯一能有用的地方就是中等项目的 ERP系统， 这个使用框架确实比较快，也能比较好的控制。 但框架一旦本身有bug， 乖乖~~~， 那种恐怖的感觉就是快窒息了一样， 而且一旦拘泥于一种框架， 将来有了更优秀的怎么办？

做了这么多年java， 有很多时候确实都不能用简单的方法去思考问题了。觉得非常有必要进行一下反思， 其实并不是什么都使用优雅的结构， 所有可能的变化都可配置才是正确的。 如果有些地方使用hardcode能简单快捷的解决问题， 而且在可以预计的时间内并不需要改变的情况下， 何必将他写到同样并不简单的xml里面呢？

上个礼拜因为一个比较紧急的任务， 不得不使用perl来开发一个通用处理流程（也许可以称之为框架 o(∩_∩)o...，这里要感叹一下， 现在的程序员几乎对脚本语言都不屑一顾，搞的我这个很多年没接触过perl的人还是最熟悉这个东东的人） 我又重新的体会了一遍脚本语言的优势， 虽然运行速度慢一些， 但开发速度却绝对的快。 也许将来有空了会吧这些用java改写， 但我想说的是，我喜欢perl的简单，和处理问题的简洁。

感觉很多人对对oo过于崇拜了， oo只不过是解决问题的一种方式而已， 虽然在大多数情况下是一种很好的方法， 但要知道，世界上至少有40% 程序员不是使用oo 在解决问题。

我的理解是在软件设计中， 至少的现在还是没有什么很通用的解决方案。 框架是一种尝试， 确实在一些合适的地方使用能帮助开发， 但很多人显然把他的地位抬得太高。 而且现在的一个问题是， 你要知道在什么样的项目中使用什么样的框架却不是一件容易的事， 如果你已经是专家， 适合你的会更少， 因为你看起来很多框架都不是设计优良的。

第一次来这个网站，看到这么多同道的讨论，很受启发。

> 你要知道在什么样的项目中使用什么样的框架却不是一件容易的事
非常正确，这就是架构师的职责所在，必要情况下，要开发自己行业的框架，而不是生搬硬套用其他人的框架。