java开发真的需要那么复杂吗?

coyizz1

2007-05-13 08:48

我并不在公司，是一个经历了Intel8051、98汇编，PASCAL、PB等时代的人，并用每种语言开发出过实际应用，对JAVA的开发自然有一番感受。在开始学JAVA时，就被其繁多的概念和复杂性所吓倒，但我选择JAVA纯淬是一种爱好，而不是为了生存，因此，有足够的时间和精力来学习JAVA并开发完善自己的框架。我的想法是，对于众多的JAVA爱好者来说，在公司工作的人毕竟只是一部分，他们使用什么框架和技术，都没有自己的自由，何况目前国内大项公司间的竞争，与其说是技术的竞争还不如说是关系的竞争。我希望的是，通过宣传JAVA开发的简单性，使更多的程序员喜爱上JAVA，通过一些小应用来提高其兴趣，只要有兴趣，再难的事情都好办了。在大项目上，JAVA的个人爱好者是无法与大公司竞争的，但在根据客户需求定制的小项目（几千至于几万元的项目）上，在小型应用程序框架的支持下一个人完成一个项目是比较现实的（人多了分的钱就少了）。至于应用程序不打包的问题，是因为对于个人承接的软件项目，客户为了保证其后继维护，通常要求开源，加上项目不大，不打包时更新单个JAVA类十分方便。

killko

2007-05-13 17:22

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

gh_aiyz

2007-05-14 10:33

为什么这种帖子也能上头条，纯浪费我们的时间

lgx522

2007-05-14 11:44

Java开发有简有繁，看你的需求和架构而定。大多数应用需求都能在Java这里找到适应的解决方案，这正是Java成为No.1的重要原因。

十几张表，几十个页面，百人以下同时在线的DB+Web应用，完全可以用JSP+JavaBean搞定。虽然PHP语法精简得多，但JavaBean封装性好，重用性高，IDE支持好，做下来不会比PHP复杂多少。
上百张表和页面，几百个人的中等规模应用，如果是锁定DB+Web的，用个纯Web的框架，像Struts、Webwork、JSF均可，用个数据库连接池，性能要求高的页面搞个把缓存，也不难搞定，用顺了其实不比ASP.NET复杂多少。
以上方案解决了90%的Web+DB问题。

至于最后的10%，那就是真正的企业级应用，决不仅仅是多少张表、多少页面、多少用户的问题。考虑的是稳定性、事务、安全性、扩展性、重用性等等一堆堆复杂问题，这种复杂应用，J2EE（EJB或者Spring+XX+XX+XX）才能解决问题，而且目前是最简单的解决方案。

coyizz

2007-05-15 00:51

作为行业用户,从目前使用的几个JAVA大系统的情况来看，这些系统的重点一般是实现联机事务处理，将各类业务数据采集到系统中，并按业务流程进行处理，对于后期数据应用分析功能，由于其业务需求多样化，往往不能完全满足我们的需求。由于各地的个性需求不尽相同，如果全部交软件公司或省级单位来实现，会造成开发工作量过大、开发周期过长，无法应付逐步产生并且不断变化的的新的需求、省级数据库负荷过重等问题，省级单位通常的做法是将数据分发到市级单位，由各市自己实现个性需求。但省以下单位的开发力量薄弱，要让其能用JAVA实现自己的个性应用，必须有使用尽量简单的开发框架支持。使用我的框架，对一般的数据应用需求（比如，对3张数据表联结后形成的一个大表进行通用查询，并且该大表有20个编码字段在显示时需要译码；或是让各级机构自行输入重点关注对象名单，只对相关数据进行统计显示），只需要编写一个JAVA类并通过FTP上传到服务器指定目录，全市及所属各县的业务部门，立即可通过浏览器查询数据处理结果，大大方便了技术水平较低的开发人员实现个性应用。这样，将数据应用系统的开发分为的框架开发层和应用开发层。框架开发层由数量少但技术水平较高的人来不断完善，主要实现通用功能，尽力减少应用开发人员需要掌握的技术数量和技术难度；应用开发层为省以下各单位的信息技术人员，数量较多，这些人可专注于个性需求应用的开发，不需要考虑过多的技术细节。有人会说，谁会愿意去做应用开发层这些没有挑战性的工作呢？但在JAVA大系统的使用机构中的实际情况是，真正愿意开发框架的人是很少的，因为开发框架需要掌握的技术多，难度大，在大家工资都一样的情况下，除了真正爱好技术的人，有谁会愿意做吃力不讨好的事呢？
当然，通过JSP也可实现，但JSP不是强类型的，本身不支持OO，复杂功能的还要靠JavaBean配合完成。

