说明：
想起做这个 精华之精华 主要是有些贴子实在是太好了，看着那些闪烁着光辉的字句,让我忍不住再花点时间抽取一次，让那些好贴能永久的供大家揣摩，品位！当然，这只是个人行为，没有收录到的希望大家不要介意！毕竟，我们的共同目的是有所提高，而不是其他
. 若转贴，不要对本文有任何删改，谢谢！
完整资料请访问系统件开发专题网站: http://systemer.51.net
系统件开发模式讨论精华存放在：http://systemer.51.net/SYSTEMER.HTM
原始讨论站点URL：
http://www.csdn.net/expert/topic/824/824008.xml?temp=.41383
http://umlchina.smiling.com/group/posts/view_forum.ecgi?group_id=9986&res_message_id=1133663
主题：系统件开发模式（Systemer）
作 者： freekany
系统模版，是一类已经做好的成熟的特殊的系统，说它特殊，是因为这类系统模版并不具有任何具体的数据特性，不具有任何个性化的信息，但具有固定的系统结构和界面布局。当我们使用这些系统模版来作系统实现的时候，我们只需要赋予它具体的属性值，比如说具体的数据库信息，具体的显示信息等。更直观一点，其实一个系统模版就和一个类，一个组件，控件差不多，，只是它是系统级别的，已经上升到了系统的高度。因此，我给它起了个名字：系统件（Systemer).以后我们就用系统件来描述吧！
有了这样一个基于系统件的系统，以后我们做完需求分析后，我们就可以直接利用这些系统件来实现我们的系统了。不需要去想任何代码上的实现。或许，我们那些只懂点粗浅知识的程序员要下岗了，包括我，虽然这有点痛心，但社会在进步，程序员也该换个活法了！
我知道这样一个想法是比较令人吃惊的，从某种规律来说，如果不考虑底层的代码实现问题，上面的分析和设计就不太可靠，所以要做一个好的系统需求分析和设计，似乎需要有长期的代码经验！如果没有代码经验，就去设计一个系统似乎不太说的过去！
因此我深感惶恐，这样一个基于系统件开发模式的系统能占的住脚吗？可能吗？
思索了很久，我发现其实这样一种开发模式并不违背上述规律，从分工合作的角度来说，这种开发模式其实系统件已经完全封装了所有的底层代码的实现工作，而大部分设计工作也封装在系统件里了。而需求分析其实是一个系统具体化的过程，这一点任何时候都不能避开，在使用系统件开发模式开发的时候，系统件变为系统的过程正是需求分析结果的体现！
简单说来，系统件开发模式只是把以前的一长串的开发过程变成了简单的需求分析-实现的过程，而这个实现，以前是每一个系统有一个具体的实现，现在则简化到了简单的系统件来实现！以前一个系统可能需要很多人来一起协作完成，这其中包括了很多的编码者，现在，可能根本不需要这些编码者了！
这样一简化，时间和物力都大大简化，而系统则具有一样强大的功能，甚至更强大！
这个“甚至”是有一点深度的，因为我发现现在许多做企业软件的公司实际上做的产品的绝大部分功能都差不多，但因为利益关系和狭隘的商业思维，每个公司的产品都是保密的，所以虽然是同样的产品，每个公司都是招上一帮人从头做起，又因为时间短促等因素，所以做出来的产品虽然都具有相同的功能，却都不成熟，千姿百态，甚少精品。
这从软件工程的角度来说，就是重用性问题在企业的最好体现！
说到这里，我想你大致知道了这个“甚至”所包含的意义，以系统件模式来开发，重复利用的机会就大了很多，因此经受的考验就更多，自然，系统就会更强大，更有耐力！
一般性的规律并未违反，因为基于系统件的开发模式也是遵循经验积累规则的，它只是把以前相似的大量的散沙聚集起来，提炼为一颗颗晶莹剔透的钻石，并且使得分工更精致，合理。
现在可以这样解释：以前的先有代码的经验积累，然后才可能去进行系统的需求分析设计的思维模式只是一种纵向的思维模式，系统件开发模式则纵横结合，并从分工合作的角度来重新定义了软件的开发过程！
>回复人： freekany2002() ( )
█>>>软件发展过程是一小撮高手写给一大群低手使用的过程
--------------------------------------------------------------------------------
申明一句：下面的的话可能有一点过激，但决不带有任何贬义，希望大家客观的来理解！
我知道这样一个话题就现在来说，必然是反对多于赞同的，但是我仍然觉得这个想法的确是可行的！
让程序员下岗，可能大家误会我的立场了，要做这个系统，必然还需要许多高水平的程序员，因为系统件的开发的确是有一些难度的！但现在我们的很多初级程序员仍然还在底层代码上不知疲倦的钻研着，我觉得实在没有必要，因为他们花了十倍的精力做出来的东西，其实给高水平程序员可能一倍的精力就做出来了。而因为现存的商业因素，这些高水平的程序员却往往只能为某一家企业服务，从他们所得到的回报来看，似乎这正好顺应了多劳多得的规则，而这正是每一个有着正义感的人所追求的！但其实从另外一个角度来看，如果这些高水平的程序员所做的东西不只是为一家企业服务，而是释放出来给千千万万家企业所用，那价值就不可估量了！这其实是资源的一种重组，而这样一重组后，是的，是使我们的软件产业进步了——这句话虽然有点大了，但是事实！进步不可避免的会让某些环节发生重大改变——这里最直接的，当然是让许多编码者下岗了！但我们为何不从另外一个角度来想想呢。如果变革发生在了我身上，如果我是一个敢于接受一切有意义的变革的人，那就勇敢的去接受它，然后寻找另外的突破口。程序员下岗了，那就把你的聪明的大脑用在分析和设计上啊，当然，如果你还很喜欢写代码，那就去改进我们的系统件啊，更突出一点，你可以想想更好的软件开发的方法啊！
其实，我现在希望做的和当时微软和BORLAND提出的组件，控件开发是一个道理，只是我把它上升到了系统这个高度！从这个角度来说，我想大家应该更明白一些！
有一句话是这样说的：以后的软件开发是这样的：软件发展过程是一小撮高手写给一大群低手使用的过程！我觉得这话不错！你看看现在不是微软和BORLAND的高手写给我们所有这些使用他们开发工具的低手用的吗？我们的所谓的开发高手们，和他们比起来，你们自己觉得自己有多高？
> 回复人： _i_(不懂装懂) ( )
to 搂主：
一看你开始的那些话，这么和我想做的系统一样。
两个月之前我想到差不多同样的东西，在我一片粗略的文档的某个段落的最后一句是：呵呵，我们不需要蓝领！
我是做delphi+sql server做三层式开发的（ERP），其实涉及到底层一点的东西很少，更重要的是企业逻辑——但也具有很大的相似性。不规范的开发流程使编码人员写出很多功能重复的接口，也生产了许多类似的错误。如果有一种代码构建器（应该完全可能），完全可以避免这些损失，甚至可以不需要编码人员，只要架构人员。
简单逻辑的代码构建器我们这边已经有人做出来了，但是复杂的逻辑，或者说客户端有特殊要求界面的我思考了好久，整合到一种统一化的模式有点难度，近来工作很忙，我没有继续深入下去。
其实也不一定要生成中间代码，完全可以生成最终应用程序。
如果这个程序能出来，它将是同一风格的（减少错误与重复的同时也灭了不同程序的个性），它是支持流水线的，它可以减少客户的学习时间。
说得有点语无伦次，不多说了，如
成功不一定是目的，在讨论中大家读可以提高。
> 回复人： cherami(cherami) ( )
大体上说我还是赞同楼主的观点的，但是和其它朋友说的那样：过于理想化！我们都有梦想，而且实际上我也很希望有这样的工具。
问题是：要实现这样的一个工具，需要很多的先决条件。
1、大量通用的代码架构并且有针对目标语言的不同版本
2、大量高水平的程序员，他们要对上述的代码有很深的了解并且对各种应用系统有很多经验
3、充足的资金进行先期的投资，要有一个真正可以使用的系统，没有几千万RMB是不可能的
4、完善的管理，这样大的项目，没有好的管理是不可能成功的。
实际上单单从以上的条件而言，这样的一个系统目前是不大可能实现的。对于一些老练的程序员而言，实际上他们自己是一个这样的系统的人工版本，之所以这样说是因为假设是他们做设计并实现，那么他们最初的分析行为就是楼主讲的需求分析及详细设计过程，这个过程完成后，他会从他积累的代码中选择很多作为模板进行修改，因为这些代码是经过严格测试证明没有问题的，这比从头写高效得多，他需要修改的只是部分和需要完成的系统相关的部分。因此这个程序员实际上就是楼主所言的系统的一个化身，至少是非常的类似。需要指出的是要做出一个这样的系统从一定意义上而言就是模仿这个程序员的思维和操作过程，而我们知道，现有的系统还不能达到这样的水平，如果人工智能技术非常的完善的话，那么这样的系统的实现不是很难。
一点妄言，见笑。
> 回复人： hax(海曦) ( )
我的看法如下：
楼主的想法许多人都有过类似的。包括我。只是我的应用目标并不是所有的程序和软件，那样基本上是不可能的。我觉得你应该县针对某种特定应用来积累经验。我现在要做的就是web site的整体开发平台。
其实，从过去的技术发展上看，web技术一向比其他编程技术更加接近非程序员。html是一种说明性的语言，基本上智商正常的人都能够掌握。而java script则是一种脚本语言，其设计目标就是给非专业程序员使用。当然现在的脚本语言还是蛮复杂的，不过比c、java要简单，而且开发者的主要精力是在功能的实现上而不是程序的效率上。
再看比较复杂的服务器端，java的例子最好了。从servlet到jsp到标签库，越来越“简单”。实际上与许多人的误解相反，jsp也不是给专业程序员用的。专业程序员应该做的是servlet、标签库的实现等等。
现在国内的小公司给各个企业做得管理软件大同小异，没错，这就跟website的开发是很类似的，所以如果从这块出发，有了底层的一些东西，上层的效率就很高。比如jsp终于有了标准标签库（我在许多文章里推荐的），它可以提高效率很多。而且作为标签它基本上跟html一样，非专业人士也可以轻易掌握。
再有一个例子是zope，加上三层分离的概念之后，我们可以把web site分成外观、逻辑和数据层。
其中外观是设计人员的工作，虽然以前一度html、java script的过度膨胀以及与数据层和逻辑层的混合导致混乱，但是现在许多开发模式已经把三层分离，并且随着xhtml的发展，混乱状况会得到改善。
数据层现在普遍用xml。
逻辑层通常是程序员做的，也是程序的核心。我们要简化的就是这个部分。
比如用Zope，它有自己的dtml来做表现层，而且有现成管理框架可以直接处理一般的数据层。逻辑层则用python脚本来写。但一般很少需要用到python脚本，因为除了zope本身的管理功能之外，还有许多现成的products可以安装，例如通用的内容管理系统之类。
最后，我觉得楼主需要再考虑一下你的系统件究竟比较接近中间件还是类似zope的product。
还有，对于我来说，我发现rdf是很好的东西，因为xml虽然好，但是没有语义，这也是智能化程序的障碍，rdf是提供语义的。我觉得rdf对于楼主肯定会有启发，建议你去看看。www.w3.org/rdf。
>回复人： chao_jian(升级中...)
To freekany2002() :非常欣赏你的大胆想法，记得有个说法大概是说程序员的一大优良品质就是善于偷懒。
不过这真是一个“梦”想，很抱歉，我不得不说说我的看法：
或许在十多年或更早以前有些程序员（我不知道当时人们是如何称呼他们）听说了组件概念后，立即也会有你相同的想法，因为一个简单的组件用汇编可能要几天或几个月才能实现（或者说在当时能输入字符的东西就可以叫“软件”了），但今天我们很幸运，几分钟就可能做到。的确，当年的程序员现在几乎是消失了，但不幸的是我们这些使用组件的人又被称为程序员了，“系统件”（尊重你的定义）出来之后，那么使用“系统件”来实现程序的人难道就不能叫程序员了吗？即使设计是同一人，不过我想这种情况很少，就象今天很多系统分析员使用看起来简单的组件并不顺手一样，何况“系统件”可能比现在这些组件要复杂很多倍。
说到此，我想关键是，在断定程序员是否因为某种技术出现而消失时，首先应该界定程序员是什麽？
最后，我觉得作者的技术方向应该代表了未来某种趋势，但这跟程序员是否下岗并无必然联系，或许在某一行业的程序员的确会减少，但并不是普遍现象。
我们必须承认软件之间的差异，既然存在差异，这种想法（代替程序员）便无意义。
>回复人： softworm(老头) ( )
大家这么有见识，也没有必要在他一个人身上体现出来吧。
为了什么呢？为了楼主，使他避免失败的痛苦？或是为了自己，
说明自己对现今的软件技术了解有多深？
如果你行，请不要说别人差，更不要说别人的想法不可能。
当初刚刚开始普及电脑的时候，大家都说中文要死了，但朱
邦复先生就不信邪，为之奋斗了半生。现在谁还说中文要死了？
> 回复人： zmzy(zmzy) ( )
1 工作量的软件可以搞自由软件，比如linux,因为有很多其他系统可以参照，而思想性或者说创造性的软件只能搞商业开发，否则会陷入无止境的争论。
2 资金最重要
3 看了你的设计，觉得还是太模糊，还有很长的路要走。
> 回复人： white(white)
非常有意义的想法!
我也曾经有另外一种想法,设计一种第六代编程语言.
我们知道,我们现在用的大部分程序设计语言都属于第四代,SAP中的商业应用语言属于第五代.
程序设计语言越往后,离机器越远,离人越近.随着CPU的升级(它每18个月就会升级,所以不用担心),效率不成问题.
我们用的第四代语言,如VC,VB,DELPHI等,已经不再需要关注机器码、寄存器等细节，但是仍然需要大量的书写代码，不过比汇编当然要少许多了。
第五代编程语言更多注重商业逻辑，只在少数系统中使用，如SAP的R3。
我所设想的第六代语言，基本不需要用文本来编写代码，而是用一个图形化的方式来设计程序流程，就像VISION中画流程图一样。但是用户界面这一块仍然需要设计，不过目前的VB、DELPHI等都已经做到图形化的设计了，因此不成问题。
另外需要一个解释引擎来执行这种程序，为了顺应技术的发展，它应该可以支持分布式的执行，就是说上一条“指令”（姑且叫指令）在这个服务器上执行，下一条指令可能在地球上另外一处的系统上执行。
目前的工作流引擎应该可以算是这种语言的一个原型实现，它已经具有图形化的流程设计工具和图形化的界面设计工具以及一个执行引擎。不过工作流引擎目前大都只支持少数的几种节点（即我们所设想的指令）。
第六代语言将把程序员极大地解放出来，更多地关注业务逻辑流程本身，而非技术上的细节（就像前几代语言一样）。
关于第六代语言，国际上目前有少数公司在从事这方面的研究，比如韩国的一家公司出了个ProcessQ的产品，声称是第六代语言，不过还不是很成熟，而且应用范围比较窄。
> 回复人： Kenky(Kenky)
当一个人说“不可能”的时候，他往往是错的。
所以，我不敢说，：）
楼顶说得对，这是一个“梦想”。人人都有做梦的权利，而且做梦还，很浪漫的。而且多数的现实都是从梦想实现而来，所以梦想总会有实现可能，注意，仅仅是可能。如果你想实现这个梦想，下面有几点我们探讨一下。
踏实的工作是最重要的。看得出，你对自己“那种对大框架，大方向的把握能力”的能力很自信。对，这点很重要，特别是在技术高层的人来说。也看得出，你也承认自己“静不下心来做点具体的东西”，说实话，这点很可怕，可以说是致命的。其实“对大框架，大方向的把握”和“静下心来做点具体的东西”并没有什么矛盾，请记住这一点。如果你要实现自己的梦想，即使你是把握大方向的，也有大量的具体工作要做。也许不是编码！在我看来你现在在你脑子里形成的框架还太模糊，确切点说是一种想法，不足以付诸实施，而你却开始建立软件模型了，虽然我没有看，但我清楚会什么结果。没有正确需求的工作，不止对软件开发，对所有的项目都是致命的大忌！好吧，我们暂且假定你的可行性、需求分析已经完成，那你还有很多很多很多具体的工作去做：做一个可以打动投资人的项目计划书（不要告诉我你这样庞大的项目不要投资），按照计划书征召具有掌握关键技术能力的技术人员、“高手”程序员、有经验的项目策划和管理人员，细分开发任务，分配投资资金......太多了。当然你可以说：我聘用别人来完成这些工作。对，没错，完全可以，但雇佣多少人，什么样的人，都做什么呢......建立一个完成既定功能团队有何尝容易。
扯远了，呵呵。说这些的意思是，即使把握大框架、把握大方向也需要大量具体、细致的工作，而不止是在脑子中的空想。
还有就是技术的准备。按照你的说法，运用现有编程工具的绝大部分的程序员都是“低手”，我暂且同意。那么你需要的是摆脱传统的诸如Borland、MircroSoft的束缚，形成自成体系的系统，不受制于人。很好，非常好，这是多少年来国人的梦想。这样需要什么呢，要彻底抛弃现在这些什么Delphi、VC、VB之类的东西吧，还好你还有开放UNIX，要不操作系统也得重新做......不对啊，是不是CPU也得重新设计，免得Intel等厂家哪天改了指令什么的......
好啦，语无伦次说了一些，总结陈词：梦想是很好的，只是要实现她要做的还很多，而你需要的正是“静下心来做点具体的东西”了，如果你真的想实现它。
> 回复人： netpit(网井)
这种思想懒惰的程序员和真正专家都会想到。
这种思想在许久以前国外就有研究，在八年之前国内也有很多的研究。
说白了，基于这种思想实现的基于构件的应用软件开发平台。
前些年组件开发技术不成熟，internet也没有广泛应用，所以上面的东西虽然有人开发出来了，但实用价值也不大。
现在是这种思想实现的时候了，基于j2ee/.net构建一套这样的系统其实并不难。
我认识几个大学毕业才二三年象你这样的小伙子，理论一套一套的，但实际做起事情来实际是痛苦--不仅仅是痛自己。我想这个年龄段可能也是梦想最大的时候，但往往眼高手低，所以从大处去想，从小处一点点做起，才是重要的。
做这样的系统，要求对系统架构把握的能力强，对现实世界的业务系统也要有充足的经验，这样才会有相应的规纳能力。如如何进行构件的层次划分，如何建立系统集成的框架，这些都需要对通用设计模式及思想有较深的理解及把握。
不过年轻是个本钱，希望能用到实处。
> 回复人： dulo123(没有尽头的夜晚)
－－－－－－－－－－－－－－－－－－
我的理解是
1) 你这个系统是用来自动生成代码的。
2) 你这个系统可能和visio等工具相接合，（或者是解释visio等文件），自动生成代码。
3) 你这个系统目的是为了提高开发的效率。
4) 你这个系统是满足一般的工程的需求。
5) 这个系统的界面，流程，比Delphi更加一般化，调节的属性也更少，但这在一个标准的工程，是可以接受的。就如delphi的按钮也可以接受一样（不包括第三方控件）
6) 系统的操作是：在需求，设计时就用该系统来描述，到完成时，只需要象delphi那样设置一下属性，连接等类似的东西就完工了。
而我的问题是：
1) 这个系统自动生成代码，那么代码的效率可能很慢？如何嵌入自动的代码使效率更快？
2) 这个系统仍然要和底层连接？ 比如调用dll等，仍然要嵌入自己的代码？
3) 一个很简单的编程问题，
A.B.C.D。。。等10人围成一个圈，从A开始顺时针数数，被3整除的从队列出局，剩下的是谁？
这个系统怎样描述该问题？（准确来说是怎样描述解决问题的方法），在该系统如何描述，如何生成代码？
这个问题是否自动生成代码？或者手动写代码以作嵌入？
如果要写delphi等伪代码，或者写此代码的描述，是否比写真代码更快？
4) 如果系统有代码冲突，怎样debug？
5）我觉得太抽象了。当初从汇编到c，相信许多人也是不相信，不甘心，不肯接受，他们的理由是（不能做底层工作，效率低下，代码偏大）； 从VC到delphi，又不甘心，理由是上面三条，还有就是（不稳定，不灵活）。。始终来说，系统件是一个很抽象的东西，可能成功，也可能失败，但不会象上面的变化那样飞跃
我希望你给出例子
描述－》代码，
其实我连需求分析、详细设计都不会啊！！
> 回复人： hit5075() ( )
不要总用老脑筋去想新问题，
其实这种想法可能实现，
而且程序员也不会失业，
都转去做“系统件”了
另外加一句：人如果没有了梦想，那跟咸鱼又有什么分别
> 回复人： tony1978(突击召唤师)
楼上的所有人，没看过软件工程的，稍微浏览一下。搂主相信是看过“设计模式(Design Patterns)”了，不知道理解得如何。
针对某一狭窄的应用来说，这是完全可行的，很多系统都证实了。虽然应用会有很多的限制，但是完全可以产生可用的程序。要应用于所有地方就太难了，这在设计模式一书中提了一句。你所要做的，是一个可以分析、拼装并且假定可以适应任何需求和环境的框架，这有一点不现实。即使能在数年内实现，恐怕也只能针对特定的一部分应用。即便如此，工程量也是超乎想象的。试问，你如何知道用户用来构建的系统，会有哪些独到的算法、逻辑和界面，你怎么保证实现他呢？
>回复人： bonmot(jerry)
还是回到软件的目的吧：
软件的目的是自动化，自动化是基于某个层面的复用实现的。
复用与通用化程度成反比，
汇编最通用，但最不复用
基于流程的语言最能复用，但只能是某一领域的，不能通用
世界是复杂的，但构成世界的基本单位是简单的。就像几何的原理是简单的，但具体某一证明是复杂的。我们可以在原理的基础上对某一类问题构建任意数量的定理，但我们不可能对任意问题都用有限的定理实现（实现不了的还要从原理或假设出发）。
同样，在软件世界亦复如此。
搂主如果希望既能通用，又能复用，违背了世界的基本原理，是不现实的。
但如果就某一领域，大家都可建立自己层面的复用构件。
> 回复人： pacman2000(pacman)
想法很不错，我想说的是看看这个例子，不知道我的理解对不对。
通过系统件开发，其实就是基于组件的开发方法，只不过组件的定义内容不同罢了。但是如果要做的好，目的是为了不需要开发细节代码（楼主是不是这个意思？），就是通用程序设计的方法（GP）。想想STL就是这样的一个例子，把许多算法和数据结构用通用的方法表示出来，大家用的时候不需要自己写了。当然做起来不容易，甚至需要C++语言本身修改来支持。可是至少说明这样做是可行的，而且也确实能起到简化开发的作用。是不是可以这么说，系统件是某个应用方面的STL。呵呵。
需要说明一点，一个好的设计人员如果不了解使用的工具的话，是做不出好的设计的。而且如果考虑到灵活性的话，必要的细节替换是必然的！这些细节都是基础。
>回复人： freekany2002() ( )
首先谢谢大家的热情参与：
没想到这个论题引来如此多的争论，其实大家所想到的已经超出我所想的很多了。众多问题，我无法一一回答，这里就两个问题和大家交流一下。
首先的一个问题是：系统以后的发展壮大，我是如何希望去实现的-FFDD的实现问题：
其实就我最初的想法，是希望能吸引现在的众多已经存在的成熟系统，鼓励他们把他们的系统转化成系统件，这样就可以实现系统的复用并不断优化，改进！这就是我所提出的系统-转系统件解决方案，这种方式能使得FFDD迅速壮大起来！但这其中牵扯到商业利益问题，很头疼！所以我又想到了能否效仿LINUX的发展模式，但这种方式估计发展比较缓慢！
另外一个问题是我想谈谈创新的问题
很多人反推假如有这样的系统后，程序员不是要饿死（当然，这是夸大语言，^_^)了吗？其实这种担心完全没有必要，我想告诉大家的一个观点是：只有创新，才能做时代的领跑者！如果你要做时代的领跑者，你必须随时做好要有创造性的东西出现，这一点我希望大家多多思考为何MIRCOSOFT和INTEL总是牵着我们的鼻子走。因为他们永远都有我们意料不到（或者说做不到）的东西出现，所以他们总是跑在我们前面！ 设想过个十年，大家可以开始考虑如何设计成熟的 WINDOWS 了（并且不是一件很难的事） ，但我要告诉你的是，微软那时已经是移动操作系统和3D操作系统的霸主了！所以，请不要想着做MS 式的WINDOWS了，如果你希望和微软较量一下，你现在可以考虑做3D操作系统（虚拟现实操作系统），那时你就有充分的力量了！
> 回复人： shornmao(死猫)
我运行过了楼主的demo版。
软件本身不是很稳定，不过这没有关系。
但是我的直觉是，该软件是基于wizard的，软件中所说的系统件其实就是wizard，从技术上是完全可行的。因为早在很久以前Foxpro和Access已经实现了类似的基础功能，这和该软件中的自带的基本系统件功能基本一致。
可是楼主的设想完全建立在目前大多数MIS产品的相似性上，而这一相似性本身就是一种不足之处，抽象一种有缺陷的设计，并试图将他作为一种标准模板，这样生产出来的产品一定是有缺陷的。
按照正确的思维模式，不同的企业有自己的业务模式和业务应用，按照不同的应用需求必须设计不同的业务逻辑，需要将很难复用的业务逻辑抽象为可复用模块的这种方法，我不认为是很严肃的开发态度。这也许是某些短视的商人的思路，我是决不会赞同的。
> 回复人： iwtfly(手心凉)
理智的，其实所有的小mis系统，能够开发pb,delphi,vc的团队不可能开发不出来，可能抽象的比我们还要好很多，但是他们为什么不在他们的基础上做一个定好的框架来卖？大家认为那些bill gates的以及类似人的商业脑袋们没有想过这点么?我不想被认为太幼稚，所以我宁可相信他是在考虑的!起码vfp里面访问数据库的模板也是有的，自动产生的程序框架也不是没见过，好像是只实现了很简单的功能，为什么呢？我认为这是很科学的一种选择！这样在保证程序快速正确建造的同时，也留下了灵感发挥的空间。其实每个人都有自己灵感的一方面。
总结起来就是：客观说我们就是二次开发者，给我们搭建舞台的人们跟我们之间有一种妥协的关系，他们做得多，我们工作量就少，他们做得少，我们做得多，分工不同。
> 回复人： SnHnBn(大可达)
看了一大堆回帖，大多都是扁楼主的。
不过我本人倒是很支持楼主的这种想法。自从我设计的第一个项目完成之后，在总结的时候，我也有了同样的想法。
不是不可能，而是非常有可能实现的，不是什么人工智能等高深的东西……除了界面是否好看，位置拜访是否合理。至少，在数据加工存储的时候完全可以由设计导出代码，前提是设计足够详细，以一种规范而严密的格式表现设计。当然只能局限于某一领域。如果要作出适用于多各个领域的设计表达，那么这个设计是无意义的，因为这样的设计就是编码。OO设计思想是比较容易推导成代码的设计，Rose和PlayCase都有从设计导出代码的功能。希望那些一上来就批判的人好好去看看Rose和PlayCase，看看UML。我在接触这些东西之前，就已经发现面向对象的设计几乎可以直接导成Class，可惜用户界面还有点问题。但是，如果以三层结构来建立系统架构，那么中间层和存储层的自动推导就是一个很了不起的进步。
> 回复人： ar7_top(黑白呸，男生女生呸)
很有可能实现
因为现在一个好的软件设计师应该可以将软件的设计
详细到每一个过程甚至是实现方法
而根据很多文章中所写的
同样的一个问题
所有的印度程序员写出来的代码都是一样的，这就说明一个问题
这些代码是可以通过一定的逻辑自动生成的
其实类似的东西 Dreamweaver 已经做出了榜样
使用 Dreamweaver UltraDev 作的 asp ，基本上是不用自己动手写代码的
所有的代码都是可以自动生成的
这个例子推而广之，就成了软件的相同模式了
不知道大家看法如何
> 回复人： nhgw(创新！)
我曾经做过一个系统，系统中包括许多元件，对于不同的应用系统只需要把各个元件像流程图一样组织起来就可以了，完全不需要编程。不过存在一些问题：
1、生成的系统功能都很相似。因为都是由相同的元件组成的。
2、局限性很大，只对特定业务有用。适合那些功能不同，但很相似的系统。
3、实际也是一种开发工具，只不过使用简单，功能单一。
这实际是代码重用的问题，我个人认为目前比较实际的想法有如下功能：
1、积累丰富的实现各种功能的代码。一个管理良好、产品众多的公司就可以做到。
2、积累的各段代码可以很长（完成某个特定功能），也可以很短（一个函数），也可以重复（可以把很长代码中的一部分组成另一段代码），也可以有界面。
3、开发一套系统，对积累的代码进行分门别类的管理。
4、人工定义一些系统生成逻辑，如对于某种功能，可以由几段代码按顺序组成，输入输出接口等。
5、需要生成新系统时，代码生成系统只需要根据新系统的功能，查找系统生成逻辑，生成代码即可。但是生成的系统只是半成品，不过还是节省了大量的开发时间的。
我的想法有些与微软开发MFC的想法类似，但是更具体，只针对某些系统，这样对这些系统的开发就会更简单。不像MFC什么都可以做。
> 回复人： ColdWolf(天边流星)
老大们，看的偶的头都晕了。
谁说这个不能实现
只是时间问题。
不要停留在代码层来讨论问题好不好。自动的代码生成又不是没有。现在的可视化开发工具就是一个缩影，当年在DOS年代，当有一天看到人家随便用向导生成了一个简单的窗体，惊讶的说不出话来，心里暗思，赶快用TC实现，不然我就要被淘汰了。。。若干年后，这些工具就不是什么VC，delphi。。。可能就是楼主说得的System Builder了。
对于该方案的反对，也许只是各位的一种内心的恐惧吧：如果这种东西出来了，我们这些coder还怎么吃饭啦。注意，我用的是我们，因为我也是一个coder。就好像当年从DOS转到WINDOWS开发一样，心里充满了对新事物的恐惧。现在，只要有点逻辑思维的人，有点语言基础，用VB,CBC...就可能利用向导作出一个可能是以前的DOS程序员要一年才能实现的东西（不要和我强调什么效率和资源利用，各位在开发普通商用软件的时候，也不会考虑64K的内存限制了吧），因为他们要做的，只是把各种控件摆到恰当的位置，这样看起来会舒服一点。同时在某个点击事件里面写几个简单的数据处理。一个媒体播放机就做出来了...也许在各位眼里看起来，它漏洞百出，随便改一下，就能使这个破东西用起来方便体贴。但是，我想强调的是：它毕竟被做出来了。对DOS时代的我们来说，这是一个多么了不起的事情啊！！！！
要做测试去了，我想我要说的，大家应该也会明白。
不过，我还是觉得代码员是不可能被任何程序取代的。因为任何软件都是人们制造出来，然后代替人做一些重复的事情，人就被解放出来去做其它的事情。就象DOS时代的，高手们会写一个完整的程序。因为没有人能代替他们。现在的高手们会去做组件，或者其它的。其它的人会利用这写现成的组件，通过一些简单的实现，就能完成一个很实用的程序了。这些人可能到最后都不知道到底是怎么实现的，只是知道自己的目的实现了。
以后，会有人实现了MIS Builder, ** Builder.然或楼主就在用这个东东做系统换money，然后各位就做这些东东卖给楼主换money 呵呵！！：）
也许我说得有些偏激，还请大家见谅。我就是这个性格，没办法 :(，虽然我知道这样不好。可是本性难移啊。
> 回复人： jiawh(魔东西)
我的几个爱好:
编程,科幻,微型小说
有科学依据的幻想是好的,而且只要是在科幻范围内,在将来就有可能实现
多年以前人们在科幻中梦想人类登上月球,人们实现了.
有幻想才会有发展,有进步.
大胆的幻想吧.让人们都来幻想吧.
我的意见,这个设想在一定的范围内可以实现,
但它不应该是一个产品或者一个工具
而应该是人们的工作模式和
在此工作模式下的使用的多种工具
> 回复人： Justing(山风)
不敢说全部看完，大部分还是看了。说句实话，头都大了！
我想楼上的不少弟兄可能误解了freekany2002()兄的意思，不论什么让程序员下岗之类原本是现时比喻的言论，就是纠缠在代码的具体实现也让人足够烦恼。当C++用模版实现代码复用，大家开始都觉得那难以接受；VC用宏而不是虚函数机制实现消息映射，背“一切为对象”之潮流而动，却赢得了效率和空间。我可以肯定地说：freekany2002()兄所追求的，就是软件开发未来发展的方向！所以，对于这个梦想，以及基于此的一切讨论(可能更重要)，我的个人评价是：Great!
前景是诱人的，实现起来当然也极其困难。在具体讨论实现之前，有一个至关重要的问题是：如何界定此工具与程序员（也就是用户吧）的接口，在多大的颗粒度上实现？实际就是如果这样的东西已经出来（当然是假设），我是程序员，我该做什么才能把我的需求转化为工具可以理解的格式然后自动生成我需要的代码？仅仅说什么分析设计太空泛了！首先有这样的标准（这是一个必须建立的标准，就像现在的Windows程序开发标准一样，最低是基于API的），我们才可能具体考虑它的实现。
最后向致力于这个问题的所有朋友们致敬！这是一个恢宏的思维，希望可以成长成挺拔的白杨！我将继续关注这些问题。
> 回复人： zhengxionghua()
我觉得一切并非不可实现
但实现的时候
可能跟现在的Delphi差不到哪里
只不过控件变了，控件的操作方式变了
但效率提高了！
努力吧，希望将来能用到这样的开发平台！
>回复人： fling_boy(男孩)
我曾听说过软件开发就像是在搭积木，由小的组合成大的。
从过去到现在发展的趋势是：我们最后做的积木越来越大，提供
给我们可用的现成的积木也越来越大，看看以前在DOS下开发程序
时，我们用的开发工具提供的函数库是多么少，但那时开发程序
的程序相对现在来说也是比较小的，现在的程序越来越大，如果
还有以前的开发工具我想花的时间肯定会非常长，可能就没必要
做了，所以现在提供的工具有了越来越多的功能强大，封装完整
的类库，组件等时间也就节省下来了。
但我在编程序的过程中感受到，积木越大做起来是快但少了灵活
性，积木越小虽灵活方便但耗费了大量的时间和精力；我不得不
在两者之间找最佳的结合点，有时为了赶时间而调用一个庞大的
组件实现一个小的功能，有时为求精悍而花一天的时间写一个小
的算法。
我自始至终都认为软件开发是需求分析，系统设计，代码编写，
程序测试几个阶段的组合，其实也是一个由大到小，逐一求得小
积木的方法；有时从某些人的角度上讲他不需要其中的个别步骤
，举个特殊的例子客户可以只要整个程序这一个模块，分析员要
的是系统的各个功能模块，但如果说要设计一些组件通过简单的
搭配来完成大的功能模块，我想不但现在就是以后也是不可实现
的，因为需求总是在不断变化的，而且需求复杂多样的，比如现
在的开发工具不断的更新，类库不断的加强和完善，开发模式不
断的变化，这些都是为了适应新程序的开发，而这些是需要有人
去开发的，同样应用程序也是一样甚至变化的更快更复杂，所以
我觉得软件开发的环节还是越细越好。
>回复人： lingate(lingate)
我想有一点大家都很明白，每个人为自己的项目开发的组件在其他人使用起来并不好用，如果控件较大，则修改不方便，且不易符合大多数人的需要，如果你写小的功能具体而微的控件，那么将来在使用的时候是要自己写代码组织起来。你所设想的系统构件和控件很像，我想也会有这些问题的。
回复人： cnjava()
1.越是集成的东西就越笨，因为它们不够灵活。
比如有人用汇编，用c写病毒，但却从来没有人用pb写病毒，虽然
用pb开发系统很快。
2.你越是要求功能强大的东西，你就在灵活性和灵感上失去越多的东西。
比如说你每一个系统都是用同一个模板做出来的，就好象你把每一幢
建筑都做成一个样，你说还会有当今世界上这么多有灵感的建筑吗？
在灵活性，灵感和创造性之间，你只能二选一。
3.我认为机器就是机器，人与机器是有着本质的不同的，机器智慧的本质
是计算，而人类智慧的本质是灵感和激情。如果有一天“机器”也有了
这些，那我们应该称呼他们为智慧生命！
>回复人： eyunfei(云飞)
to freekany2002
你的想法的确很大胆,不需要程序员?也许当你真正实现时,那应该是划时代的东东.如果你真想要去实现它,就应该去做点实际性的东西,那样才不至于让人说你是一个狂想者.如果能把你现在设计的这个"系统件"(就用你说的吧)现在所编出的源代码公布出来而且不断更新,那将更有说服力.想要让人加入你这个工程,那也必须要让人看到你的实力,当你拥有超强实力以及能有望实现时,那时自有人加入.所以,与其在这大发言论,浪费时间,倒不如先静下来,写上上万行代码,再让之公布,让有兴趣者加入进行整体改动,增进,视其反应,之后才是进行团队的组建工作.总之一句说,实际行动比言论更具有说服力.(即使在这过程中不一定成功,但这过程却必然会让你学会更多的东西,那才是最重要的.)
说出来也不怕大家笑话,我不是程序员,但就在前一个月我却有更加天真的想法,那就是"抗衡微软".呵,岂图通过组织一个程序员组织来实现此目的---中国程序员联盟. 各程序员实行分区制.(有点像以前的红联)当初成立不到两星期,成员就猛增至六七十位,其中也有不少高手级人物,有一个顶级域名,以及80G的空间.但成立后,我才发现其中众多不足之处,其实即是开始这样一个简单的组织形式也有很多令人意想不到的问题.以至现在.... 唉,不说了,实在是现在自己的水平有限.但从中让我学到了不少东西,这也许是我值得欣慰的事. 我希望你能成功,其实这个过程比的就是耐力,只要你有这份决心,保持这份心态,也许随着以后科技的发展,你的梦想有实现的可能也说不定,那时你可能就比他们先走了一步. 另外如果你真的想要弄一个专门的页面对你这些项目等的进探讨,我想我们现在的联盟也许还可以提供一个空间给你,(不过这需要经过联盟的一位成员同意.)当然,如果你有突出的表现,我们中有人会加入你这个规划也说不定.其实起初成立这个组织的目的,也就是进行软件的开发工作.
好了,我也不再多说了,如果你有兴趣,就发信给我吧!
>回复人： Jason_guo(梦想难成,努力能成!)
****************************************************************
****************************************************************
花了很多时间看完全部贴子.我来综合一下我认为重要的几点:
1.这个系统,理论上可行.
2.如果这个系统可行.那么,这么巨大的编程工作.该由谁来完成?我相信,如今
世界上,没有一个企业能做到这个工程!
3.如果有企业能做到这个工程,它的灵活性呢?灵活性高吗?如果你要实现如此
大的工程,那么,在使用你这个工程.相信作出来的项目,要说明的地方很多
(顺序,结构,排列),如果这样,那岂不是现在这些程序员改改名字,就可以继
续开发程序(因为你的系统庞大,所以操纵一定技术性很高.不是一般电脑
使用者可以操作)
4.如果你做到了这个系统..那你可以做到未来的需求么?
5.如果你做到了.那世界不是好,而是坏...
为什么这么说?你这样做,无疑扼杀了创新,而不是在创新...
因为创新是竞争而来的,如果你做到了,还要竞争吗?
到时,程序就没有创新了...
------------------------------------------------------------------
就是这几点,我相信你的梦想已经接近没有办法完成!(当然,是有"可能"的.).综合起来,我不是反对你的想法.而是说,你已经脱离实际..在技术里
迷失了方向了...
>回复人： wxt(D.K)
对于代码自动生成器（我想系统件就是这种东西吧），现在也不是没有。既然以前认为生产一部汽车只要1分钟是不可能的，而现在却是现实。所以我也相信让机器编码也是迟早的事。只是那时“程序员”的含义肯定和现在不一样，就像现在造汽车的人做的事和50年前做的事的区别一样。
但是，同样的道理，50年前做汽车，现在仍然再做汽车的，除了福特，世上还有几人呢？将现在做汽车设计的人放到50年前，会不会有工厂接收我想也会是个问题。因此，搂主，我为你生在这个时代感到悲哀！
如果不想像马克思一样穷困潦倒，就不要研究共产主义！虽然共产主义可能是最伟大的梦想。
这就是我想对搂主和所有像楼主一样对现在的开发环境不满的人说的。
>回复人： longbow74()
评论太多了，都一一看不过来了,随便说两句.
第一,应该允许你有这个梦想,虽然基本是不现实的,但梦想是梦想,可以不实际.
第二,象你这样有想法的人我见的多了,其实是什么,因为做不好开发,所以希望开发不存在,或者贬低开发,你可以想一想是不是,并不是说你这样不对,人之常情,但更客观一些看待事物就好了.
第三,把握大方向其实是很容易的事,我见过的人每个都能说一通,就好象一个迷宫,大方向是这个口进,那个口出(当然真正的把握大方向不是这么简单),真正的过程在于走,***现在统一软件开发过程是迭代和增量的***,部分的设计来源于上一次迭代的开发,这样的设计才是可行的,真正要做到一个好的系统设计,希望你能踏下心来,做软件是个苦活,可以追求懒惰但至少目前不能懒惰.
第四,其实我真正想说的是设计和开发的关系,现在国内的情况是设计和开发这两个职业好象是割裂开的,难以合作甚至互相贬低,其实设计是什么,相对于机器码和汇编我觉得现在的语言就能算设计了,要清楚设计和开发是紧密结合的,在甫获需求阶段,你必须清楚实现约束,在制订迭代计划时,你要清楚哪些有技术风险,在迭代过程中设计会随开发而变化等等.希望做开发的人能了解设计,并有意识的学习(不一定要急着成为设计),毕竟一个好的设计是开发的高层阶段,做设计的人要熟悉开发,不清楚开发是怎么回事就做设计,纸上谈兵.***好的软件工程师必须要克服懒惰和浮躁,要有想法,也要脚踏实地,否则想法只是想法***
第五,写这么多,累了,赫赫,够懒的了.也不算回应你的帖子,只是做了这么多年,有些看法,希望能对在这行业里发展的人有帮助,中国的软件业能好些.(我觉得现在真的是满差的)
> 原文(newdongkui于2002/06/25 12:45粘贴)
回复: 我有一个梦想------程序员下岗-----快活DIY开发者之梦
--------------------------------------------------------------------------------
我和我周围的一些朋友或多或少都在做类似相近的事情，大家缺乏一个统一的认识，而且往往陷入一些具体的代码封装或一些行业应用的细节，其实有共同的感觉：这是一个漫长的过程，我们还有很多知识没有准备好，缺乏一个有商业头脑的组织者和一个有绝对丰富经验绝对控制能力的项目组长。
建议你搞一个网站中英文的，把想法和资源开发出来，建立小组，划分课题，共同讨论，两三年后，我们会得到专业企业和行会的注视，建立标准，选择Java或其他一门语言，推出Demo，得到大多数人的注意，然后再来整合，集真正足够的力量，来完成和实现它。
另外我感觉语言之间的界限越来越模糊，WEB和Local越来越相似，我们也许应该考虑一下三层的结构，简化界面和表示逻辑，从另一个角度让程序员下岗。
> 原文(newdongkui于2002/06/26 09:24粘贴)
回复: 非常感谢，希望大家现在把讨论的重点放在怎么去实现它！
--------------------------------------------------------------------------------
更可操作的，是自由小组组合和规范源码开放的做法，既自由软件.把这个东西彻底开放和透明化，再由其中的志愿精英，各自把握方向，交叉，试验，实践，应该会清晰化我们的思路，统一我们的思想，我们现在的问题是，思路思想都不统一，大家的伊甸园风景不一；比如我大学（6，7年前）时，发过一次神经：要消灭语言（vb，vf，pb，delphi...），让项目开发人员，搭积木，拿各种模块，来做项目，开发变成装修。现在想起来，也傻也不傻
另外有一个不好把握的就是，用户的个性化要求和行业上特别应用。
假设这样一个开发体系：
用户需求－－》需求分析－－》FFDD建模分析（抽象，建模，叠代......）－－》FFDD模型抽取（功能模型板，流程模型板，业务模型板，架构模型板，测试模型板......）——》FFDD实例化（架构件，数模件，应用和功能件......）－－》代码实现
我觉得你能明白我的意思
