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

您说对了，大部分的政府项目就是这样的。

说具体点就是，当某个政府领导发现有三家乙方的质量是差不多的（即使真的有上下，不等于这个领导有能力分辨出来），这个时候就看谁关系硬，谁更能忽悠。

至于回扣等其他黑幕我就不一一列举了。

配置的可修改性，估计就像那神七的逃逸塔吧。
虽然不一定能用上，他是有总比没有的好，但是有这个东西就更放心了。

我自己也没有碰到过实施阶段需要修改配置的情况，纸上谈兵吧。

“Java框架思想综合征”就是这个毛病，什么都是有比没有好，好比java没有真正的析构函数，根据有比没有好的原则，难道放弃Java去用C++或者C，完全自己控制资源，有比没有好啊，总有场景会碰到需要自己主动释放资源的情况，对吧。

你再想想上面我说的反话，或者说，等你有了实际部署经验再来讨论吧。

我再一次强调，配置即使是部署型xml一样是要作为代码来看待的，必须要纳入版本控制，不能随意人工修改的，否则风险和部署时的bug不可控，所以单独只修改配置（不编译或者不调试或者不测试）的需求场景是根本不存在的。

而一旦部署型xml纳入版本控制，有以下好处：
1.极大的降低部署人员的素质要求，降低成本，尤其是产品型部署，不可能派开发人员频繁参与部署任务，那是对开发人员的极大浪费，开发人员也没有专门的支持人员更容易和客户沟通。国内还有个不好的习惯是，一旦放开发人员直接去部署，和客户熟了以后，客户往往直接找开发人员变更需求，这是绝对不可取，对公司的商务极其不利的结果，必须要有支持人员或者其他角色在中间拦截。一方面不能随意浪费开发人员的成本去为客户修改（带来商务上的极大的不利，开发人员不是销售，随口一句“我半天就能搞定”往往害惨所有相关人员），另一方面即使真要修改也不能随便答应，客户脱口而出未经仔细推敲的需求往往是有隐患的，或者是他表达的意思不完全，匆忙的交待往往是会产生需求歧义的。

2.能很好的控制测试任务、版本发布和分支版本的bug修改。通过制定的svn版本和实现全自动化的ant，集成测试人员能够很方便的自行打包测试，完全不需要去打扰开发人员，减少沟通成本。实施人员也能够根据要实施的客户、版本号来自行或者委托集成测试人员打包（为了节约成本，集成测试人员和实施人员完全是可以兼任的），不需要修改任何配置，带着war包就能去部署了，尤其是异地部署这样做更是方便。

看了上面的回复。

有朋友提出了，配置应该是全局性的，不能随意修改。你在测试的时候由于支持热部署所以你使用注解还是配置都一样的。而在生产环境只修改一个配置文件就搞定一切是不可能的。所以可以注解还是可以代替配置的。

这种说法是很奇怪的。注意我上面强调过，注解是硬编码，注解是代码 没有任何修改是能在生产环境下完成的。那么总要在开发环境中完成，总要编译源代码的。完全可以使用硬编码啊。问题是硬编码不但带来编译的问题，更重要的它是一种重复。考虑一下web层的那些注解。如果有一天我们的目录结构变化了，我们的模板要引入换肤功能，所以需要调整。那么你就要挨个的修改所有的controller的java代码。假如引用配置文件，那么这些修改就是集中修改的了。当然这种修改概率是很小的，我只是想说明的是，注解带来的是硬编码，硬编码不但带来了需要编译，更带来了重复，还有代码可读性的下降。必须避免硬编码。再次强调：注解是硬编码，注解是代码

 

还有一个是有人认为建筑行业比软件业更发达，其实不然。有朋友总喜欢拿电子行业和建筑行业和软件业打比喻。以证明所谓的模块化，封装的必要。我首先声明，本人是个电子爱好者，业余时间喜欢自己设计电子玩具玩。而且以前是个农民工，在工地上打过工。所以这两个行业多少我是知道点的。

 

首先是建筑业，这个行业所能复制的只有设计而已。如果做一个的楼房那么是比较简单的，10个左右的工人就能建好。根本不需要设计，因为如何做都在这些工人脑海中已经形成了。最后的结果可能不太满意，但是总体而言是建好了。而且是比较坚固的，这里面并没有什么力学，什么土质，什么图纸之类的讲究。如果是一个高楼大厦，这个是要分工的。每个工种负责一点事情，每个小组有组长。他们非常清楚自己要什么事情。就现在而言都是框架的钢结构的。搭好架子，灌上水泥。然后就可以开工了。这个行业如果想降低成本，第一工人多做一点，第二就是质量牺牲一点。通常都是后者。

 

