现在很多软件公司都在开发‘零代码企业应用开发平台’对我们程序员有什么影响，大家都怎么看？ ( 积分: 100 )

将0代码平台等同于高级语言，未免太抬举了它吧，难道0代码平台可以像高级语言一样，
能编译机器码出来吗？0代码平台等同于高级语言编写的一个玩具，好玩就已经差不多了。

高级语言是一个零机器码的平台，而零代码平台则是一个零高级语言的平台。实现前者的
是拥有语言转换魔力的编译器，实现后者的是拥有抽象到具体转换魔力的智能引擎。使用高
级语言的开发者能够体会到高级语言编译器开发者所倾注的智慧，零代码平台也是一样。
估计多数人到现在为止，见过的只不过是玩具，所以认为这个世界上除了玩具之外别无它
物。想必大家也知道论坛里前一阵有个家伙自称用了20天整出来了一个可配置的系统——那
种破烂我04年花了个把月也搞定了，容易的很。但是，一直修练到今年，我才真正跨进零代
码的大门。

多说无益，得加紧努力了

做工具当然不是为了好玩,而是为了提高生产力,相信平台的发展会越来越好.
转一个帖子:
-------------------------------------
在如今的软件行业，向平台进军已经是每个软件开发商宣传的口号，基本上每一家开发商都号称自己拥有软件开发平台，平台概念就和炒ERP一样被炒烂了。更离奇的是对平台的自我评价(或许该称为吹嘘)都非常类似，总结一些宣传的比较“好”的归纳如下：
1、快速开发：开发速度比手工写代码提高xx倍，应用系统开发只需要xx%的代码量或者可以零代码开发；
2、面向构件，工厂模式：开发软件可以像汽车组装流水线一样方便和快捷；
3、扩展性：灵活的业务配置和扩展能力；
4、低成本，易于维护；
5、平台的设计能力：平台可以根据用户的需求，很灵活的设计出符合用户要求的系统。
6、商业智能(BI)、划时代意义、ERP的第三次浪潮（ERP都没搞清楚），诸如此类的陈词滥调。

这些宣传真的是非常到位，就此而言，如果平台产品真的实现了这些目标，我感觉真的是企业之福了，可是实际情况是怎样呢？下面先了解一下现有平台的分类，根据现有的平台厂商调查，大致分为如下四类：
1、 [恶搞类]平台：这类平台大部分是在word,excel里面写了几个宏文件，连系统都谈不上，愣说自己是平台，不说也罢。
2、 [设置类]平台：此类平台以应用为基础，设置一些开关变量，以适应不用的情况和场合，可以说让应用的灵活性有一定提高。可是再灵活也只能称为应用，而且扩展性非常差。
3、 [应用转行类]平台：这是比较成功的一类，暂且称只为平台，以行业应用为基础，封装了行业(或典型企业)的诸多相对通用的业务逻辑，而且业务逻辑是对某个行业经过深刻研究后才能得到的结果。可是只能在行业内部应用，增加业务逻辑模块仍然需要编写代码，如果开发新的行业的应用，等于从零做起。
4、 [协同类]平台：这是比较成功而且是见的最多的一种平台(具有应用转行平台的所有优点和缺点，但是其局限性要小的多)，以OA或者ERP为基础，以工作流为核心。

纵观这些平台，再看平台的宣传，平台解决了什么问题？其实这些宣传正是他们没有解决的问题。那么问题出在哪里？其实最重要的还是平台软件厂商的没有认识清楚平台的概念，还没有从应用的开发当中解放出来，不忍丢下现有的行业应用。那么这就导致了这些平台产品的局限性，同时制约了本身的技术进步和思想进步，最终将会沦为与传统行业应用软件开发商相同的层次，到时候只能宣告：向平台进军失败。或者说这些行业软件商不具备开发平台的条件。
在此插一句：为什么国内ERP的实施失败的案例很多？做了几年的ERP的软件开发商都不知道何为ERP，开发商自己都不用还要高价卖给客户，这能成功才怪。ERP是改变工作方式、合理利用资源，而大部分开发商和企业只是将其认为是软件，是数据库应用，暂且不评论ERP软件的质量。或许是开发商的售前鼓吹、或许是企业对ERP期望太高，ERP的实施费用是相当昂贵的，少则10万20万，多则几千万。企业花了高价来实施ERP产品，却收效甚微，甚至出现影响现有工作的情况，大多是因为企业管理人员对ERP的错误认识或者ERP软件本身就不能满足现有需求。软件满足不了需求最好、有BUG更好，我们提供升级，提供服务啊。现在都在卖服务不是，好像有了服务就是好软件了，那么修改BUG也要用户来买单，还美其名曰是服务，我倒！开发商钱赚到手了？那么ERP的疗效去了哪里？深思吧

