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

最近论坛里出现了不少关于此类的文章：

引用

秀一下我的快速开发平台
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程序员可能都有一个好大喜功的特性，环境所致把。

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

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

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

评论

42 楼 yangyi 2008-10-30  

我个人是支持针对某个特殊业务的通用架构的，谁说平台没钱途，那你看看一个Siebel可以卖多少钱，至于代码生成就不敢恭维喽。要做就做得彻底点，像siebel一样连界面也做了。不过话说回来，如果连界面也做了那么通用性必然受限制，所以我说这样的平台应该限制在某个业务范围之内。工作流也不是万能的。

41 楼 elvea 2008-10-30  

icewubin 写道

yiwujiaoyu 写道

elmar 写道

jindw 写道

呵呵，首先我得申明一下，我并没有任何恶意，看到你们做得东西确实也很不错。
大家都是过来人了，其中滋味我想大家自己也很清楚。当能，承认这里的个体差异。

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

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

从成本的角度考虑，选择不同的方案取决于我有多少钉子去钉。
从个人成就感考虑，我们可能毫无疑问的选择方案一。

这个是石器时代的做法啊。不过，话说回来了，软件开发本来就处于石器时代。

软件还没到建筑业发展的程度，未来就会的

说到建筑业，我刚才贬了代码生成，现在拿他来举个例子。

建筑业不可能通过某一个事先造好的机器（这个机器是要成本的），来近乎无成本的生成墙壁和房间吧，即使墙壁和房间都是同一尺寸一模一样的功能，幻想软件业变成制造业和建筑业那样的模式是行不通的，软件业总有很多“偷懒”的人会用各种办法来减少重复，建筑业行么？房间和墙壁再一样，还得用民工去造。

打个比方，就好象说一座大厦，很多部件啊，比如桩啊什么的，这些通常都是在外面完成的，这样就不用说每次建楼的时候，都要在建筑工地上再什么都重头来过。
代码生成不是万能的，但是我不反对代码生成，简单的代码生成可以生成一些架构性的东西，我们就可以在这个上面建筑我们自己的逻辑，难道这个不是应值得鼓励的吗？

40 楼 nychen2000 2008-10-30  

这瓢冷水泼得好!!!

39 楼 murainwood 2008-10-30  

daquan198163 写道

码是用来给人看的，代码是要长期维护的，什么时候代码生成器弄出来的代码可以满足这两样需求，它才有可能被接受
因为软件整个生命周期的成本，大头儿在后期维护

  

38 楼 murainwood 2008-10-30  

大公司流程重得很，想快都快不起来，
所以我就8关心那些玩意儿了。。。

37 楼 daquan198163 2008-10-30  

代码是用来给人看的，代码是要长期维护的，什么时候代码生成器弄出来的代码可以满足这两样需求，它才有可能被接受
因为软件整个生命周期的成本，大头儿在后期维护

36 楼 aoaoao 2008-10-30  

代码生成比较适合开发方式受限的外包公司，IT民工本来干的就是重复劳动的事，项目不允许你其他技术减少代码。

35 楼 icewubin 2008-10-30  

yiwujiaoyu 写道

elmar 写道

jindw 写道

呵呵，首先我得申明一下，我并没有任何恶意，看到你们做得东西确实也很不错。
大家都是过来人了，其中滋味我想大家自己也很清楚。当能，承认这里的个体差异。

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

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

从成本的角度考虑，选择不同的方案取决于我有多少钉子去钉。
从个人成就感考虑，我们可能毫无疑问的选择方案一。

这个是石器时代的做法啊。不过，话说回来了，软件开发本来就处于石器时代。

软件还没到建筑业发展的程度，未来就会的

说到建筑业，我刚才贬了代码生成，现在拿他来举个例子。

建筑业不可能通过某一个事先造好的机器（这个机器是要成本的），来近乎无成本的生成墙壁和房间吧，即使墙壁和房间都是同一尺寸一模一样的功能，幻想软件业变成制造业和建筑业那样的模式是行不通的，软件业总有很多“偷懒”的人会用各种办法来减少重复，建筑业行么？房间和墙壁再一样，还得用民工去造。

34 楼 icewubin 2008-10-30  

yanwt 写道

xml做配置的优点是，修改配置不需要重新编译源文件，这个注解是做不到的。

这根本就是一个伪命题。什么场景需要这样？测试的时候本来就不会在意编译速度，而看重重新发布是否需要重启应用服务器，支不支持热部署。要说热部署，java文件的热部署能力的还比配置文件来的高呢。

如果是生产环境，能随便修改配置文件么，如果需要修改，会产生只改配置文件，而不改任何代码的情况么，绝对不可能，我特意说了配置文件主要有两种，专门为代码服务的配置文件根本不存在只改配置文件而不改代码的场景，测试的时候可能会碰到，但是测试的时候不在乎编译速度。

33 楼 btprince 2008-10-30  

人们总是太理想化，妄图搞个东西出来解决所有问题，这是不对的。
无论是代码生成还是开发平台本身都有其适用的范围，不能妄图其解决一切问题。只要在实际使用中帮助开发者提高了效率，解决了一些问题，这就是成功的。应该在一定适用范围里讨论问题，否则没什么意义。

