论坛首页 Java企业应用论坛

给做快速开发框架的人泼泼凉水

浏览 40346 次
该帖已经被评为良好帖
作者 正文
   发表时间:2008-10-28  
最近论坛里出现了不少关于此类的文章:
引用
秀一下我的快速开发平台
http://www.iteye.com/post/711399
http://www.iteye.com/topic/258458

忘掉普元EOS、构建自己的企业级快速应用开发平台
http://www.iteye.com/topic/232219


我也做过类似的东西,现在也一直在用。
但是越来越感觉那是鸡肋。
http://www.iteye.com/topic/95580

有一次,开发一个公司内部使用的图书馆里系统,前后只花了一个下午,把老板吓一跳,并支持我利用工作时间完善那套框架。

确实,在某些情况下,他可以极大的提高我们的开发效率。

但是,我们忘记了这类系统高昂的开发和推广、学习、维护成本。

刚才查了一下,我那个代码生成器,单源代码就是6.5M。
如此一个不知名的第三方开发的庞大的系统,你不搞清楚其内部逻辑你敢随便使用吗?而真正搞清楚这些东西的代价有多大,后期扩展,维护的风险多大!

从我来讲,我不敢用。

我想,做这种东西有一个强大的后台公司支持还好,如EOS后面有普元。
而作为个人开发者,我们如何能打通这条产业链,如何让别人信任,学会,并采纳你的设计思想,让足够多的人去分享去使用你的产品,这些可不是一个技术问题。

Java程序员可能都有一个好大喜功的特性,环境所致把。

但是我们还是应该充分认识到自己个人力量的有限。

要做什么东西的话,先别想着如果别人用这个东西可以提高多少多少的开发效率。
只有它能给自己带来足够的好处,你才能做下去,否则很难生存。
穷则独善其身。

有什么考虑不对的地方,大家来提提把。
   发表时间:2008-10-29  
普元什么时候倒又有谁知道呢
0 请登录后投票
   发表时间:2008-10-29  
简化开发有两种办法。
一种,减少代码量。
第二种,代码生成技术。

第二种技术是最不好的,也是rod johnson大叔非常鄙视的一种解决方法。原因很很简单,你只是把重复的代码使用生成技术生成而已,本质上并没有简化开发,况且代码的生成也不是那么智能。

第一种方法只是一个大概的概念,想减少代码量方法不止一种也不是简简单单的就能简化的。需要一个彻底的革命。

综合我见到过的所谓快速开发框架大多还都停留在第二种这个范围之内。也有一些试图去使用第一种本质上减少代码量的方法,但是结果不理想。比如那些对注解玩命追求的朋友,他们就是试图减少代码量可是,却并没有减少。想一下,你只是把以前的配置变成了注解而已谈何简化啊?更何况作为注解来说,它本身应该是代码的一部分,用它来做配置文件的工作是绝对不妥当的。还不如直接在代码里面硬编码呢。

简化需要一次彻底的革命,我考虑过这个简化,但是我并没有去实现。我相信没有人能接受,他们会有一种不安全感,会觉得。它行吗?太少了,怎么这些和这些放到一起呢?以后要是XX了怎么办?哎呀,怎么没有xxx层啊,那xxx功能放到哪里呢?
0 请登录后投票
   发表时间:2008-10-29  
本人的思路就是减少代码量
生成的代码也是代码,而且都是重复代码,通过一些手段可以消除这些重复
达到精简代码,快速开发的目的
有兴趣可看看鄙人整的东东
 
http://www.iteye.com/topic/257804


1 请登录后投票
   发表时间:2008-10-29  
做Java也几年了,从来不觉得所谓的代码生成技术有什么好处,也从来没有看到一个框架能做到所谓的快速开发。

在企业应用领域,业务逻辑都比较复杂,简单的代码生成不具备可用性是毋庸置疑的,这些logic你都能生成?客户来一句业务限制你马上歇菜。

在互联网领域,由于界面和设计上的改动,整体结构的变化很大,所以代码生成技术带来的好处也不大。至于说到快速开发框架,谁能保证它的性能?谁能保证它的无限可扩展性?

综合来说,踏踏实实写你的代码,不要试图通过投机取巧来获得任何好处,这样的结果只能让项目变得更烂。

另外想提一点,在开发过程中,最佳实践总是不断总结的,而还有一些通用组件会被不断提取出来,这些通用组件与所谓的代码生成或者快速开发框架并没有很大的联系,不过这些最佳实践和通用组件能大大降低我们的开发成本。
2 请登录后投票
   发表时间:2008-10-29  
downpour 写道
做Java也几年了,从来不觉得所谓的代码生成技术有什么好处,也从来没有看到一个框架能做到所谓的快速开发。

在企业应用领域,业务逻辑都比较复杂,简单的代码生成不具备可用性是毋庸置疑的,这些logic你都能生成?客户来一句业务限制你马上歇菜。

在互联网领域,由于界面和设计上的改动,整体结构的变化很大,所以代码生成技术带来的好处也不大。至于说到快速开发框架,谁能保证它的性能?谁能保证它的无限可扩展性?

综合来说,踏踏实实写你的代码,不要试图通过投机取巧来获得任何好处,这样的结果只能让项目变得更烂。

另外想提一点,在开发过程中,最佳实践总是不断总结的,而还有一些通用组件会被不断提取出来,这些通用组件与所谓的代码生成或者快速开发框架并没有很大的联系,不过这些最佳实践和通用组件能大大降低我们的开发成本。


确实如此。用手写代码,不光是一个编写的过程,更是一个体会的过程。 如何,把一些近乎公式化的代码写得更优雅,更有效。 而这些快速开发框架,只能秀出开发人自己的技术有多强大,对于实际业务没有什么用处,可能还会有一些隐藏的问题。

