代码生成器是否需要？

  对于代码生成器之类的快速搭建工具我一向是不怎么感冒的，可是最近发生的2件事情让我又重新感冒了

  首先是前几天一个兄弟公司向我们展示了一套在线办公系统的软件，其中包含一个自定义表单的功能。大概就是通过一个gui界面配置，可以直接生成web界面。并且可以与工作流结合，权限结合。
  这套自定义表单的作用有2点
       1 快速搭建界面原型
       2 快速进行二次开发

  我感觉缺点也很明显
       1 与在线办公系统绑定
       2 生成的界面固定
       3 非开放技术
       4 生成代码的可修改行（没见过，怀疑一下）
 
  其次就是现在做的一个项目，客户问我有没有代码生成器之类的，我说“没”，然后客户就说，xxx公司就有一套，可以让开发时间缩短。我强烈的感觉到代码生成器这种东西对于忽悠客户来说，真的是一件利器！

  那我是不是也应该建议公司搞一套呢？ 忽悠客户 + 提高开发效率？

 

代码生成器是开发的辅助手段。但是这东西只适合简单的、固定的东西。比如建立一个表的基本CRUD。但是稍微麻烦一点的就不能用它了。
你开发一个代码生成器给谁用呢？
客户？拜托，他们中很多甚至连杀毒软件如何升级都不知道，怎么会用这个？
开发人员？固定但是琐碎的东西辅助生成一下还可以，然后还是要在生成的基础上修修改改。这里如果用得好的话能够提高开发效率，但是如果生成的代码结构是大家不熟悉和讨厌的，还是不要用了。
实施人员？对了，你说的这种东西就是给他们用的。总有人想要做个万能平台出来，程序员开发完了平台就不用再开发了。实施人员到客户那里把平台一安，然后上面用生成器一配，客户系统开发完成。但是实际上是不可能的。至少现在的软件工程水平达不到。这种生成器、配置器只能配置配置他们定义好的，如果出现些个性化的需求，立马歇菜。甚至你说我用代码写都不成，内部封装了，不许进。

所以如果你做的是产品，而且客户需求基本都一样（差不多是到客户，直接安装，收钱，走人的水平），那么搞这个还可能有点用。可以让实施人员调整的余地大一些。
如果你每个项目都不一样，那么这东西还不如不要，用了反而缚手缚脚。

你应该和客户解释。代码生成器这东西对客户用处不大。
首先客户自己不用。就是客户会用，一般也怕搞错了，会让程序员来配。
其次，成本很大。如果代码生成器功能太差，没任何用处。功能太强，开发成本要客户买单的。
再次，生成的代码效率要比人编写得差。很多功能强大的生成器，里面到处都是XML之类的配置。不然没法灵活。但是这造成性能急剧下降。

所以，你要做的不是给客户开发一个生成器。而是打消他这个不怎么切合实际的念头。这东西客户基本上不用着，白花钱。而且功能弱了没用，强了比自己写还麻烦。你看看SAP的ERP，它倒是灵活了，但是整个一门新语言。购买成本、人员培训、开发维护哪个不需要钱。

我和你想的一样


客户不用这个，问题是我的竞争对说说他有这个，客户认为他们的开发效率一定高于我们


基本上我拿到的一个快速框架我是很不熟悉，至于代码结构那更是要从头学起。
但是 这么多坏处都不如一个亮点让人注目，那就是确实在几分钟以内能够出来一个CRUD的界面，在老板、客户眼里，这就是效率！


是有一种情况，只是业务代表用，用它来快速搭建界面原型，挖掘客户需求。。。。 这也是一个经验。
但是没有说要求能够做到直接用的地步。




暂无这类需求


我们的竞争者用到 这个东西，我还真不好意思跟客户说这个东西是个垃圾，毕竟我们也没有看到人家的东西呀
另外，如果我老板搞到的这个，我也不好意思说这个东西是个垃圾呀。



哎，彻底打击我了。投降

如果你想高效快速开发的话，Rails、Grails、Django都可以拿来用。Rails、Grails自动生成CRUD、Django自动建立后台管理界面。这些都可以极大地提高开发效率。
你不好意思直接说可以换个角度说。我口才不好，交不了你。不过你只要围绕一点就可以，即“成本大于产出”。

如果贵公司的产品比较固定，可以抽取出比较共用的东西，能够做成通过程序来生成。
倒是可以做做。

就好比报表工具一样，通过界面拖动，实现报表。

或则和delphi这类的工具一样，通过界面拖动，生成代码，也可以自己写代码来实现界面。

做一个也不是很难。
投入多，就做酷点；投入少，就做简单点。真的要做，就原型来说，也就是一两周的事吧。

赞同，如果原来的开发够规范，不断的抽取共性的东西，做个简单的CRUD代码生成，十天就足够了。

“谢谢您的建议，但这种事情还是我们内行人来决定好吗？”

问题的关键在定位代码生成器的功能范围.
1. 究竟解决那些问题
2. 用于那个场合
3. 投入/收益分析比较
泛泛的说代码生成器,这个圈太大了,最后只能是自说自话,最后发现讨论的根本不是一个东西.