言规正传，平台软件到底能不能满足企业信息化建设的需求？回答是肯定的，但不是上述几类平台能解决的。一个能满足企业信息化建设的平台应该是什么样子？其实就是实现上述平台所宣传的目标，那么这个目标如何实现，关键还是定位问题。还得用一下生产汽车的例子：其实组装汽车并不复杂，因为我们是用制造好的零部件组装，所以显得很容易。软件也是如此，因为平台里面集成了了很多业务逻辑和功能模块，所以平台都号称零代码或者面向构件，因为他们忽略了最重要的环节，也就是这些业务逻辑和功能模块的的开发，这才是问题的关键，也是为什么平台没有实现所宣传的目标的原因。软件开发与组装汽车不同，因为汽车零部件都有相应的标准，而且都是批量生产，具有模式化；软件则不同，没有办法来统一，需求千变万化，如果拿做车的路子来套软件生产，无疑是死路一条。
如何改善这个问题？有人说SOA，可以灵活的实现业务基础架构，这里不再多说SOA,从它一开始到现在所走的路，自己是死是活都不一定，可以去CSDN搜索相关文章自己感受一下。

那么现在需要什么样的平台？我认为是汽车制造零部件的工厂，也就是快速构建功能模块的平台。这样的平台与行业应用没有直接关系，只是能快速根据图纸生产零件，当然能组装成产品更好。这必须要遵循三个原则：
1、 在编程语言上层实现。
写代码虽然灵活，可随心所欲，毕竟效率很低，修改起来也困难。可是不写代码可能灵活性尽失，又要走前面一些平台的老路。其实程序员都知道，写代码也无非那几招，数据输入（数据采集，合法性验证） 、逻辑处理（条件判断、循环遍历、递规调用）、执行处理（数据运算、数据库操作）、显示处理（界面显示、报表），很符合MVC思想。如果这些处理都不再需要编码，那么会节省大量的时间。
2、 与行业应用无关。
因为我们是要做平台，是将需求转换为思维再转换为应用系统。当然这个平台不能说只能做进销存，或者只能做OA。它应该能更灵活的做信息化应用。
3、 能快速将思维图纸转换为业务模型。
思维来源于需求，对于有行业经验的业务人员，根据需求产生思维意识的解决方案是很容易的事，但是实践到产品开发上面还要经过大量的时间，概要设计，详细设计，模块划分等等。那么如果平台可以给业务人员一个展示才华的机会，可以让他用我们的平台来实现他的思维，那么这个环节将省去大量的劳动力和宝贵的时间。

当然，平台的稳定性、安全性、可部署性、是否可以在满足互联网环境等等问题，都要平台设计当中考虑，这不是本文的范围，不加详细说明。

>>原始社会中，人们很多时候都生活在野兽和自然
灾害的恐怖之下，吃不饱，穿不暖，平均寿命不到40岁——难道你想回去？
这是教科书的标准答案可古书上不是这样写的，那时的民风淳朴，帝王有德，
人反而活得长。不要用教科书上的描绘的图景来想象上古年代。
现在的人又何时征服自然，南亚海啸一来，一下收走三十万，我国近年来自然灾害不断。
再加上人为的车祸每年稳定在多少万。未来几年更是气候条件恶化。什么温室，尼诺。
都来了。就是科技最发达的美国，龙卷风一来，一个二个还不是被撵得鸡飞狗跳。
人在宇宙中太渺小了，科技再怎发展，在漫长的宇宙历史中和没发展差不多，况且科技文明
也不是我们这一回，我们一回是最差的。

若能这样做SAP就不会这么贵了! 这些公司在烧钱, 没有结果的! 若是做一个电子商务平台还是可以的, 不过也不一定能适用所有公司的需求, 其实从现在的ERP系统的使用状况来看可见一斑, 金蝶,用友都在说他的能适用大多数的公司, 但实际上在我接触过用以上系统的公司没有一家是满意的, 而SAP系统也不大部分公司也没有用得很好, 更只说是这个什么零代码的软件系统, 若是能做微软与IBM,或甲骨文公司早便做了, 这些公司是套了一些钱做一些所谓的概念的东西, 用来应付股东的. 试想实现手法, 应用的行业,当然是写一个行业而且业务流程一样这样是可以的!

恩,说的也很有道理,现在宣传'概念'的确实比较多,不过,做的成功的确实也很不错,继续努力.

to 我爱PASCAL:
请您不要再“发挥”了，发言无益，不如不发。如果您觉得这个世界太糟糕了，完全可以
自己重新投胎去。

呵呵，若是他真的投胎去了，老兄你也没啥好处啊，莫非研读佛经的人就喜欢超度人？嘿嘿。。。
发言无益，不如不发。

现在人才市场会写代码的人多如牛蚤。

我没有对世界不满，而是就当今科技的生产效率提高并未使人更轻松而作的一翻论述。
古人除了农忙，有大量的时间休息，而现代人，每天工作八小时以上。
不妨打个赌，2013年后，你的电脑还能正常启动你来找我。

