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

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

引用

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

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

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

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

评论

62 楼 sphenx 2008-10-31  

sphenx 写道

jindw 写道

这里我倒是看到了xml和annotation之间有一个代码生成的需求。

annotation最大的好处是，IDE语法检查，重构非常友好。
代码紧凑，同一个事情不必不同文件间反复跳转。

这对开发非常有利。

但是一到实施就麻烦了，不要我改一点配置就重新编译吧。

hibernate 有自己的官方annotation2xml转换工具，其他的呢？webwork，spring这方面有没有工具支持？

用xml还是annotation的关键是，你的配置指定的属性到底是依赖于环境还是依赖于自己
1. xml是用于做外部资源指定的，它会随环境变化而变化。如，用xml指定连接的数据库的属性。
2. annotation是用来指定自身属性的，它只随自身的变化而变化。 如，用annotation指定一个bean是否是serializable。

如果在第一种情况下用annotation，显然有害无益；反之也一样。所以，xml和annotation各有优缺点，各有擅长。一味的用xml或一味的用annotation，都有问题。

61 楼 sphenx 2008-10-31  

jindw 写道

这里我倒是看到了xml和annotation之间有一个代码生成的需求。

annotation最大的好处是，IDE语法检查，重构非常友好。
代码紧凑，同一个事情不必不同文件间反复跳转。

这对开发非常有利。

但是一到实施就麻烦了，不要我改一点配置就重新编译吧。

hibernate 有自己的官方annotation2xml转换工具，其他的呢？webwork，spring这方面有没有工具支持？

用xml还是annotation的关键是，你的配置指定的属性到底是依赖于环境还是依赖于自己
1. xml是用于做外部资源指定的，它会随环境变化而变化。如，用xml指定连接的数据库的属性。
2. annotation是用来指定自身属性的，它只随自身的变化而变化。 如，用annotation指定一个bean是否是serializable。

60 楼 jindw 2008-10-31  

这里我倒是看到了xml和annotation之间有一个代码生成的需求。

annotation最大的好处是，IDE语法检查，重构非常友好。
代码紧凑，同一个事情不必不同文件间反复跳转。

这对开发非常有利。

但是一到实施就麻烦了，不要我改一点配置就重新编译吧。

hibernate 有自己的官方annotation2xml转换工具，其他的呢？webwork，spring这方面有没有工具支持？

59 楼 icewubin 2008-10-31  

aws 写道

XML配置在实施的时候也比较好用

那你说的就是为实施服务的配置，还有更多的配置是实施的时候是用不到的。

58 楼 aws 2008-10-31  

XML配置在实施的时候也比较好用

57 楼 sphenx 2008-10-31  

假设有这样一种情况：
1. 有一个class叫FrameWork，它要调用某个job类的某个方法来工作
2. 要使Framwork工作需要做两个配置
   a. 指定使用的job类
   b. 指定job类的一个方法

那么我们应该用xml还是annotation来完成配置呢？
答案应该是，两者结合
a. 在一个xml配置文件中指定job类
b. 在job类的某个方法上用annotation来指定该方法为framework需要调用的方法

56 楼 jindw 2008-10-31  

超级潜水员 写道

不进则退，楼主自己写了个生成器，就以为所有人写的东西都如LZ的生成器一样。
而一个开发经验过多的人，也会限入某个条条框框，而不知现在的事物都是在发展中的。

这里不是在讨论技术上孰优孰劣。
只是说这个方向可能纯在的一些现实问题。


孙子说过：
不尽知用兵之害者，则不能尽知用兵之利。
我们头脑一热，就会冒出许多宏伟的计划。但是实施起来，确是困难重重。没准劳命伤财，受害的都是自己。

混的时间常了，越来越倾向于老子的无为之治。
我们过度的强调自己的有为，最后往往是吧自己忘泥潭子里推。

初学分布，但求平正；既能平正，务追险绝；既能险绝，复归平正。初谓未及，中则过之，后乃通会。


当能，我的观点或许是片面了点，我也希望有位天才能够站出来，凭着自己的盖世武功来拯救世界，可惜，我苦苦等了27年，这个英雄还是没有出现。

55 楼 超级潜水员 2008-10-31  

不进则退，楼主自己写了个生成器，就以为所有人写的东西都如LZ的生成器一样。
而一个开发经验过多的人，也会限入某个条条框框，而不知现在的事物都是在发展中的。

54 楼 jindw 2008-10-31  

amonlei 写道

elmar 写道

jindw 写道

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

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

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

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

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

石器时代？？？？有轮子了？？？？现在是一个重复造轮的时代。。。

轮子是任何时候都要造的，马路上跑的轮子是上不了铁轨的，高铁的轮子看似简单，里面的学问大着呢，如果我们本着不重复发明轮子的态度，哪估计是不知道要死多少人的。

或许轮子的最高境界就是没有轮子，看看人家磁悬浮，呵呵

“重复发明轮子”这个比喻是否少了点说服力呢？
扯远了，呵呵

53 楼 心无旁骛 2008-10-31  

koda 写道

无稽之谈..

顶，同感
这个帖子就不要放到首页来浪费版面了
楼主在这么经验太少，还是不要随便下结论的好