wind13

2007-05-15 09:07

coyizz 所描述的方式，大概可以理解，很关键的一点就是以数据表为基础的思维方式，这样当然会影响到进一步认识面向对象、模式、框架这类的开发思想。

那么首先我们可以不争论到底哪个方式更好的问题，我想很重要的一点就是作为程序员都应该有一种追求更好的精神，如果我是coyizz，目前我的方式可以解决应付当下的问题，那么我目前的方式有没有什么不足，现在的JAVA技术不断进步，有没有更好的方式解决我现在的问题等等，我可能更多的考虑是这样的。

那么，我会更多地了解类似框架之类的东西，是否能为我所用，比如现在是要基于底层的框架新写些Bean再发布上去，那么可不可以在前期分析时就已经考虑到后期可能的扩展，各种接口和功能都已经留好，即使考虑不到那么全面，也可以通过很方便的方法就可以在系统上再进行开发扩展，而基层的人员只需要在某个管理入口中配置自己的实际使用即可？我想banq所一直推崇的Domain Driven Design是可以实现的，也正是为实现这样灵活的开发而提出的，记住软件是要有生命的，要能不断成长的，要有好的框架以使它不致于有一天变成一个巨型的怪物，我们自己也无法控制它了。

那么这样，到时就只有总部的程序员在管理着系统，在一个非常好的框架上（例如IOC模式，非常容易扩展）不断完善系统，而基层使用的人员只需设置自己使用的具体细节即可，同时可以不断提出新的需求建议，由总部来针对其做进一步的开发。

我想上面我所说的也只是一种想象，是希望虚拟个具体一点的例子能更好地说明我的建议：先不要争论孰优孰劣，可以从自己的应用角度出发（因为只有你自己最了解你的需要，同时也只有你才要面对你的问题），多了解一些新的技术，新的思想，能对自己有所补益是不错的，如果能改变自己原来的想法，我想那是更佳的效果，呵呵……

youway

2007-05-19 16:33

只说一点，xml有效解决了很多异构的问题

lgx522

2007-05-21 08:16

千万不要怕复杂。
国内的那些个大师们不是吃饱了撑着才搞出这些架构，大家一定要硬着头皮，深入钻研，等知其然后要知其所以然，才会慢慢领悟到软件的精髓。
本人在“轻”与“重”，“快”与“慢”之间痛苦徘徊了好几年，最近总算小有心得，待会撰文写诸位共勉。

zeeler

2007-05-22 15:11

/************************************************
gh_aiyz 发表文章: 20/ 注册时间: 2006年02月21日 10:00

为什么这种帖子也能上头条，纯浪费我们的时间
*************************************************/
没有呀，我觉得通过大家的讨论也能学到不少东西呀。
楼主的说法太过武断自然会引来各方面的批评，不过讨论技术问题说明白道理就行，没必要指名道姓XX说。我觉得楼主想要表达的意思是他们的项目结构很简单，规模很小，想采用某些开源框架发现不但学习周期长而且有点杀鸡用牛刀了。。。其实，这里的讨论很多人都已经讲出框架的优点和适用面。一旦接触比较复杂的项目了，不用大家说，开发此项目的人会自然而然发现非常难于维护和扩展，这个时候他自然会发个帖子，介绍一下项目，然后征求大家的建议看看使用哪种框架比较理想。
总之，我的原则是能不用框架的项目尽量不用框架(比如楼主这种小而简单的项目)，如果采用框架一定选个比较合适的(当然，这要求对各种框架都要有一定的理解)，而不是选择最时髦的。
以上是个人意见，讨论问题，楼下的不要带情绪哦