三蹦子不安全、速度慢、无照经营，但还是有人坐啊！

32 楼 fireflyc 2008-10-30  

<p>      就快速开发而言，我认为这是一种管理层面上的东西而不是太多的技术上。须知道软件生命周期中除了编码时间还有别的时间。假设编码时间占项目时间的80%左右那么节省编码时间自然是客观的，假如说只占了20%甚至10%左右那么这个节省的就不合算了。所以应该叫做<span style='color: #ff0000; font-size: medium;'><strong>快速编码或者叫做技术的快速开发</strong></span>。</p>
<p> </p>
<p>     就快速编码（技术的快速开发）而言，针对java本身来说。<span style='color: #ff0000; font-size: medium;'><strong>除非你彻底的放弃现有的经验否则你所做的一切试图快速的做法都逃不出代码生成的圈子</strong></span>。试想一下我们废除DAO，废除Service，只有domain 和web，这种做法如何让人能接受？做过java的都肯定会质疑，这种做法行吗？这不是耦合吗？姑且不讲这说法的正确性如何。但就此疑问而言就可以说你不可能来一次革命。你彻底革命会让那些朋友难以接受的，试想一下把一个原始社会的人拉到现代社会，给他喝可乐，吃冰激凌，看非常6+1，玩计算机游戏。你能想想他会是什么表情，什么心理，而且他也不可能做好这些事情。</p>
<p> </p>
<p>     现在要么是围着web层打转转，要么是代码生成技术。谈不上快速开发，充其量只能算是<span style='font-size: medium;'><strong><span style='color: #ff0000;'>快速编码</span></strong></span></p>
<p> </p>
<p> </p>
<p>03年我读书的时候在程序员杂志上介绍了一本叫做《快速软件开发》的书。那时候敏捷来时汹汹，这本书被当时成为最后的传统软件工程经典。当时我买来看了，一知半解，但是后来我越发的认识到其中的奥秘，认识到什么才是快速开发了。快速开发而不是快速编码。这本书现在出了经典版，我买来做了收藏。大家喜欢快速开发的朋友不妨一读。</p>

31 楼 yiwujiaoyu 2008-10-30  

elmar 写道

jindw 写道

呵呵，首先我得申明一下，我并没有任何恶意，看到你们做得东西确实也很不错。
大家都是过来人了，其中滋味我想大家自己也很清楚。当能，承认这里的个体差异。

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

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

从成本的角度考虑，选择不同的方案取决于我有多少钉子去钉。
从个人成就感考虑，我们可能毫无疑问的选择方案一。

这个是石器时代的做法啊。不过，话说回来了，软件开发本来就处于石器时代。

软件还没到建筑业发展的程度，未来就会的

30 楼 yiwujiaoyu 2008-10-30  

downpour 写道

做Java也几年了，从来不觉得所谓的代码生成技术有什么好处，也从来没有看到一个框架能做到所谓的快速开发。

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

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

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

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

踏踏实实的 写代码，确实如此。

29 楼 elmar 2008-10-30  

jindw 写道

呵呵，首先我得申明一下，我并没有任何恶意，看到你们做得东西确实也很不错。
大家都是过来人了，其中滋味我想大家自己也很清楚。当能，承认这里的个体差异。

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

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

从成本的角度考虑，选择不同的方案取决于我有多少钉子去钉。
从个人成就感考虑，我们可能毫无疑问的选择方案一。[b][/b]

方案一这个是石器时代的做法啊。不过，话说回来了，软件开发本来就处于石器时代。

28 楼 fireflyc 2008-10-30  

<p>以上有不少同学是支持代码生成的，看来有必要继承一下rod joshon大叔的优良传统，对这种“封建的官僚主义”作风给予批判了。:-)~~以下是个人观点：（哈哈~）<br/><br/><span style='color: #ff0000; font-size: small;'><strong>代码生成本质上没有减少代码量的</strong></span></p>
<p> </p>
<p>代码生成技术只是把以前手工书写的代码变成了计算机自动生成的技术（只是手工ctrl+c ctrl+v的自动化版本），这种层面上说这些生成的代码其实是一种重复的东西，它们必然是类似的。有重复维护的时候就必然是一场噩梦。代码生成依然有很多代码，这些代码你依然要维护。更要命的是这是一种重复的行为，重复必然会引起以后修改的麻烦。</p>
<p> </p>
<p>另外再次讨论一下我对注解的观点：</p>
<p>注解不能代替配置文件，配置文件的产生是为了方便修改配置文件而不是代码。比如数据库连接之类的，我们要以注解的形式放到代码中吗？再比如一个web层的action，它的返回模板需要以注解的形式放到代码中吗？有一天你把这些模板的路径修改了怎么办？（比如让模板的目录的结构更加清晰）你需要修改所有的action。这和直接写在action中有什么区别吗？你写到方法的上面和用后面return返回有什么区别吗？没有丝毫的区别，而且你写在注解上更让人看不懂，更费解了。</p>
<p> </p>
<p>上面有朋友提到EJB3的注解，这种注解是合理的使用。我们没有可能在运行着系统的时候突然有一天说，把我们的EJB的remote接口变成local的吧，或者突然有一天说把我们的session bean由无状态变成有状态的吧。这种情况几乎没有的，即使有那么不修改代码也是不可能的。所以这些标志ejb接口remote、local标志session bean的特征应该是和代码在一起的，它们修改一定会引起代码的修改。</p>
<p> </p>
<p>综上总结一下：<span style='font-size: small;'><strong><span style='color: #ff0000;'>注解是代码</span></strong></span>，它本身就是一种硬编码的形式。<strong><span style='color: #ff0000; font-size: small;'>配置是外部的，配置的本意就是为了配置</span></strong></p>