52 楼 koda 2008-10-31  

无稽之谈..

51 楼 hellboy 2008-10-31  

每个人在自己的每天工作当中，都应该去想如何提高自己的工作效率问题，解决的方法有很多种，关键在于，我们有没有想过这个问题，致于如何解决，那只是手法问题。

我自己就做自己的快速开发平台，那是我平常工作的总结，里面积累我自己的很多东西，确实能帮我提高工作效率。

代码生成器确实不是万能的，无论你的代码有多精简，但不可否认的是，真正的项目开发中，确实存在很多重复的劳动，了解代码生成器，自己快速修改模板，确实可以大提高开发效率，比ctrl+v,c,要好的多。

50 楼 amonlei 2008-10-31  

elmar 写道

jindw 写道

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

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

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

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

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

石器时代？？？？有轮子了？？？？现在是一个重复造轮的时代。。。

49 楼 zhuzhsh 2008-10-31  

首先得有一个好一个的架构，在这架构上开发的东西能保证写最少的代码，这是代码生成的前提。有一个好的架构的基础上再去考虑有一些重复性的代码，像jsp页面写起来本身就是很麻烦和重复性的东西，而且经常出现人为的错误。
理解好架构然后用代码生成机去生成一些一看就明白的代码才是关键。
没有一个好的架构或者不理解正在使用的架构，用人工或者自动生成都是一个样。

48 楼 fcm915 2008-10-31  

我觉得.对于大公司来说,后期维护简直就是鸡肋.
但是对于小公司的一些软件外包,大部分都是CURD的操作.没有太大的业务逻辑.
反而用这个比较好.小项目维护起来也比较简单.
个人观点.还没有用过生成器.

47 楼 icewubin 2008-10-30  

jindw 写道

icewubin 写道

yanwt 写道

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

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

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

xml的这个优点还是有点用处的，比如说有些项目我们不能给交互源代码，如果你吧配置都放注解里了，那就麻烦了。

xml当然是有用的，我说了要看这个xml配置是做什么用途的，比如Spring的通用配置当然是放在xml中要比一个一个的写在注解里要高明，像你说的特殊用途也完全可以这样，因为你们约定了把你们的配置作为交流工具，再说像你这样的情况真要以某种格式导出注解，我想也不难吧，可能可读性还要大大优于XML呢。

我指的是更多的情况下，专用配置文件在软件工程中就是应该作为代码来对待的，不应该有那种盲目的“配置优于代码”的僵化观念，有不少人还是一根筋认为任何情况下，东西写在配置里要比写在代码里好。

46 楼 yunsong 2008-10-30  

不相信有银弹，也许从来都不会有

45 楼 jindw 2008-10-30  

icewubin 写道

yanwt 写道

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

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

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

xml的这个优点还是有点用处的，比如说有些项目我们不能给交互源代码，如果你吧配置都放注解里了，那就麻烦了。

44 楼 mathsfan 2008-10-30  

能提高效率时干嘛不用？对公司对个人都是好事，特别老是ctrl+c,ctrl+v的做的不烦吗？

43 楼 icewubin 2008-10-30  

elvea 写道

icewubin 写道

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

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

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

我举这个例子正好是“称赞”代码生成的，再拿代码生成类比软件业和建筑业完全不一样。

1.建筑业中即使桩啊什么的，这些通常都是在外面完成的，仍然是要有固定成本的，再次举例软件业中的代码生成，是近乎零成本的，建筑业无法复制，也没这个能力。建筑业本身的固有的复杂度，和可以降低的成本的空间已经很低了，早上了流程化和制度化的道路，软件业早着呢。你看看软件业技术本身的发展，抽象不断提升，不断有底层或者重复的事情由机器或自动生成代码（不管是事先的还是运行时的）来替代，而不是由所谓的“软件民工”来替代。

2.如果有更好的方式，这就是不值得鼓励的。好比，你对我说燃烧氢的汽车有多环保，你说的没错，和传统烧汽油的比这是一定的，但是我肯定马上说，同样用氢的燃料电池汽车更环保，有更好的技术为什么不发展更好的技术呢？

像JSP编译成servlet，servlet编译成class，c编译成二进制执行码，java编译成class，Javascript运行时动态生成某些匿名对象，都是代码生成，只不过是运行时生成的，这当然是首选，而不是在开发阶段就去生成这些代码。

或者说，当你发现有些工作是需要代码生成的，都可以提炼共性需求采用运行时的代码生成来替代。
一个典型的例子如下：
场景1.某天某个程序员用了装饰模式封装了一个类的所有方法，对外保持透明，对内扩展了原来类的功能。
场景2.然后这个程序员发现他有好几个类都需要这样的装饰模式封装一下，但是封装的策略几乎都是一样，于是他写了个工具类来自动生成这些进一步封装的中间类。（很多人认为这个境界已经很高了，到顶了，是么？）
场景3.另一个程序员，看到他这样做以后建议他使用AspectJ，来做切面，具体过程就不说了，最终效果就是运行时动态生成中间类，来做原始类的代理。从整个过程来讲，各种成本不比第2种场景低么？