针对我现在的项目,手下的几位仁兄一直抱怨框架烂,很多重复的代码什么的。 我开始也是这种想法。 但是没有办法,在我接手的时候,框架早已完成了。 于是按照这种情况,我也给他们设计了一个基本的代码设计器。 由于是贴合业务的,所以说并不复杂。 但是,随后在客户websphere发布时出的一个十分诡异,甚至花高价请专家都无法解决的问题,让我彻底放弃了我那个自动代码生成器。 放弃了所有由那个生成器生成的代码。
0 请登录后投票
   发表时间:2008-10-29  
能够互相结合是最好的。80%的工作由电脑自动完成,剩余的20%再花脑子去完成。
0 请登录后投票
   发表时间:2008-10-29  
jindw 写道
最近论坛里出现了不少关于此类的文章:
引用
秀一下我的快速开发平台
http://www.iteye.com/post/711399
http://www.iteye.com/topic/258458

忘掉普元EOS、构建自己的企业级快速应用开发平台
http://www.iteye.com/topic/232219


我也做过类似的东西,现在也一直在用。
但是越来越感觉那是鸡肋。
http://www.iteye.com/topic/95580

有一次,开发一个公司内部使用的图书馆里系统,前后只花了一个下午,把老板吓一跳,并支持我利用工作时间完善那套框架。

确实,在某些情况下,他可以极大的提高我们的开发效率。

但是,我们忘记了这类系统高昂的开发和推广、学习、维护成本。

刚才查了一下,我那个代码生成器,单源代码就是6.5M。
如此一个不知名的第三方开发的庞大的系统,你不搞清楚其内部逻辑你敢随便使用吗?而真正搞清楚这些东西的代价有多大,后期扩展,维护的风险多大!

从我来讲,我不敢用。

我想,做这种东西有一个强大的后台公司支持还好,如EOS后面有普元。
而作为个人开发者,我们如何能打通这条产业链,如何让别人信任,学会,并采纳你的设计思想,让足够多的人去分享去使用你的产品,这些可不是一个技术问题。

Java程序员可能都有一个好大喜功的特性,环境所致把。

但是我们还是应该充分认识到自己个人力量的有限。

要做什么东西的话,先别想着如果别人用这个东西可以提高多少多少的开发效率。
只有它能给自己带来足够的好处,你才能做下去,否则很难生存。
穷则独善其身。

有什么考虑不对的地方,大家来提提把。


很有幸,我也被楼主列为反面教材了,呵呵!
不过楼主能把一个代码生成器的源代码整成6.5M,在我看来实在是夸张了些,我不敢说你对平台的理解有误,但我可以肯定,你把平台这个东西复杂化了!也许是在下粗鄙,做的东西实在不登大雅之堂,我的整个代码生成器也就40多个类,不到5000行的代码量,这个估计也抵不上楼主的一个零头了吧!
至于这个东西有没有用,有什么用,我想在我的文章里大家都已经仁者见仁,智者见智了,实在也没必要在这里再重复个一二三了!
其实我个人觉得这完全没有必要成为一个问题,也不应该是个问题!是不是自己做基础平台和代码生成器这个东西,完全是你个人、团队的事,有能力就做,没有能力就别做!至于做出来的人要在这里发个贴,给感兴趣的同仁们一个参考什么的,也完全是一片好意,完全没必要上纲上线。大家都是从事脑力劳动的人,有意识,有主见,也不是我们这些小程序员一两篇文章所能忽悠的!
至于楼主说整这个东西得公司行为,个人做不了。我倒不敢苟同,至少对于我们团队来说,我们把这个东西做出来了,而且用的很好,这就足够了,至于别人是不是认可我们的东西,我倒不是太关心(诽谤除外 :) ),我们也没有成天想着如何把这个东西像XXX公司那样卖他个百八十万的,我们这些文章,大家若觉得有用就笑纳,没有用就当放屁,呵呵!不过单从文章的访问量来看,我想也不至于人人都当俺们是放屁吧,呵呵!
另外也给楼主提个建议,不要动不动把普元扯进来,难免让人此地无银三百两,沦为枪手贴之嫌!
0 请登录后投票
   发表时间:2008-10-29  
呵呵,首先我得申明一下,我并没有任何恶意,看到你们做得东西确实也很不错。
大家都是过来人了,其中滋味我想大家自己也很清楚。当能,承认这里的个体差异。

有一天,我要去敲一个钉子,那么我有下面三个选择:
1。接合自身特点,自己铸一把锤子,把这个钉子丁下去。
2。市场上买把或者邻居家借把普通得锤子,把这个钉子钉下去。
3。随便找一快能用得石头,吧这个钉子钉下去。

没有任何一个选择是任何时候都正确。不同的人,不同的职业阶段,不同的环境我们会有不同的选择。

从成本的角度考虑,选择不同的方案取决于我有多少钉子去钉。
从个人成就感考虑,我们可能毫无疑问的选择方案一。
0 请登录后投票
   发表时间:2008-10-29  
fireflyc 写道

一种,减少代码量。
第二种,代码生成技术。
。。。。

总结的非常不错。
关于第一种情况,主要是框架乃至编程语言的改进。能做到这点当能是最好。

但是现实中我们往往只能退而求其次。我们往往是游走在不同的第三方框架提供的服务中,比如说我们用hibernate,用spring,用webwork,而他们是相互独立的系统,我们只是在他们的狭缝中游走,代码生成在这里也就成了一中可选的黏合剂。
4 请登录后投票
论坛首页 Java企业应用版

跳转论坛:
Global site tag (gtag.js) - Google Analytics