27 楼 icewubin 2008-10-30  

yanwt 写道

icewubin 写道

yanwt 写道

现在这个问题没有谁对谁错，支持代码生成的人是想在现有架构上面生成一些需要ctrl+c，ctrl+v操作的代码，由机器生成了，好处是生成一些配置文件不会出错，不需要大量的改动，增加工作效率。另一部分人是，想从根本上改变架构，尽量减少代码量，就目前的情况来看感觉不太现实。我做过的项目都是基于数据库的，持久化操作每个表都要写，每个表是不一样的，这部分代码是可以自动生成的。如果有人愿意自己写，我不反对，反正我是不喜欢重复的劳动。

Hibernate、iBatis、Spring JdbcTemplate都是动态生成sql的框架，何必事先生成？

当然是第一种方法好，也是大方向。

反过来说Hibernate的作者为什么不写个事先的sql生成工具呢，他完全有这个能力的。

难道你不需要写数据库和对象之间的映射吗？不需要工具帮你生成？自己手写吗？我很佩服

基本不需要写，你可以参考ror的方式，SpringSide3也可以参考一下，或者看一下这个类org.hibernate.cfg.ImprovedNamingStrategy，代码生成本身就是一种笨拙的技巧，不失灵活性的动态生成加约定不是很好么。

26 楼 icewubin 2008-10-30  

fireflyc 写道

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

首先你把普通的配置文件和专用配置文件搞混了，专用配置文件，比如Hibernate或dwr的配置文件，这些配置文件就是为代码服务的，不客气地说，这些配置文件就是代码，所以采用注解的方式，代码量上一定是减少的，因为xml作配置文件本身就不太合适，多余的字符特别多。同时IDE对注解的支持要远胜xml配置文件，在做重构、自动补全、编译期检查、单元测试和部署、代码维护（可读性和易读性方面）的环节上都能节省下大量的时间。

25 楼 smilerain 2008-10-30  

快熟开发和智能开发还有很大的距离,虽然大家谈的是是快速开发,
不如说是想达到智能开发.
在本人开来,一门成熟的语言+上成熟的构架在有个好的ide环境就算快速开发了.
比在dos上快多了.但要智能化的完成逻辑部分代码.才是下一步要解决的问题.

24 楼 icewubin 2008-10-30  

raymond2006k 写道

很同意大家回复的观点。

我的感觉， 美国人(或者外国人)做的东西， EJB，Hibernate，Spring，.... 中国人都会虚心学习；即便有缺点，也不太会有大的反对，而会探究是否是误用。

而同样的东西，中国人做出来，首先自己都觉得怀疑；还没详细了解清楚，就挑三挑四。中国人缺的就是自信，对自己自信，对他人自信。其实，我呆过的几个公司，都有技术牛人，能做二次封装，改良，或者框架等，而且做的都很棒；如几个牛人集中起来，也能做很多框架出来。现在 javaeye上的牛人也很多啊 。

只是希望国人对他人的创新多多互相评估，试用，以建设性的态度提意见，提缺点，提改进意见。

你认为的“中国人都会虚心学习；即便有缺点，也不太会有大的反对，而会探究是否是误用。”本身就是有问题的，老外每年也产出无数的框架，中国人难道每个都虚心学习；即便有缺点，也不太会有大的反对么？

都是在这些框架成熟（其他老外的认可）以后，这些框架的作者才会被称为牛人，先有鸡还是先有蛋不要搞混了。

23 楼 icewubin 2008-10-30  

yanwt 写道

现在这个问题没有谁对谁错，支持代码生成的人是想在现有架构上面生成一些需要ctrl+c，ctrl+v操作的代码，由机器生成了，好处是生成一些配置文件不会出错，不需要大量的改动，增加工作效率。另一部分人是，想从根本上改变架构，尽量减少代码量，就目前的情况来看感觉不太现实。我做过的项目都是基于数据库的，持久化操作每个表都要写，每个表是不一样的，这部分代码是可以自动生成的。如果有人愿意自己写，我不反对，反正我是不喜欢重复的劳动。

Hibernate、iBatis、Spring JdbcTemplate都是动态生成sql的框架，何必事先生成？

当然是第一种方法好，也是大方向。

反过来说Hibernate的作者为什么不写个事先的sql生成工具呢，他完全有这个能力的。