santafeng

2007-05-24 14:15

我个人比较支持简单快捷的方法.不过与lz有点不同.

个人学习java框架成本过高,使用时下流行的java框架开发周期长,若没有完整的软件工程UML配置等IDE工具配合去维护跟进文档恐怕,人手维护DOC是若干困难.恰恰国内很多公司都没有这方面的经验.只能蒙眼瞎摸,通常是一个PDM表结构,几份所谓的手写DOC需求,一些SRC的结构管理DOC甚至是先core后逆向.在更新需求或增加模块结构代码时候通常只有COPY,从未考虑过重构,即使考虑重构也无法应付项目赶工,通常程序员都是照COPY无误,反正实现了,客户口就给堵住了.而且人员流动时间通常都是1年左右,若项目期在2年内的,开发者都是只有打一枪换一个地方,这样项目流产早,客户需求无法第一时间实现.以上应该是国内的现状.

我们绕个圈看看.net,它的学习非常快速,开发周期跟vb还快,即使文档人手维护,单查找bug或更新增加需求时候即使不重构,开发也是非常的快捷简单,界面拖放控件,底层sql编写,简单模块推翻重做也easy.项目虽然很烂,但总会保证客户的需求第一时间满足.

请问大家问题:我们做it为谁服务?如何服务?
我认为是为客户服务,要第一时间满足客户需求,同时代替他/她做对其有帮组的事情.

反对滥用xml配置的数据库映射框架如时下的主题orm框架:
项目表过百张,映射配置超过百份,start部署难以忍受,更不用说开发了,难怪人人加班,眼睛通红.

反对滥用xml配置AOP框架:
AOP映射通常都是配置逻辑类映射,所谓的滥用就是改动少的模块也配置一番,如:权限,业务逻辑不是经常变更的.这样映射该映射模块文件非常大,即使分文件也是很痛苦.非必要还是先跳过AOP实现,在扩展或修改时候重构加入.

开发体现主要在重构中,实现多种工厂利用接口的扩展去管理新增或修改的逻辑模块.必要时加入AOP框架管理,可加强项目扩展性.必须安排硬性重构时间约定组成,形成规范约制,这样即使没有框架也是非常好办.

本人很少发言,以上只是我个人的一些观点.大家可以进行针对性的讨论.

zeeler

2007-05-25 10:35

楼上说的也有些道理，XML文件多了维护也是问题，不过你.net那种方法虽然省事但是交接也麻烦吧，你自己心理很清楚，换个人来维护是否方便呢

drinkjava

2007-05-26 05:33

