好累啊。

累啊,脑子!每天看不尽的文档!!而且还全都是英文的。头都看大了,但还是看的一头雾水。做软件行业好累啊。每天都要学新东西。我们客户(一家大型国企)的员工就爽多了,每天就是装装系统,聊聊天什么的,拿的工资也一点不必我们少。哎!!

codeguru说的很有道理。

曾经在ejb,spring,hibernate里打拼了很长时间,最后还是回到了jsp+存储过程的路线了。个人认为,技术上的东西可以研究探讨,具体使用什么还要看具体的环境,包括开发人员。我们项目的第一个版本是基于ejb,基于petstore的思想来设计的,设计上有些过度,但还算优雅,然后换了一批人,改的面目全非,然后提出javabean的方式,后台用hibernate,又换了一批人,结果OOM出现的那个频繁,忍无可忍了。换成jsp+存储过程了,jsp里写sql语句,这个世界清净了,刚毕业的学生都能写,不用什么培训,人走一批再来一批,大不了把jsp和存储过程重写,虽然重复的多了,但耦合的少了,不会出现现网运行时那些莫名其妙的问题,开发组也不用天天争论问题是谁的无聊问题。开始使用该框架,我开始也坚决反对,但看到效果这么好,无语。。。。。

>我开始也坚决反对,但看到效果这么好
只能说明你们的客户比较容易搞定,没有给你们提出频繁变动的要求,或者说没有客户需求,自己定规则自己玩,这就是桃花园,独立王国。

世界上有几个这样独立王国?特殊现象不代表普遍价值。

现实总是有太多无奈,你不能指望客户改变,更可气的是那些自以懂的开发的客户,具体的细节他都要指手画脚。

to banq
关于变化问题,不是我们的需求没有变化,而是变化的太快。每次表结构都要换一遍,就重新规划版本重新开发一遍了。当然我们也不是自己玩,呵呵,哪有这么爽的单位。来了需求进行开发修改就是,如果仅仅是玩,又没有压力,也不会架构换了一遍又一遍。我不是否认什么技术不好,而是觉得要用什么技术一定要结合公司的软环境进行考虑,如果队伍里有一个专家,八个刚毕业的学生,计划半年时间用struts+ejb或者spring,hibernate来开发一个商用j2ee系统,那么开发出来的效果不会好到哪里去,但如果用jsp+存储过程,则效果要好的多。

国内的企业一般升到CIO就不做什么实事了,就如我们公司的CIO,整天就知道和客户吹水,夸公司的实施能力多么好,解决方案多么先进。还有好多技术总监也是,真该给他们换个销售总监的title。
[该贴被eoeac于2007年09月13日 16:02修改过]

组件化并不是指技术,而是如何将业务逻辑组件化,你能抽象业务逻辑,不管你是用VB、C、Java甚至Cobol,还是其他的各种框架(Com/corba/j2ee/Spring/……),你都能够开发出可重用的系统。如果你纯粹从技术谈组件化,说明对软件工程的理解还没有入门。

各种技术对组件化的确都有支持,但支持的力度不同,要求不同。

像VB、PB这类的东西,也是支持组件化的,但支持的程度很有限。大多数这些领域的程序员习惯了拖拉控件,做了好多年都不会去考虑做自己的控件、更不用说重用业务逻辑(不是复制-粘贴大法)。因为组件化在这里只是一种高级参考实现方式,实际中大家为了上手快,基本上是不采用的。
但Java不同,组件化重用是其核心思想,也是一种带有强制性的隐含惯例。一开始会非常难以习惯,真正学会了才会其乐无穷。

具体技术与总体思想是形而下-形而上的辩证关系。互相影响、互相促进。正如过去的C与“瀑布方式”,后来的VB与RAD,现今的Java与OOP。个中关系,自己体会。