当前位置:  开发笔记 > 编程语言 > 正文

如何在开发基于Java EE的Web应用程序时提高工作效率

如何解决《如何在开发基于JavaEE的Web应用程序时提高工作效率》经验,为你挑选了3个好方法。

我想知道如何解决与其他技术堆栈(Seaside,Ruby on Rails等)相比基于Java EE的Web应用程序开发看似低效的问题.

限制是:

完成的Web应用程序必须可以在符合Java EE的应用程序容器上进行部署

如果可能,应保留以前对基于Java的解决方案的投资,即应该可以与基于Java的系统和库进行本机互操作

由于团队结构,Java作为实现语言是首选,虽然不太奇特的基于JVM的语言(即Groovy)也可以接受

由此产生的系统需要在架构上是合理的

由此产生的系统需要是可扩展和可维护的

为了不让这个进入哲学讨论,我只对基于实践经验的建议感兴趣.可能的示例包括特定于域的语言,框架和MDSD.

如果您指向一个抽象类的解决方案(如MDA/MDSD),请提供有关如何实现它的详细信息以及有关常见陷阱和最佳实践的信息.

如果你不同意基于Java EE的Web应用程序开发意味着低生产率的假设,我也想听听你的推理.

编辑: 由于答案远远少于我的预期,我也会接受有关失败尝试的说法,基本上将问题扩展到"如何(不)提高开发基于Java EE的Web应用程序时的工作效率?".



1> Jan Soltis..:

我相信Java EE Java堆栈实际上非常好.有几个原因可以解释Java EE的低生产率:

作为"企业堆栈",它通常用于创建枯燥,丑陋,"足够好"的应用程序,一般而言,企业往往不会吸引热爱编程的优秀开发人员,并思考和关心他们的工作.企业界的软件质量并不高.

作为资金所在的企业堆栈,软件供应商试图向他们出售产品.他们制造庞大,复杂和昂贵的解决方案并不是因为它们很好,而仅仅因为它们可以将它们出售给企业.

企业往往非常厌恶风险,他们做得更好的一切都是"标准化的".某些技术被证明是成功之后或之前创建标准.在这两种情况下,它对企业(和Java)都不利.企业最终要么使用好技术,要么使用彻底失败的技术.后一种情况也非常危险,因为如果技术标准化并且每个人都在使用技术(否则完全失败)必然是好的,它会产生错误的看法.

从历史上看,Java EE平台似乎吸引了很多架构宇航员和大公司的开发人员,他们被提升为架构师,他们的唯一目的是创建更多层,更多框架,更多抽象和更复杂.

并不是没有好的Java工具和框架; 这是因为有太多不好的,太多的过度工程,太多的官僚程序和方法,太多无用的标准.

在这样一个混乱的世界中,不仅仅是您选择的特定工具选择会影响您的生产力.它主要是关于您,关于您的价值观,关于如何拒绝社区,供应商,同事和经理向您提出的大多数解决方案.这是关于你反对当前的,关于你的常识,关于质疑每个主流信念和"最佳实践".

也就是说,单靠工具不会大大改变您的生产力,相反,合适的人也可以使用劣质工具来提高工作效率.

我的建议:

不要仅仅因为它是标准技术而使用技术,因为每个人都使用它,或者因为它是Sun正式推荐的.只有在您个人认为它是您工作的最佳工具时才使用技术.通过这种方式,您可能会发现自己拒绝使用JSF,JSP,Web服务,JMS,EJB,JTA,OSGi,MDA等技术.

保持简单,运用常识,质疑一切.您真的需要发布对象以进行远程访问吗?你真的需要创建另一个抽象层,以便你可以从Hibernate切换到TopLink吗?您是否真的需要在每次需要时将数据转换为XML或从XML转换十次?你真的需要XML模式吗?您真的需要可配置的所有内容都可以互换吗?在运行时?非开发人员?