图形化！图形化！图形化！图形化！图形化！图形化！图形化！图形化！图形化！图形化！图形化！图形化！图形化！图形化！图形化！图形化！图形化！图形化！图形化！
图形化是解决问题的根本！
不能图形化表达的东西都是复杂的，不能方便导航，方便编辑的东西都是废物。这就是为什么有了Html还要有dreamweaver,为什么有了.net还要有Studio.Net，为什么有了Spring还要有springIDE,为什么有了struts还要有strutsConsole(后两个做的非常垃圾）...
可惜现在的JAVA界都想占山为王，很容易搞的界面就是没人做。那个垃圾Spring更是变态之极，将个类的初始化搞的复杂无比还没有图形化支持，N年前VB,DElPHI将控件拖来拖去的时候，这个玩意还不知在哪猫着呢!
什么XML方便更改更是放狗X! 不懂代码就改XML，你借他十个胆他也不敢！相对于开发成本来说，菜鸟们搞个远程桌面简直是小菜一碟。应用是一个整体，配置和代码往往是纠缠在一起的，尤其是那个什么狗XSpring掺合进来的时候。
一家独大有一家独大的好处，至少人家会养一帮闲人，倒估个界面出来，现在的JAVA整个一盘散沙。。。.

[该贴被drinkjava于2007年05月26日 05:46修改过]

cofferain

2007-05-30 12:53

可配置其实最终目的还是为了更好的实现系统的可扩展性，如果对于一个在预期中将会改变的业务，但是你目前不知道这个业务的最终规则和详细情况的时候，那么面向接口开发，同时用xml进行接口实现的维护配置将会为你的系统带来更大的灵活性。在现实情况中，系统地复杂性到处都有，连我做的30万的小项目都存在明知会有新业务但是还不能确定相关的规则和详细情况的情景发生，其他的更不用说了。还有，我们需要搞清楚复杂性这个概念，其实我们做的业务都存在或强或弱的复杂性，这种复杂性同时也会伴随着变化，“唯一不变的就是变化”，不知道是哪位牛人说的。作为一家为客户提供系统的公司，不能够在最大程度上满足用户的变化，那么我可以直接的说你不负责任。当然，用户说我不管变化，那这就没有办法了。感想很多，先说这些，看看在说。呵呵。

lgx522

2007-05-31 08:37

在数据层，dao这个层次是万不可省的。
多数业务逻辑用ORM来表达的确比较清晰和简单。
性能要求高的地方，难免要写sql或存储过程，这样性能才有保证。
有些复杂查询，用ORM简直是自找罪受，用Spring的JdbcTemplate解决起来很快。

service这个层也不能省，否则客户端要求一变就苦不堪言。
在联机事务应用方面，客户端还是用C/S（RCP）更能让客户接受，清晰的service层可以很轻松地实现替换，或C/S、B/S并用。

而web层，像SpringMVC、Webwork这类高解耦的框架，可以根据不同需要采用不同的视图。尤其是SpringMVC，初上手太灵活、太繁琐，但精通后可以适应Web的种种复杂要求，值得深入学习。

[该贴被lgx522于2007年05月31日 08:38修改过]

liuyz666

2007-06-07 10:50

我觉得大家讨论来讨论去,主要集中到两个方面:
1.研究基础知识,将来可以开发自己的模块
2.不研究基础知识,拿别人建好的模块搭积木.
其实这两个方面各有各的应用领域,看你是搞什么的,如果你只是为其他企业开发系统,完全可以只是搭积木,就象banq说的,只要知道电视机电冰箱是怎么用的就行了.如果你要做基础的东西,就要从基础学起,就要研究电视机电冰箱的结构了.这纯粹是应用方向的不同,并没有绝对的对错之分.
但我不同意banq的是对搭积木的过分强调,你的观点固然正确,但只是对一部分人来说,对另一些人来说就不一定了.就象治感冒的药,药本身并没有什么正误之分,若是拿来治感冒,就是好药,是治病良药.若是拿来治烧伤,就是误人子弟了.
国内现状虽然是需要搭积木的人多些,好像"钱途"也更广阔些,但决不能没有了搞基础的人,不然若干年后(其实现在也已经是了),我们也就只能玩玩搭积木了. 如果别人那天不想给你积木玩了,就只剩哭鼻子了.看看伊拉克的例子,想当年伊拉克是多么的富足啊,要啥有啥,据说个别人的马桶都是纯金打造.可一旦被封锁了,饭都吃不饱了,可怜啊.这也是我国要致力于打造自己的核心技术的原因(至于龙芯之类的东西,是被小人蒙骗,可以不讨论了).
现实一点,如果哪天你的积木里被人埋了一颗遥控炸弹(木马后门之类的),想想看,好像一点都不好玩哦!

所有我认为,需要赚money的,可以搞搭积木,多快好省,有兴趣研究底层的,尽可以向下钻研,到时自己搞个积木出来(小心,多数会失败的),卖给那些搭积木的人.

猜你喜欢