电子业看似比较简单，因为有很多芯片可以拿来用。可是这些板子是不可能拿来就用的，这些是需要成本的，你不可能做到这个板子坏掉了，直接换掉另一个不同品牌的板子。你在使用这些芯片的时候必须了解这些芯片的性能，而且要根据电路来判断选择那一种的芯片和零件。

 

所以想复用就不要封装，看封装不是封装才能达到复用。

只有朋友能制造出自动生成想要软件的工具，我对此会坚持——打死也不信。

1.使用注解的大前提就是减少重复，否则是不会用的。
例：比如默认的约定的声明式事务策略一般都是用配置文件来配的，不会用注解。实际使用时往往是默认的约定的声明式事务策略加少部分自定义的注解事务，自定义往往是需要特殊的事务隔离机制或传播机制。
注解一定带来重复，这条逻辑上根本是不成立的。更多的情况是，利用注解的特性能减少重复，xml中的各种和业务无关的标签和规范就是某种意义上的重复，而且还影响可读性。

2.接着上面的可读性来讲，以Hibernate的注解为例，可读性一定是注解优于配置的，看一个Java文件的速度一定是比.java + .hbm.xml要方便的，所以“xml配置可读性一定优于注解”也是不成立的，而且大部分情况下，xml可读性反而不如注解，这里的可读性包括IDE能提供的间接的可读性，比如我要借助IDE找到所有的引用此注解“@AccessType”的类。

3.请首先了解历史上为什么会出现“硬编码不好，配置优于代码”的起因，以前这样的论调是要解决什么问题。现在时代变了，有很多种方法来解决部署时的问题，降低各种人员成本和版本控制的成本。

我前面也说了，首先设计上就要区分开部署型的配置参数，然后利用ant全自动的修改部署型参数，剩下的参数就不要幻想会有临时修改配置的可能，如果你们公司真出现了这样的场景，我认为你们对生产环境的发版做的不够规范，很容导致浪费成本的情况出现。整个软件工程，成本最高的部分往往是修改、测试、部署、维护，而不是开发。

我也在造重复的轮子……但觉得这个轮子值得……

这两天看了一些这样的框架东东，个人能搞出来都是花了极大的精力哦，赞一个！！！
我做了两年的ERP研发，公司以前是在delphi的模板下开发的，的确对我们研发效率有很大的帮助，后来公司在.Net下也搞了一个类似的模板用起来就不是那么爽了哦，呵呵
个人也参与了一部分功能的开发，说真的对那个东东没用很多的信心，后话就不说了！
个人这里只是想从商用和业务角度对于这个东东的理解：
    这类开发框架想要商用，可扩展性应该是最为重要的，公司想要使用也许对于其自身的整个研发流程都要有较大的改动，用了你的东东，软件公司是不会把你也请去做后期功能扩展的，所以大多数公司宁可自己搞一套，也不会采用个人开发的，更何况存在对个人技术和个人软件极大的不信任因素
    从业务角度来说，简易框架实现增，删，改，简单查询操作应该是没用问题的，但真的企业业务当中这样简单的功能其实是不多的，常规开发这样的功能也花不了多少时间。而对于复杂的业务功能个人认为这样的框架是很难实现的。
    个人感觉，这类东东要做到尽量“远离”业务，抽象出一些功能性的东东，应该更会好卖些哦，呵呵！！！

关于快速开发框架或平台永无休止的争论只是因为大家都没有用心去做
不用否定，也不用夸张的下结论
我们也做快速开发平台，2001年起步，一直在做，通过平台开发的项目也近百个，没发现有这么多杞人忧天的问题，总结一句，许多下结论说平台做不到或效率低下的问题，其实都不是问题，只是因为你的所谓的平台不够好，你没有投入大量精力和成本进去。

http://www.extraction.com.cn:8855 这是个用平台开发的产品范例，没有一行java代码，开发工程师以前进行PB开发，不属性Web开发

javaeye上总能看到许多对快速开发产品的讨论，感觉很多人对这块很关注，也在探索。但大多都是持否定态度，其实对于软件平台产品目前主要存在3种类型，一种是业务平台，以特定行业业务为核心，和开发关系不大，另外两种是开发性的平台，一种关注代码生成，一种关注逻辑复用。

我们一直在做逻辑复用类型的开发平台，感觉虽然平台开发复杂、涉及面广，但如果有好的支撑体系，还是可以开发出较好效率、较广应用面的平台产品。

快速开发平台并不是万用的平台，也不能一劳永逸的解决所有问题，但再面对一个项目或产品时，有平台在手上可以大体忽略开发问题，而把重心放在更为核心的需求调研和系统设计上。

对于快速开发平台，建议不要过于菲薄，视为仇敌，快速开发平台能够降低成本，提升开发效率，这时毋庸置疑的，而且从长远看，平台化的软件开发也是大趋势，象硬件系统一样的模块化组装也是整个行业的追求。

科诺已经倒了，普元还能坚持多久？ 底层框架，OpenSource是王道！