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

这瓢冷水泼得好!!!

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

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

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

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

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

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

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

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

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

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

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

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

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

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