保持流程简单.要敏捷.你真的需要那份文件吗?你真的需要在一个巨大的表格中描述每个屏幕,批准它,将它输入到一些自制工具然后生成JSP吗?您是否拥有称职的程序员或您首先设计所有内容并且程序员只能"翻译"为Java?

HTML的WYSIWYG设计不起作用.

通常,图形编程不起作用.这包括UML作为蓝图,UML作为编程语言,MDA,绘图页面流程图.代码生成很糟糕.

在使用框架之前永远不要设计框架,总是要收集框架.

首选只有很少XML配置的框架.

争取低LOC数.查看代码中的实际字符.每个角色都很重要吗?认为.您可以做些什么来缩小代码?你需要那堂课吗?它有什么作用?你为什么要那样做?

测试不是神圣的牛; 你不需要100%的测试覆盖率.只测试有意义的东西.如果难以测试,请使其更简单; 或者根本不测试它.不要测试视觉外观.

最后,一些具体的Java建议:

对于表示层,请尝试Tapestry.我为什么喜欢它?因为使用Tapestry,您可以创建漂亮的代码.它专为此而设计,因此您的代码可以很漂亮.你的代码.美丽我的意思是重要的一切 - 它简短,易于更改,易于阅读,易于创建您的抽象,并且仍然灵活,它不会试图隐藏您正在为Web开发的事实.当然,它仍然是谁使你的代码美丽.

随意使用Hibernate,特别是对于CRUD和大型应用程序.不要打扰JPA.虽然它不是一颗银弹,但是ORM你总是会把另一套问题换成一套.

只有一点点Spring,你不需要太多,因为你已经仔细避免了所有的Java EE陷阱.谨慎使用依赖注入.

毕竟,在抽象出复制/粘贴代码时,您可能会发现Java语言过于冗长且不太有用.如果您想进行实验,请尝试使用Scala.问题在于Scala的主要卖点是,您可以在保持类型安全的同时获得现代语言的所有好处,同时,还没有可靠的 IDE支持.用于超酷Java IDE,除非有一个稳定可靠的IDE支持,否则切换到Scala没有多大意义.足够稳定是不够的.


我不同意"不要使用标准,而是工作的最佳工具".您的代码可能会存在很长时间,这可能比"今天的最佳工具"长很多,因此您的雇主可能需要在10到20年的时间内维护您使用工具包/语言编写的代码.对其他人完全不了解.概念验证:Visual Basical停止向后兼容版本6.这意味着这些应用程序停留在时间间隔中,但可能仍然是重要的应用程序.基于标准的项目往往寿命更长,并且有多个实现.
除非您是提交者,否则Tapestry对于企业使用是不可接受的.它可能很好,它也有一个不可接受的政策,以维持当前稳定的版本.在从4到5的转换中,4没有收集错误,长时间没有稳定5.

2> Pascal Thive..:

像Spring,Hibernate,Wicket这样的框架当然有助于简化和加速Web开发,因为它们提供了高度的可测试性并且非常好地集成.但即使您有一套良好的开发实践,它也不足以达到RoR生产力.仍然需要太多的技术和管道.

Grails可能是这张照片中缺少更接近RoR的部分.这是我的下一个实验.

顺便说一下,我的MDA经验与提高生产力相反,所以我不会提及它们(实际上,MDA正在扼杀我们的生产力).



3> Anton Kuzmin..:

Javarebel可以大大减少使用Java进行Web开发所花费的时间.

我在这里引用官方网站:

JavaRebel是一个JVM插件(-javaagent),使您可以立即查看代码更改,而无需重新部署应用程序或执行容器重新启动.如果您厌倦了观看日志,并希望看到您的更改以便继续前进 - JavaRebel是您最好的朋友.

推荐阅读
女女的家_747
这个屌丝很懒,什么也没留下!
DevBox开发工具箱 | 专业的在线开发工具网站    京公网安备 11010802040832号  |  京ICP备19059560号-6
Copyright © 1998 - 2020 DevBox.CN. All Rights Reserved devBox.cn 开发工具箱 版权所有