生产效率提高跟不上人的欲望，我和朋友合伙买彩票，买了就开始做梦，如果中
了500万改怎么使用，我的朋友说买辆车，而我呢，就买一个小房，里面就放一张
床，一个简单的洗手间，然后联系一个餐厅每天送外卖，之后365日24小时就是
睡觉-吃饭-睡觉-上厕所-吃饭-睡觉循环下去，过这种人类最基本，最原始的吃拉
睡模式，其他都不管了，什么手机，电视统统都不要，车更加没有用，衣裤也不穿
了，省得洗，还要什么科技。

>>生产效率提高跟不上人的欲望
看来我们的看法差不多。
做为老板，可以考虑怎么提高效率，作为员工，提高了你还是不敢提前下班，说不定效率高了，全自动，你也用不上了，找个安装维护的就行了。到头来为他人作嫁衣裳。

我都做个计件工，本来一天可以做9箱药丸，但是整个车间的人故意拖慢只做7箱，
为什么不做9箱多赚点钱，因为怕将9箱做出来，厂里面就规定每天做9箱，给7箱
一样的钱。

creation-zy, 呵呵, 我说"可能"完全是一种友情提醒.
本人也曾一度疯狂迷恋"平台"概念, 也曾部分实现过.
这个东西有个定位, 比如说可以作为一种可配置系统, 或者代替"高级语言"作为主要的描述工具.
对于前者我比较看好, 那是因为他目标较小, 我就称之为"局部战争"吧.
作为后者, 我觉得前途渺茫, 首先是理论上的, 其次才是实践性的.
国内的大部分人喜欢干什么一下子就从技术上开始干起来, 对于理论上的本原考虑的过少, 就妄图做出革命性的东西来.
再过几年, 我们再来讨论这个东西吧......

大家讨论的平台，我感觉不应该是一个概念，而是一个实实在在的发展趋势，
就是代码多少的问题，生产力的高低问题，适应性的范围问题。不要把不同的平太放在同一个应用范围来比较：汇编等够做的， Delphi 不一定做的了，但delphi能够做的，汇编一定能够做，但我们一般选择delphi做，这是生产力的问题。
作为应用软件来说，抽取共性，在delphi等的基础上重新封装应用构件（粒度的把握很重要），我相信，平台的实现应该不是那么复杂的，这是个思路的问题。

dreamfly兄，您如果看过我的AI帖子，就不会认为我只是一个“技术狂人”了——一切技
巧在AI的天宇之下，不过是一片淡云罢了。我现在使用的高层理念中有几个我还没有看到业
界有什么有效而简练的描述机制。我们的平台不是“技术”的堆积，更加不是工作量、代码
行的堆积，而是超越面向对象的更高层理念的有效组织与协作。
《华严经》中提到了对世界的一种分类方式——理法界、事法界、理事无碍法界、事事无
碍法界。最后一个法界是禅的境界，一切语言、思维所不能及，我们的目标是让平台修炼到
第三个法界层次。[]
楼主提到了粒度、复杂性的问题。其实——“一沙一世界”——任何一个看似简单的小组
件中，都包含了与大组件完全相似的结构和机制。做为平台的提供者，我们是不是需要关心
粒度到底应该大还是应该小呢？[]

虽然东西，可能不错，但我还是不太敢用这类产品，我们的业务平台基于你们的开发平台，如果开发平台本身有些BUG，而我又没有源码，一边客户催，一边我还得求爷爷，告奶奶的请你们修正好，而且我们软件的业务功能，基本上也局限在你们的平台水平上了，想修改与维护都是一件不容易的事，所以平台自已做，业务系统自已开发，才是我要选的正路。

关于源代码——请问大家有Windows的源代码么？有IE、Office的源代码么？Linux、Open
Office是开源的，为什么大家没几个人用呢？[]
您可以说用平台的人局限于平台，我也可以说用高级语言的人局限于编译器。如果我的平
台灵活性比特定语言的编译器还差——这种破烂平台我不开发也罢！

不知道什么时候能够见到兄弟的大作呢？还得多长时间？

呵呵，如果我着急推出的话，2005年就能出来吹了。当我经过两年多的禅思、在理论上有
了突破后，平台才得以拓展出一个前人从未涉足的全新的方向。我们的抽象程度和灵活程度
是业界任何产品和书本都未曾达到的——我们现在已经完全统一了上面提到的“理法界”和
“事法界”，正在向“理事无碍法界”进军。不过，理论的完备并不代表工程上的完备，我
们的目标是做一个在理论上绝对先进、同时工程上极为实用的系统，所以还要做很多工作。
我们目前正在世界的一隅有条不紊的工作，在实践中不断的进化——我们已经潜伏了两年
多的时间，为自己确定方向、进行理论上的提升和创新。前一阵我们团队完成了对自己平台
的精确的市场定位，现在是时候进入Beta阶段了。[]