－－几分钟看完全文，还是不知道他到底是怎么做的。。。好像有resin
【GBDP的配置会和J2EE一样复杂吗？如何运行GBDP代码呢？刚好相反，非常简单, 普通配置好resin等后, 把模块化的jsp文件和java文件放到相应的目录，然后建立一个空的数据库, 配置好连接, 修改dbName的值后, 就可以运行了, 连接池、数据表和记录什么的都会自动配置和建立的, 不用操心了。】
【需要指出的是，在大型项目开发中
80%以上业务实现是简单的，只有不到20%是复杂的
另外GBDP适合于jsp,asp，不适合Delphi,C++类的编程，
站在Delphi,C++的角度,GBDP就一无是处了，但GBDP是针对JSP，ASP的
如果你真正用GBDP写过东西，你才能体会到它的好处，特别是改动需求的时候
用项目开发理论来论证GBDP的优缺点是没有意义的，因为我已经实现了相当复杂的项目（为了和同事打赌），
而且我参与开发过财务软件和ERP
】
GBDP技术简介
( 强干扰反编译class的“专利”技术, 反编译一个死机一次 )
GBDP 技术演示网站：2005.09.10 Last Updated
http://www.universecommerce.com PowerPoint演示
介绍之前，请先看看这幅图 (鼠标滚轮可以控制大小)
A和B的颜色是一样的，但我们的眼睛却说是不同的，哈哈，被眼睛骗了吧；
希望您可以用同样的感悟浏览下面的内容，不要让直觉和习惯来左右大脑
******
GBDP 技术体系是取代 J2EE、.NET 的下一代软件开发技术体系( 2002开始研发，于2004年底实现成熟商业化的GBDP 4.0，2005年底推出 GBDP5.0 版)
目前人类已知最快的成熟商业化应用开发体系，实现和更改需求以分钟为单位，而不是通常的小时和天；包含单机、CS、BS等多个版本，支持C++、JAVA、.NET等开发平台
GBDP is a new software developing system. It's simple, efficient
and powerful. The terminator of J2EE.
对软件开发“不很了解”和“了解过头”的朋友，可把GBDP看作应用软件开发中的
李小龙、歼10、空中突击师、东风41、等等
********************************
********************************
GBDP 1.0 代码范例：
GBDP实现示例 JSP 版本：( C++ 版采用 isapi或者单机CppWebBrowser运行)
<%--
采用了GBDP
--%>
<%@page contentType="text/html;charset=GBK" %>
<%@include file="head.jsp" %>
<%@include file="ntGBDPDefine.jsp" %>
<%
//全局变量定义
globalTableName = "publish";
parentKey = "发布申请";
parentValue = "收文单";
dbName = "ew";
isUpload = true;
%>
<%@include file="ntGBDPUpload.jsp" %>
......
页面部分
<input name="姓名" ...>
<input name="年龄" ...>
<%
if( isPost )
nt.toDB( requestHt );
if( isPost ){
out.println("<script>alert('成功!');"+
"window.opener.location.reload();"+
"window.close();"+
"</script>");
//response.sendRedirect( selfPath + "news_edit_list.jsp");
return;
}
%>
.......
<%@include file="ntGBDPScript.jsp" %>
以上就是GBDP实现一个简单的增删改单元所需要的代码，看起来非常简单吧，因为其他的都自动处理了；而且如果要增加字段和内容，不用修改一个字符
********************************
2005.09.10
k*系统与gbdp的对比，以及k*存在的问题: (k* 代表目前流行的编程方式)
目前传统的开发流程：
需求（Req）
概要设计(SD, System Design)，又称系统设计
详细设计(DD, Detail Design)
编码(CD, Coding)
发布(Deploy)
集成测试(IT)
GBDP则一般为（需求了解、界面和代码实现、更改需求）3个主要阶段(GBDP开发人员平级并行式工作, 允许虚拟数据，可以乱序开发、并行开发)
GBDP并非要否定对象化开发，相反是对象化的补充和囊括(比如GBDP的界面开发中大量用到了图形化组件)， GBDP不存在框架限制的问题，因为GBDP本身没有框架，
GBDP是一系列优秀需求实现的集合，因此拥有极强的适应能力；开发中心思想是找出输入和输出的最简洁实现， 用不用对象不是核心问题，即使是微对象的表达方法也不是一成不变的，只是目前它是最好的选择(不同意可以提出更好的结构，我立刻采用)
GBDP开发方式：每个人做自己的业务模块，并行式开发，相互之间无依赖性(即使业务相关)，GBDP体系的公用模块代码修改提交给专人负责维护，或者增量式维护(修改后必须注明来源版本和时间)
GBDP的“字段”是全中文的
k*配置部署麻烦，定义元数据的过程也是一个比较耗时的过程，还要构建等等；而GBDP几乎没有配置部署，开发的过程同时就在部署和编译；实现需求的代码一般在JSP中（也可以在class中，但不推荐，因为丧失了部分灵活），class一般是公用的从实际操作来看，k*还在定义元数据的时候，GBDP的程序已经在运行接受测试了(我本来开着J10，突然间到k*后在马路上开步兵战车了)
GBDP体系严格来说，本质是修改，而不是在开发，而是在已经实现的需求模板库中找一个近似的，然后经过略微修改（什么叫做略微修改？，通过周易预测的例子可以让大家感受一下），而成为新需求的实现，也就是所谓的“贴膏药式开发”，目前主要是菜单、列表、编辑、权限等；不要有框架和架构的思想，它就象一个更大的房子，虽然比其他房子大，在提供强大功能的同时，但也限定了我们发挥的范围，因为它有边界，试试幕天席地的感觉；因此.net的最大问题就是，尽管更漂亮、面积更大，但它还是房子，而且由于低层隐藏的太深，限制了灵活。
不过，asp.net的界面倒是GBDP体系中一帖非常好的膏药。GBDP就像一个拥有魔鬼身材的人（输入输出丰富灵活，可中间代码很少）。
就我目前所接触的，k*目前能做到的，GBDP都可以轻松做到。现在以模仿E** GRID框的实现来举例GBDP的灵活实现方式
a. javascript b. Flash (效果可以远远超过目前E**的效果) , 若要谈理论的话，目前k* 服务端实现不如GBDP后台灵活， java界面表达上不如IE + Flash 丰富强大, 需求分析，开发，部署，维护什么的复杂度都超过了GBDP。例如，仪表盘的实现 GBDP其实根本没有主从表、明细表、单据分录的概念, 数据间是弱联系，和k*的强关联形成了鲜明的对比；“无为”方能无所不为， “无为”自然能无所不为，并非什么都没有了。
k*的数据库新旧导入和转换工作量大，复杂度高，目前的方法是完全写SQL脚本，不好，以前我写过SQLServer 转 Oracle的类似工具可以借鉴
目前很多方法是实验室方法，没有考虑到意外情况，例如光盘单面在实验室已经到了100 G 以上，但我们实际中只有10 G以下 如同坦克目前绝大部分还是手排，没有换成自动波 GBDP对于类似的“表结构”，可以简单的复制修改后成为新的“表结构”，
B**的需求相似元数据定义无法简单复制，只能重新定义，或者继承
不要把YY之类的纸老虎当做对手，这样就把自己放的太低了，我们还有更大的目标：为中华之崛起而工作，为人类之进步而创新。 功夫在诗外
k*平台开发的同步和更新问题是一个大麻烦
B**平台以层级、继承为特色，优秀的封装，代码编写量少；但给升级、维护、需求变更、功能扩充带来了艰难，个人感觉甚至超过了带来的好处，有点类似于.net。一个女人再漂亮，能干，但不顾家，你永远不知道她什么时候突然就离开 Just joking: K****** 以后最好不要发音成“啃地”，应该是“KING Defeat EvEryone”(王者无敌)
希望自己不要沉浸在解决BUG中，自己的思维都有些迟钝了, B**终结者
采用GBDP的坏处是，节约了大量的人力成本，我不希望看到同事们被解雇。不过不用担心，k*不会采用GBDP的
虫生虫，缝生缝
初期设计要主动
莫到维护喊没空
加班白头亦无用
B**的排错和功能变动会带来实际上巨大的工作量
构建一次要 x ~ x 个小时，天哪，居然源代码压缩了后有 xxx M
20050202 出现空指针的错误，单步跟踪调试了好久才发现是“xxxx表”的数据有错造成的，实施人员可要喊天了。
例如单据（包括单据分录）的制作（不考虑业务逻辑的情况，时间计算从开机到可以运行给客户看），B**架构开发熟手需要最快2个小时，慢则半天时间；目前流行的一些高速开发工具（包括建库）也大概在这个范围，但GBDP有更快的方法（10分钟以内）。如果业务变动了（字段改变和业务逻辑三分之一变化了），在“B**数据更新”功能完善的情况下（且不考虑DEBUG工作量），
理论上需要72分钟（如果是按照目前的实际状况，远远超过72分钟）；GBDP有更快的方法（包括字段改变和业务逻辑变化，数据转换，DEBUG全部加上，直到给客户Beta3测试，10 ~ 60分钟）
如果您要问技术的最高境界是什么？Philips已经回答过了：“简单”
ad: 削弱或者取消表间约束关系，数据完整性验证尽量由代码来进行（注意验证要输出详细的过程信息，由配置决定是否开关
输出信息），这样可以在情况变化的时候不致于太忙，公司亦可减少加班成本
ad: 尽量用详细的运行过程信息取代跟踪调试，这样实施人员就不用去魔法学校去学习，开发人员不用去健身室打沙包
ad: 为减轻BUG和维护压力，以及服务器的运行性能，能够在客户端执行的任务尽量放在客户端，不要去骚扰服务器；
例如，数据引入中，任务执行是在服务器，EXCEL表数据解析消耗了很大一块的时间，可以将EXCEL表数据解析放在客户端，
转换成XML后，传到服务器去执行（word等其他格式文件亦同样处理，好处是可以在一定程度上“任凭客户风浪起，服务稳坐钓鱼台”）。
ad: B**增加相似需求直接拷贝能力，不要仅仅只是继承。例如，把一辆车喷漆，直接变成另外一款车；而不用设计母车，然后继承，设计成两款车型。
ad: 考虑用其他格式来代替XML保存元数据，XML适合小数据量，检索性能亦差，E**构建一次要 x ~ x 个小时，源代码压缩了
后有 xxx 多M，不能说和XML的低效没有关系；我N年前曾经做C++下的XML性能测试（500M CPU），当XML的“总记录量”在100条以下的时候，单条记录ADE(add,delete,edit)速度有 几百条/秒 ；当“总记录量”在3000条以上的时候，单条记录ADE速度下降到 几条/秒。我们可以想想JAVA下E**的惊人的元数据量在XML方式的效率。
ad: 架构师升级到“体系设计师”的水准
什么是“体系设计师”？举个例子，《布衣天子》电视剧中有个情节，皇帝为了解救瘟疫而赈灾摆医擂，太医们的药方是人参鹿茸等名贵药材，洪立的药方除了黄连还是黄连。太医是优秀的架构师，洪立则是“体系设计师”。“体系设计师”不仅要考虑到技术实现层面，更要综合考虑到合理的开发失误、成本核算、员工管理、客户满意度、需求应变、BUG控制、利润吸纳度、炒作便利度、健康保险支出、等等董事会、市场、人事、技术等诸多角色才考虑的事情。
B**与GBDP的技术层面简单比较: ( B**代表目前主要编程模式 )
1. B**基于JAVA; GBDP支持C++，java, jsp, asp, .net 等实现方式（目前C++版实验室阶段，jsp版
实现了商业化，其他没有商业前途，暂时不考虑）
2. B**基于对象; GBDP基于需求，考虑对象比较少，但不排斥对象，GBDP对象主要存在于界面
3. B**只基于CS（我不确定） ；GBDP有单机、CS、BS多种，且可以相互融合
4. B**的DEBUG、升级、维护、需求变更 相对艰难；GBDP基本没有这些烦恼，且有完善的解决手段
5. B**追求大而全；GBDP的主旨是：需要多少做多少，需求随动，挣变化的钱
6. B**的界面比较固定单一；GBDP利用IE和FLASH的支持(GBDP的单机C++版是内嵌IE控件来进行
界面表达)，界面灵活丰富且修改容易
7. B**是基于开发模式的；GBDP体系严格来说，本质是修改，而不是在开发，是在已经实现的需求
模板库中找一个近似的，然后经过略微修改，而成为新需求的实现，也就是所谓的“贴膏药式开发”
8. B**字段名是英文，GBDP是中文
9. B**的开发流程：
//
需求（Req）
概要设计(SD, System Design)，又称系统设计
详细设计(DD, Detail Design)
编码(CD, Coding)
发布(Deploy)
集成测试(IT)
//
GBDP则一般为（需求了解、界面和代码实现、更改需求）3个主要阶段(GBDP开发人员平级并行式工作, 即使业务相关，也无须等待其他人工作的完成，可以乱序开发)
/////////////
我认为宜早不宜迟的重要事情，从管理和流程革新上要利润
如何从流程上来保证减少初期设计失误呢？其实也不难，多出宫，下基层，体察民情；最重要的是，挑几个战术上的难点和典型（工作量不大的），架构师等高手们亲自完整实现（包括DEBUG、需求变更、维护模拟），给数个模板（不是demo）直接给开发人员去套; 这样，技术难点、风格统一、DEBUG、维护难的问题，可以直接消灭在战略设计阶段。缺点是宰相们可能要亲自挑水体验生活。
变“开发产品、写代码”方式，
为“修改模板、套代码”方式，
（B**目前在这方面做的很不够，或者根本没有此思维）
这样才能在质上提高速度，这其实才是GBDP的精髓之一，技术是变化的，精髓不会变，不要买椟还珠
/////////////
自入职以来，首次运抵K*后院的第一批石头
第一块:
*被砸目标：
B**复杂的架构，导致原本简单的Debug、库转换、升级、需求变更等等复杂无比。B**的层次组件结构，无法满足乱序开发，并行流水的高速开发要求（可以参考CPU的设计思想）；和下一代软件开发的超机动化（需求变动），超视距（需求不明确）作战要求相比，就差的更远了。
*理论雄辩：
□一个人工作几个人干，比一个人干还忙，因为这些人之间将形成许多相互关系，制造出许多工作，几个人都将会显得很忙。
□ 组织的历史越久，规模越大，成员人数越多，关系就越复杂，扯皮的事就越多；
一般来讲，企业规模越大，管理层次越多；在业务一定的情况下，管理层次越多，所需人员越多。所以，只要管理幅度不超过企业人员的管理能力，管理层次越少越好。
这些是管理学方面的知识，其实和软件技术架构的原理是一样的，B**架构分的层次太多了，腰是瘦了，结果腿肿了，开发阶段小桥流水，维护和升级阶段却洪水泛滥了，望山跑死马了。它就象一个更大的房子，虽然比其他房子大，在提供强大功能的同时，但也限定了我们发挥的范围，因为它有边界，同时造成了维护上的惊人成本，试试幕天席地的感觉；因此同样.net等的最大问题就是，尽管更漂亮、面积更大，但它还是房子，而且由于低层隐藏的太深，限制了灵活, 这就是它的败笔（你会娶一个漂亮但不知底细的女人做老婆吗？），也反映了“福兮祸之所伏”的辨证法则。不客气的说，就着B**目前这锅汤，R*****的“以客户为中心，快速反应”的梦想，锅熬破了也别想有香味出来。
*事实如山:
刚巧，昨天周日，一个我以前的老客户从广州抱着厚实的IBM笔记本又来找了；我花了6个钟头解决了他诸多的功能增强、修改要求；而且这6小时还包括了吃饭看电视聊天；此客户以前找其他的软件公司不是告诉他不能改，就是要等一个星期，而我几乎都是一天以内搞定，还包括了各种HAPPY时间；所以这个客户宁愿频繁到深圳来找我，都快找上瘾了；也不愿意找广州当地的公司，这才是“以客户为中心，快速反应”。（煽自己一巴掌，不要显摆，谦虚点）
*苦口良药：
彻底改革B**的整个架构，至少也要来个洋务运动，等八国联军打进来就晚了；目前事实上的高BUG率和维护的艰难已经在敲警钟了。不过激进式改革可能会导致苏联的下场，不妨学学邓小平，划个特区，K*也可以借鉴成立“E**开发改进特别委员会”，简称“发改委”，专门实验新技术，新思想。这样，既有航母的重载优势，同时不失舰载机的灵活。
第二块:
*被砸目标：
思维的局限性：为了JAVA而JAVA，忘记了跨平台是真正的目标，在追求100%纯java的热情中，我看到的是王明的影子，Keep it simple 在B**中成了花边点缀。我们的架构师仅仅是架构师，没有达到“体系设计师”的水准。
*理论雄辩：
什么是“体系设计师”？先举个例子，《布衣天子》电视剧中有个情节，皇帝为了解救瘟疫而赈灾摆医擂，太医们的药方是人参鹿茸等名贵药材，洪立的药方除了黄连还是黄连。太医是优秀的架构师，洪立则是“体系设计师”。“体系设计师”不仅要考虑到技术实现层面，更要综合考虑到合理的开发失误、成本核算、员工管理、客户满意度、需求应变、BUG控制、利润吸纳度、炒作便利度、健康保险支出、等等董事会、市场、人事、技术等诸多角色才考虑的事情。
*事实如山:
说了有做广告、自我吹捧的嫌疑，此处省略N个字
*苦口良药：
难，撼山易，撼人心难
第三块:
*被砸目标：
我们的技术人员只知道钻研技术，不知道功夫在诗外的妙处。一线开发人员应该多接触客户，多去唱歌跳舞极限运动等与技术无关的事情。
*理论雄辩：
太玄了，扯到哲学和宗教上去了，此处省略N个字
*事实如山:
说了有做广告、自我吹捧的嫌疑，此处省略N个字
*苦口良药：
一律不准加班，下班了统统赶出公司；加班可以，要么不加，一加惊人，必须24小时加班，等你眼睛看东西都是重影的时候，自然会考虑寻找搓衣板替代品的事情。我们的员工太勤快了，不会把懒偷到实处的员工不是好员工。
第四块:
*被砸目标：
我们竟然把YY之类的公司作为对手，挥泪大甩卖了自己的身份，通货紧缩了自己的使命。为中华之崛起而工作，为人类之进步而创新才是我们的初级目标。
*理论雄辩：
你把什么当做对手，你就和什么是同一个档次。
*事实如山:
还没有
*苦口良药：
自己开吧
第五块:
*被砸目标：
在靠服务收钱的赢利模式下，我们深入客户不够，这里是指开发人员，不知道人性化的真正含义，就是贴合客户的个性化操作习惯，而且只要IQ高于60的人无须培训也能玩上一把；开发人员天天不出紫禁城，怎么知道客户想什么？梨子的滋味是要亲自尝的，任何人的包办都会变味。
*理论雄辩：
没有
*事实如山:
试了就明白了
*苦口良药：
这个药是甜的
第六块:
*被砸目标：
缺乏创新的环境，我们给衣服改样子、打补丁的时间花费太多，无暇顾及创新之类的事情了。
将根据大家的反应，提供更多的石头。
哈，我带着核子技术和多纬度立体战争思想来到这里，要么K*成为尼米兹，要么我自己建造094
--------------------------------
--------------------------------
---- 标题：关于我和K*文化、技术融合的问题 ( 应 xx 要求 2005.02.28) ----
首先我非常感谢K*灵活而宽容的文化氛围，k*至少能睁开眼睛看看可能洒到眼里的沙子(也许是沙金哦)。
很多公司根本就是闭着眼睛评头论足，夜郎自大。仅此一点，我断言k*未来做到中国亚军位置毫无问题。
-- 不得不说到GBDP：
我认为新的编程革命将在未来5-10年内到来，届时现有的数据库和许多编程方式可能都要改变；驱动力
来源于互联网的进一步普及（海量数据处理、人工智能技术等）和下一代微型便携式或者超级迷你电脑
的出现（融合于手机等），真正的分布式时代将开始（现在的笔记本已经做到了1公斤上下，x000 RMB，
几年后呢？）。此时将会出现“数据海洋”的概念，终端就像大家去图书馆看书一样，获取自己需要的
数据就可以了。GBDP就是应对此局的。
-- GBDP诞生的文化背景，为何是我做出了此“离经叛道”的东西？
我毕业来到深圳后，不像其他人直接进入了大公司，加入了正规军；我加入过的公司已经记不清了，几乎
都是小公司，因此接触到了很多不同的技术实现，明白了一个道理，就是“当你解决问题的方法很复杂的
时候，一定有另一种简单的方法存在，只是你不知道”。另外一个决定性的因素是，因为公司小，经常我
要一个人完成所有的任务，老板经常用“枪”指着我的头让我完成不可能的任务（玩笑）。因此我不得不
研发出一种开发速度达到极致，BUG低到极限的编程体系；看到大家现在有那么“多”的时间来DEBUG，我
很是羡慕，因为想当年我开发代码的时间老板都不给够，何谈DEBUG？
因为k*大，部门多，所以不在乎，也难以在乎“整体效率”的提升，因为某个部门的效率提升和卓越想法，
也许恰恰是另一部门的梦魇（k*缺乏整体评估体系）
为什么我一直强调要架构师（或者高级专家组）要亲自完成典型需求模块的全部实现（包括DEBUG和需求
变化模拟），原因在此。毛泽东亲自种田，还会亩产万斤吗？（我只是就事说事，没有别的意思，大家莫生气）
-- 我与K*的融合
在我第一次来k*和大家交流的时候，大家仅对我的技术实现底层感兴趣，却不问我为什么要做自己的技术
体系，以及为何选择一些“大逆不道”的实现方式，我就明白了自己在K*能做些什么。GBDP技术体系中
分支包含C++版本和java程序版本（c++ 版本已经接近完成；java程序版本因为实用度不高，被抛弃），
其中的思想、技术实现、开发人员管理方式可以借鉴给B**架构。
我的要求不高：
1) 高速需求实现：
B**开发实现相似需求直接拷贝能力，这样可以将相似需求的开发时间由现在的1~2天缩短为30分钟以内
例如开发人员花费了一天完成基础资料中“国家”，完成另外相似的“省份”什么的就只需要30分钟
2) 低BUG率
开发人员无须采用跟踪方式就可以解决出现的BUG，在客户那里的实施人员可以一目了然错误的模块
3) 构建时间低于30分钟
4) 开发人员管理的改革 ( 建议在“设计人员能力要求及提升方法研讨”中讨论讨论 )
GBDP中有一种开发人员管理模式是专门应对“大规模流水线式并行开发”的：
a. “需求”开发人员、
b. “实际代码”开发人员；
c. 高级专家组
三者都是要写代码的，但分开，a专门写业务逻辑（使用“可替换java代码”，可以直接运行排错），
b将前者的“可替换java代码”转换成为实际的代码；c负责技术难点实现和架构问题。
这种方式可以良好的解决工作量的分流，以及高端技术保密的问题。
个人的一点拙见，请大家批评指正。
--------------------------------
--------------------------------
......
本来以为只有小公司才有这些需求强烈变化后导致疲于奔命的情况，没想到K*以产品
为主的大公司也同样存在这些问题。GBDP把对象纳米化后，可以在完全没有文档的情况下，
比较容易的掌握需求（通过查看GBDP数据和代码，因为它们非常的相象，即使是在看上去差别
极大的需求，亦是如此）。
顺便谈谈一些小细节，E**中有一些NULL导致的BUG，GBDP中根本不允许NULL值的存在，如
果一个值是NULL，根本不会存到数据库中； 例如E**还有一些日期什么之类的问题，在GBDP中，
日期全部统一是一种格式，而且通过标准统一的方法来调用，想出现错误都难。像数据升级和
导入的功能，GBDP是天然支持的，且实现简单；因为GBDP体系是为了需求强烈变化而设计的，
升级和导入不过是需求变化的一种形式；甚至E**的数据库内容也可以轻松导入到GBDP中。
本来想把这些告诉总体组，还是算了，免的被认为是广告；私下你们知道就可以了，知道
这个世界上还有复杂的彼岸，就是“简单”。
再次强烈感觉到了“山河易碎，人心难撼”。
...
////////////////////////////////
////////////////////////////////
像这种开发人员容易犯错误的地方，
我们不应该怪开发人员，因为这是java本身的BigDecimal易用性和抗误导性差造成的，我们不是机器。
因此以后类似的问题，我们应该进行自己的类封装 写一个 xxBigDecimal 来防止错误使用
开发应当允许出错，关键在于防止错误的机制。
通过《编码规范》等君子法则来约束的效果是有限的，况且工作交接和人员更迭使《编码规范》的实际效能大打折扣
---
从操作可行性上来说，我们可以改造B**，让B**增加实时弹出式警告来发现“疑似BigDecimal违禁使用”的情况
或者在构建的时候检查
把自行车和行人排除了，高速公路才可能高速
---
--------------------------------
--------------------------------
4. B**架构与GBDP体系的冲突与合作
答：
简单介绍
http://www.universecommerce.com/newtower/htm/gbdp_intro.htm
条条大路通北京，英雄所见略同，但为什么B**和GBDP对比起来，共同点很少？
首先承认B**是先进的，和其他公司对比是领先的，但和GBDP对比的话，B**还谈不上到了北京，
像李敖一样，我不但说B**没到北京，更可以证明它没到北京。只要公司提供一次开发擂台比赛
的机会，我就可以用事实证明给大家看。
B**与GBDP的技术层面简单比较:
0. B**开发以天来计算；GBDP以小时来计算
1. B**基于JAVA; GBDP支持C++，java, asp等（jsp版实现了成熟商业化应用）
2. B**基于对象; GBDP基于需求复制，考虑对象较少，但不排斥对象
3. B**基于CS ；GBDP有单机、CS、BS多种，且代码基本相同
4. B**的DEBUG、升级、维护、需求变更相对艰难；GBDP基本没有这些烦恼，且有完善的解决手段
5. B**是基于开发模式的；GBDP体系严格来说，本质是修改，而不是在开发，是在已实现的需求
模板库中找一个近似的，然后经修改，成为新需求实现，也就是所谓的“贴膏药式开发”
6. B**的开发流程是传统的“概要设计”、“详细设计”等多个步骤
GBDP则一般为（需求了解、界面和代码实现、更改需求）3个主要阶段(GBDP开发人员平级
并行式工作, 即使业务相关，也无须等待其他人工作的完成，可以乱序开发)
GBDP的许多优势是B**不具备的，但GBDP欠缺大型应用的履历，因此有相当大的交流空间；
对B**改良的成本和风险(即使不存在GBDP，同样存在)，可以建立“K*开发特区”的方式来规避
5. 公司评估与论证体系的完善
答：
实践是检验真理的唯一标准，但公司在评估论证方面有些不足，理论雄辩是一回事，
实际效果是另一回事。建议在评估与论证时，技术和方案采用竞标的方式，以实际测试
数据和效果为标准，不要过于相信理论和习惯。
比如某个部门的效率提升和好的实现，却导致了另一部门的难题；所以我们需要整体
评估的体系。
-- 不但说了还能做到
6. 开发与管理的改革
答：
a) 架构师（或者高级专家组）要亲自完成典型和难点需求模块的全部实现（包括DEBUG、
维护和需求变化模拟）。原因在此: 毛泽东亲自种一分地，还会亩产万斤吗？
b) “大规模流水线式并行开发”的开发人员管理模式
A. “需求”开发人员、
B. “实际代码”开发人员；
C. 高级专家组
三者都是要写代码的，但分开，A专门写业务逻辑（使用“简单可替换式代码”，可以在平台上
直接运行排错，且培训容易），B将前者的“可替换java代码”转换成为实际的代码；C负责技术
难点实现和架构问题。这种方式可以良好解决工作量的分流，以及高端技术保密的问题。
7. 重点强调与本文思想传达范围
答：
B**的改良或者改革，很容易牵涉到伤筋动骨的问题；其中的成本和风险(即使没有GBDP，
同样存在)，建议成立“K*开发特区”的方式来规避，如同深圳经济特区。
为什么我们疲于奔命？为什么有的开发人员在抱怨很多代码是临时性的？为什么不能按
时交付客户产品？ ...... 等等这些，希望大家认识到这是B**整体架构本身带来的，指望
换件衣服，涂点口红就成为美女，有那么便宜的事情吗？下面的人员往往被问题细节所埋没
，眼光不可能足够长远开阔，因此希望此文能够呈现在R*****面前，无论迎拒，至少心愿可
了。
--------------------------------
--------------------------------
GBDP 体系中需求代码的范例：
答：
有两种方式 a) javascript + html , b) java
推荐用方法a, 因为不用安装任何环境，有IE就可以，每个业务单元展现为单个的 *.htm 网页文件；
实际举例：( 计量单位组 和 计量单位 )
请将<script> ... </script> 的部分保存为test.htm来看结果( 包括 <script> </script> )
file: test.htm begin
<script>
// 此部分模拟“实际代码”中的录入部分 ,
// 其中的 _1_ _2_ 1,2...代表记录的唯一id号, 不是行号，相当于 FID 的用途
// 如果需求人员的技能较高，可以通过实际的文本框来获取值
var 计量单位组_1_FID = "94b634af-0102-1000-e000-03bbc0a813791C2AC868";
var 计量单位组_1_名称 = "重量组";
var 计量单位组_1_编码 = "100";
var 计量单位组_2_FID = "94b634af-0102-1000-e000-03bec0a813791C2AC868";
var 计量单位组_2_名称 = "长度组";
var 计量单位组_2_编码 = "200";
// --
var 计量单位_1_FID = "a50fe8c8-0102-1000-e000-09d8c0a8100d5B825C57";
var 计量单位_1_名称 = "千克";
var 计量单位_1_编码 = "01";
var 计量单位_1_隶属组 = "a50fe8c8-0102-1000-e000-09c1c0a8100d1C2AC868";
// 此部分模拟代表“实际代码”中的数据验证部分,
// 这里“== null”不代表真实的逻辑判断，而是通过注释让“实际代码开发人员”具体实现
if( 计量单位组_2_名称 == null ) // 名称必填
alert("计量单位组_名称为空");
if( 计量单位_1_隶属组 == null ) // 判断对应的“计量单位组”是否真实存在
alert("计量单位_1_隶属组: 没有找到对应的计量单位组");
// 输出显示
// javascript遍历元素, “需求开发人员”直接套用即可, 后退2格的表示直接套用的
for(var i=1; i<= 999; i++ ){ try{ // 循环开始 直接套用
var s = "计量单位组_"+ i +"_FID"; // 需要更改
document.writeln( s + " = " + eval(s) + "<br>" ); // 直接套用
var s = "计量单位组_"+ i +"_名称"; // 需要更改
document.writeln( s + " = " + eval(s) + "<br>" );
var s = "计量单位组_"+ i +"_编码";
document.writeln( s + " = " + eval(s) + "<br>" );
document.writeln( "<br>" );
}catch(e){break;} } // 循环结束 直接套用
for(var i=1; i<= 999; i++ ){ try{ // 循环开始 直接套用
var s = "计量单位_"+ i +"_FID";
document.writeln( s + " = " + eval(s) + "<br>" );
var s = "计量单位_"+ i +"_名称";
document.writeln( s + " = " + eval(s) + "<br>" );
var s = "计量单位_"+ i +"_编码";
document.writeln( s + " = " + eval(s) + "<br>" );
var s = "计量单位_"+ i +"_隶属组";
document.writeln( s + " = " + eval(s) + "<br>" );
document.writeln( "<br>" );
}catch(e){break;} } // 循环结束 直接套用
</script>
file: test.htm end
--------------------------------
--------------------------------
希望转给xxx
K*拥有的雄厚技术早就足以开发类似GBDP的体系，况且我们都明白不可能在短时间内对B**
做出什么实质性的改动和提高，因此从开发流程改良上入手是比较实际的。（有趣的是：K*已
经可以登火星了，却没有核武器；我缺乏很多资源，飞机都造不出来，却一个人搞出了GBDP这个
两弹一星）。所以我认为当务之急是推行联产承包责任制，而不是超级杂交稻的研发。
建议首先实验“需求”、“代码开发”、“专家组”三权分立的开发模式！(希望这是我下一
阶段的工作安排)
“需求”、“代码开发”、“专家组”如果比作女人的三围的话，我们目前的情况是木桶包
心菜的身材：“代码开发”人员既要了解需求，又要解决架构上的问题，腰是如此的粗！！！
所以我们应该运用魔鬼身材式开发流程：“需求”40%、“代码开发”25%、“专家组”35%
难道这样不是最合理最美的吗？当年爱迪生的助手按照图纸成功造出留声机后，居然还不知道自己
造的是什么机器，我们就是要把开发流程优化到这种境界。
附:
开发与管理的改革
1) 架构师（或者高级专家组）要亲自完成典型和难点需求模块的全部实现（包括DEBUG、
维护和需求变化模拟）。原因在此: 毛泽东亲自种一分地，还会亩产万斤吗？
2) “大规模流水线式并行开发”的开发人员管理模式
A. “需求”开发人员、
B. “实际代码”开发人员；
C. 高级专家组
三者都是要写代码的，但分开，A专门写业务逻辑（使用“简单可替换式代码”，可以在平台上
直接运行排错，且培训容易），B将前者的“可替换java代码”转换成为实际的代码；C负责技术
难点实现和架构问题。这种方式可以良好解决工作量的分流，以及高端技术保密的问题。
--------------------------------
********************************
可怜，我在2002年即推出新一代取代j2ee和.net的新技术体系(2004年成熟商业化)，专门解决抗需求变动和高速开发的问题（如果推广的话，中国的用友等类似公司将可能破产）。可惜到现在也没有遇见个伯乐；尽管我在大大小小的公司实际演示过几分钟内做成或者修改一个业务模块（目前国内其他公司最快也得一两个小时，指从接到客户需求到可以给客户使用）。
可惜领导层都认为新事物风险太高而拒绝（虽然我只用了十分之一的开发成本和时间），尽管我已经成功的用新技术体系实现了不少的商业案例（其中有许多是别的软件公司开发失败，不得已转给我的）。详见 http://www.universecommerce.com
叹叹，习惯于“拿来”、缺乏创新的中国IT业！
2005.09.09
********************************
GBDP的市场定位：
1. 蛋糕：“中国特色的ERP”市场 （国外传入的ERP在中国像传销一样水土不服），
这是一个巨大的市场，如同没有穿鞋传统的非洲
2. 年糕：“党政军、公检法”市场；（微软通过免费派发摇头丸让你上瘾，然后杀
年猪占据的市场），同样一个巨大的市场，但需要培育和耐心，建议看看
《曹刿论战》；跟我一起摇啊，铜板叮当响啊
3. 内二外八糕：“盲人骑瞎马”市场；在这里，客户不知道自己具体需要什么，软
件开发者也不知道要做成什么；呵呵，这也是商机
GBDP缘起： 诞生有点像J10，本想养了卖的，不料“臭老九”做的太好，结果得宠成了贵“飞”
曾几何时，叹2001
前有客户发飙，
后则老板督阵；
加班已，
悟人生；
GDP，无我份
莫学后主甘称臣
铸剑惊鸿绝长恨
GBDP的缺点：
0. 在某些情况下，理论上运行性能稍逊色于其他高度优化的编程模式(奇怪的是，在实际对比测试中GBDP性能一直领先)
1. 理论上，空间消耗大：采用空间换时间、空间换性能、空间换灵活的方法，导致数据存储多
占用30%-100% (奇怪的是，在实际对比测试中多数情况下GBDP占用空间反而更少)
2. 遭质疑批判：允许需求任意变动的能力、大逆不道的"显示与逻辑合一"遭到专家级
质疑和“成熟理论”的批判；尽管作者已在实践中成功印证，技术擂台比试中获胜。
3. 短期效益不明显：虽然能够较好满足中国客户的苛刻要求和显著节省程序员的工作
量；但在中国软件业不景气的大环境下，老板可简单的运用“中国国情”的办法来
迎合客户和让员工“自愿”加班来提高生产力。GBDP让客户和员工享福，但老板收益增加不多。
GBDP独特之处:
0. 允许频繁更改需求：程序员只需要加班费而不需要加班, 老板只需要客户多付钱。
这是GBDP有别于其他技术体系最耀眼的光环。AD：“拥抱GBDP，移民到天堂的感觉”
1. 文档要求低：即使开发文档丢了, 也可简单的凭代码和注释了解业务逻辑, 因为
GBDP规定了严格又不失灵活的代码范本和数据结构，只需要在代码中多些注释就可
几乎不用写文档
2. 配置简单：和J2EE头大的配置来比,GBDP几乎没有配置,更谈不上复杂配置, 全自动
4. 学习移交简单：完全了解GBDP(源代码级)，智力周期低潮的人需一周，快的一天，
但在开发中节省的时间就远远赚回来了。但这是最难的一关，因每个人都认为自己
的床是最舒服的。
5. 省时省工：截止2004年底，GBDP技术体系在数据应用开发方面，比现有任何一种编
程模式节省30%以上的总开发时间，50%以上的代码，80%以上的后期开发和维护工作
量，不服气的可以挑战，输了我请客。
6. 技术悖逆传统：GBDP采用常人认为大逆不道的"显示和逻辑合一"的方法, "见山是
山，见水是水", "心物合一", 正因如此, 才拥有任“需求”四海遨游的能力。
我的一个朋友曾感叹，“采用GBDP，美工把页面做好了，整个开发也就快完成了”。
对于用各种“专业理论”来反驳GBDP技术的朋友，我只说一句：“不要学抱着老外
大腿耍嘴皮子的阿扁，擂台上见，你用爱国者打下东风给我看看”。顺便提一句：
J2EE不是想象的那么美好，中国人有足够好的东西，只是缺乏成功登上舞台的一些因素。
GBDP现状及未来展望:
0. 目前是第四代版本，已经成为成熟的商业应用体系，基本实现了目前流行的其他各
种应用编程模式的优势技术，并独具需求随动特色
1. 在已经展开研发的第五代版本中，将引入搜索引擎的技术特征和初步的人工智能，
支持超海量数据应用，性能和速度也将达到一个新的台阶；完善分布式处理，完善
非数据库技术；加强LINUX平台的支持。
2. 未来的第六代版本中，
a)支持手机、穿戴式植入式电脑等移动端版本，适应未来没有PC的“任我行”时代；
白领坐在电脑前工作的时代将一去不返
b)超轻量应用，替代目前80%的应用，无数据库，无安装，蚂蚁也能拖石子
c)成熟的超海量数据应用和初步模仿人类思考分析的智能应用
由《心塔工作窒》出品，采用了GBDP v4.x 第四代软件开发技术体系
(用于取代J2EE，由刘涛自主研发，为完成传统开发中“Impossible Mission”
[不可能的任务]而创立)包含了需求随动、微对象、数据库无关、高速访问缓存
和数据库连接池、对象池、加密、管理及备份轻量自动化、FLASH多媒体界面表达、
等独创和国际一流的新技术， 代码量远少于传统编程（不到50%），跨平台，跨开
发模式，且容易实现软件的大工业化流水线式生产。
目前出现的新技术中，有许多快速开发和高度模块化的技术体系，GBDP技术
体系除了继承这些优点，而且针对需求不明、需求极度变化的残酷国情，大胆的
进行开发理念的革新，扬弃了许多人认为是"祖宗之法"的金包袱，使“需求随动”
开发成为了可能，开发者可以逐次逼近的办法来迎合客户的苛刻甚至无理要求，
而这在过去几乎是不可能的任务。首创了中国特色的“作坊也能流水线”模式。
在需求频繁变动的情况下，自动调整，仅少量修改即可以满足要求，这是传统
软件工程体系（相当于歼6，米格15）无法逾越的鸿沟 ，实现了PYW（Play as You
Want ）的理想；模块强壮，几乎不出现错误，最多局限在业务逻辑错误上 ，特别
适合于中国需求不定、软件开发无序化的现实国情；实现一种技术体系，一套代码，
无须改动，覆盖单机、CS、BS的统一架构 ，无须人工建数据表，不用关心表结构、
字段、值，数据保存更新全部自动化，代码量小。
如果是非GBDP的传统开发方法，您可以想象一下当整个项目完成后，客户希望
增加N个字段，业务逻辑要根据市场变化重新调整，全然不体会程序员“望山跑死马”
的悲惨。此时管理者的办法是炸堤泄洪，而程序员这些苦菜花们则是凄凉的把加班
进行到底；然后就是扯皮、程序错误等等。
学习移交简单，曾经转交一个采用了GBDP技术的项目给同事 ，只花费了一个
下午。实用实效，小米步枪和飞机大炮的完美结合。开创了大型电子商务 、电子
政务和中小型企业运营及管理的统一技术时代 ，是软件新技术中的快速反应部队
和空中突击师。曾经就某个项目模块和同行打赌，运用GBDP技术在1.5天轻松完成了
其他开发者2.5天的工作量，而且运行稳定，几乎没有错误。
GBDP技术最大的特点是“需求随动”，开发灵活，统一了单机、CS、BS的开发
架构，使用相同源码。制作电子商务动态网站仅仅是它的一个用途，完全可以实现
ERP、财务软件、物流等大型软件的架构。
GBDP技术体系演示网站：
http://www.universecommerce.com
GBDP介绍和演示，欢迎摆擂和挑战，输了请客 :)
安全交流区 (可防范网络监控)
http://www.universecommerce.com/com/chenfg/gbdp/safe_chat.jsp
作者： 刘涛@深圳.中国
E-mail: NewTower@tom.com , NewTower@sohu.com , 72049005@51uc.com
Mobile: 13613086264
UC: 72049005 (离线，常查)
QQ: 30234923 (离线，常查)
声明： 作者希望专利化GBDP技术体系，GBDP本身也在不断发展和提升，愿与有
识之士商讨合作事宜，共同推进中国的软件事业，顺便兜里也能揣点钱，
毕竟有生之年看到共产主义的机会已经比彗星撞地球的机会都小了。
--------------------------------------------------------------------------
--------------------------------------------------------------------------
--------------------------------------------------------------------------
另外的一些文章和大家对GBDP的评价:
标题 猴年马月谈GBDP2004高速编程技术体系 选择自 newtower 的 Blog
关键字 猴年马月谈GBDP2004高速编程技术体系
出处
猴年马月谈GBDP2004高速编程技术体系
2004-07-29
两年前, 我在网上公布了GBDP技术体系的1.0版本（实现了初级的需求随动功能）, 大家给予了很多褒贬不一的评价, 当然贬的多一些, 在这里先谢谢大家。对手是最好的老师, 因为大家的质疑, 才让GBDP技术体系在目前到达了一个全新的水平，目前是4.2版本，实现了微对象、需求随动、高速访问缓存、高速数据库访问、连接池、对象池、客户定制、加密、备份轻量自动化等技术。如果您是第一次听说这个技术体系，那么我再简单的介绍一下：
GBDP：通用黑盒动态编程法 General Blackbox Dynamic Programming , 它不是单纯的一个技术，而是诸多优秀技术和中国现实国情结合成的一个技术开发体系，个人认为按照这个趋势发展下去，未来GBDP也许会把J2EE挤出历史舞台，这样说狂妄了点，可我私下里认为J2EE还不如GBDP，因为J2EE的目标是分布式的企业级业务处理（通俗的说，就是把技术难点转包给J2EE，回扣高了点:) ），而GBDP的目标是开发人员可以端着咖啡笑看客户肆无忌惮的更改需求，树立软件公司“白发渔樵，青山依旧，几度夕阳”的风范。
GBDP目标：统一的代码风格，最短的开发时间，最少的代码，低廉的维护和管理成本，工厂流水式的开发模式，允许客户任意的变更需求（:)当然要多给点钱），允许逐次逼近的需求实现，项目交接简单，学习快速。
GBDP特点：需求随动（通俗点说，就是软件做得差不多后，客户想不给加班费就要你改程序），统一了单机、CS、BS的开发架构，使用相同源码。制作电子商务动态网站仅仅是它的一个用途，完全可以实现 ERP、财务软件、物流等大型软件的架构。自动建表，自动增删改记录，自动文件上传，自动事务处理，简单业务无须数据库，自动数据库备份。（不要误认为GBDP是一个MIS系统）
下面回答一些大家的典型疑惑：
疑惑1. 我们已经实现了一个,功能好象更强大, 但是只用于"列表,增加,修改,删除'的共用类
答：GBDP是一个技术开发体系，“自动列表,增加,修改,删除”只是其中的部分子技术，GBDP的核心是通过微对象的方式标准化、弱化“系统分析建模”，来实现需求随动的目的。
疑惑2. 排错太难了，要谨慎使用
答：因为没有接触过GBDP，当然难。到现在为止，我还不会种稻子呢，种稻太难了。顺便问一句，你的电脑主板坏了，是自己用万用表、烙铁修的吗？
疑惑3. 中国不缺程序员... 但严重缺高素质的项目管理人员...
答：非常赞同，这就是中国国情之一，但少了几个字，准确的说应该是，“目前发展水平的中国缺乏高素质的项目管理人员呆的地方”，君不见多少中国瘸驴到了国外后就被追认为“千里马”（呵呵，因为外国人IQ不如我们）。话又说回来，如果每个士兵都手持激光枪，坐着飞碟，即使将军政委都是二奶奶的上小学的女儿的有钱男朋友的被老师罚站的同班同学马仔，去扫黄打非、收复台湾还是没有问题的。
疑惑4. GBDP本质就是将业务逻辑封装在代码中，殊不知这样会产生严重的问题。首先，采用这一方法目的就是简化系统设计，提高系统的自适应能力。但是当后台数据存储接口相当简单(简陋)的时候，其与业务逻辑处理层的交互就必然变得复杂化。这是有控制论理论基础的，这方面的内容又是另一个话题了。通俗的说就是这样一个问题：面对相同的物理存储结构，如果要实现新的功能，除了重新编码，还有什么别的方法吗？但这显然违背了这一开发方法的声明：代码基本不动的自适应能力。以你的示例为例，假如我在你写完这些代码以后提出新的需求：保存时将原来的状况保存下来，这样我就知道对这个意见，前后有过几次反复。在这种情况下，以前的代码是采用替换策略的，新的需求确是要求采用累加策略。不改代码，你怎么做？当然这个问题如果用触发器的话的确可以不改代码。可惜采用你的开发方法的前提就是不用修改数据库设置。其次，简单的数据存储格式必然使数据的逻辑意义变得模糊。从直觉上讲，这样的数据对不确定的数据需求适应性是比较强一些。但这里面隐藏了一个问题，再简单的数据存储格式最后都要以用户能理解的方式呈现在用户面前。而所谓用户能理解的方式就是数据的表现形式是用户能理解的。这里面就有一个转换的过程。当需求发生变化时，也就是用户要求的数据表现形式发生变化时，这个转换过程肯定也要发生变化。如果没有准确而详细的设计文档，而数据存储结构又不能提供现有的数据表现形式，作为程序员该如何下手呢？至于这样的数据结构对性能的极大损害，不能充分利用数据库性能等问题我都懒的说了。总是这些话是要提醒大家，寄希望于通过简化系统的某一部分的设计来达到简化整个系统不仅是不现实的，相反是极端错误的。原因就在于本来可以将一个复杂的问题拆成两个简单的问题的方法放弃，非要找一种可以一次性解决的方法，而且还自以为找到了。
答：非常谢谢这位同行的质疑，能够击到要害，绝对是身经百战的高手，在下先拱手致敬。此话道出了所有专业同行的疑惑。GBDP的设计思路和传统编程的多层结构思路（形神分离，也就是脸上一套，肚子里一套）是不同的，GBDP反其道而行之，采用“形神合一，一招致敌”的战略（本质也是多层结构，但多层实现于标准模块中），从而达到需求随动的效果，当然会有性能损失，但也不是这位同行说的如此不济；非常搞笑的是，在数次和一些同事的编程擂台打赌中，GBDP的运行性能反而超过了“传统编程”方式，仔细研究后发现是对方“传统编程”中优化做得不够造成的，因为需求变动后，优化也要变动，否则性能不高；而GBDP的优化是直接做在模块中，是自动优化的，在GBDP高速数据库访问技术（GBDP技术体系中的子技术）的支持下，如果不是高水平的系统分析员设计的数据模型，在运行性能上反而会输给GBDP。我曾经做过的实验是10万条记录，MSSQL（GBDP数据表中实际是100多万条微对象记录）, 非缓冲的复杂查询(含5个查询条件和in子查询)可以在2~9秒内完成，如果是ORACLE，还可以更快，更加不用说开启GBDP缓存后的运行如飞。（不要告诉我，你的几百万记录1~2秒就可以查出结果来，那是数据库内部的缓冲造成的幻觉，也是商业数据库的卖点之一，首次查询或者修改对应记录后就没有这么快了）
所以我不想单纯讨论“一汽解放、东风重卡”和“帕杰罗SPORT、陆地巡洋舰（GBDP可比拟成帕杰罗）”的性能比较问题，个人认为专业术语和专业理论是市场部人员说给外行客户听的，武林高手过招会去殚精竭虑"出十八罗汉拳"还是"扫螳螂腿"吗？GBDP辉煌在擂台和战场，不是国际大专辩论会上。我只有一句回答，“GBDP从战场归来”。GBDP已经成功的拿下了一个深沪两地软件公司开发失败的例子(海量数据、逻辑复杂、需求常变)，详见 http://www.universecommerce.com
GBDP的配置会和J2EE一样复杂吗？如何运行GBDP代码呢？刚好相反，非常简单, 普通配置好resin等后, 把模块化的jsp文件和java文件放到相应的目录，然后建立一个空的数据库, 配置好连接, 修改dbName的值后, 就可以运行了, 连接池、数据表和记录什么的都会自动配置和建立的, 不用操心了。
疑惑5. 需求是不稳定的，那么需求之中是不是没有稳定的东西呢？有的，就是对象。世界都是由对象组成的，而对象都是持久的，例如动物、植物已经有相当长的时间。虽然对象也在变化，动物，植物也在不断的进化。但对象在一个相当长的时期内都存在，动植物的存在时间肯定比任何一家企业长久。面向对象的开发方法的精髓就是从企业的不稳定需求中分析出企业的稳定对象，以企业对象为基础来组织需求、构架系统。这样得出的系统就会比传统的系统要稳定得多，因为企业的模式一旦变化，只需要将稳定的企业对象重新组织就行了。这种开发的方法就被称为OOAD（Object Orient Analysis & Design 面向对象的分析和设计），而分析出的企业对象就被称为Common Business Object。 （需求的实践——林星 ）
答：本人不敢苟同这个原创于老外的理论，OOAD也许在国外是一种最优的选择，因为老外做事可能比中国人规矩，所以他们的“对象”持久，你看看麦当劳等外企的管理就知道了。但在中国呢？有多少人是按规矩办事的？你知道中国的ERP实施成功率是多少吗，你可以参照那个只养了两只王八（而且现在还健在）却一直生产鳖精口服液的企业的产品的有效成分的含量。在现在的社会，至少在中国，对象是不稳定的，不信？我给你个对象，你给我OOAD了：“美女”，她的心思、她的男友、她的衣服、她的首饰、她的化妆品...... ，一个美女身边N个男人，每个男人身边N个女人，现在你把这个美女给我持久对象化试试看 :)
综述回答：
每个提出疑问的朋友都没有重视或者回避了一个问题，就是目前困扰中国软件开发人员的一个最大心病：需求不确定。如同雷达上的F22或者女人的心思，高度模糊且高度机动。如同我们迷失在好莱坞大片的优秀特技中一样，忽视了内容和思想的干瘪。J2EE、XXX.net这些技术迷宫让我们忘记了“科技以人为本”，软件是为人服务的的宗旨。本来可以几百K就搞定的无须安装的软件采用“新技术”后，不但要几十兆的安装，而且配置麻烦。我们在指责中国企业管理不好无法实施ERP的同时，为什么不反省自己的ERP软件和时代的脱节，为什么不开发一个适合中国国情的ERP？（当然开发出来后就不是现在意义的ERP了）
我们往往要求客户必须提供确定的需要报告，但在实际中客户往往不了解自己的应用，他们要求的是能否先做个大概样板，然后逐步的修改完善，也就是“苏27膏药开发模式”，这是目前的编程开发体系“需求确立式开发”难以应对的，但是GBDP可以满足此苛刻的要求。相信我的同行们都和我有同样的感受，没有解决不了的技术问题，只有应付不起的客户需求。所以，GBDP诞生了。GBDP是一个专门为“需求渐进式开发”而设计的体系，它在不断的吸取各种技术的精华来实现程序员端着咖啡工作的梦想。
如果您要问技术的最高境界是什么？Philips已经回答过了：“简单”
作者： 刘涛@深圳.中国
E-mail: NewTower@tom.com , NewTower@sohu.com , 72049005@51uc.com
Mobile: 13613086264
UC: 72049005 (发离线消息，经常查)
QQ: 30234923 (发离线消息，经常查)
作者Blog：http://blog.csdn.net/newtower/
相关文章
--------------------------------------------------------------------------
一种新的编程思路（下）：GBDP，"面向需求"的编程方法
难得糊涂编程法 GBDP （适用jsp、asp等编程）
在"上"和"中"里面，我已经发布了源代码，现在已经推出了最新的
GBDP2002版本,如果谁有兴趣可以向我索取完整的2002打包，
一个运用GBDP2002实现BBS的范例
包括我jsp、数据库编程的一些经验积累
newtower@163.net qq_30234923
用GBDP实现BBS的范例说明:
平台使用了MSSQL SERVER, Resin
在WEB-INF目录下需要添加web.xml 用来显示在线人数
数据库表将在你运行页面的时候自动建立,不用费心,
你只需要定义好连接参数就可以了
所需要的文件都在压缩包里,自己找吧
我发展GBDP技术的原因是想创建一种新的编程体系结构，用“面向需求”
的方法取代现在的“面向对象”。GBDP简单灵活强大，但不好理解，因为
它太灵活了。我的软件开发同事承认我运用GBDP的实现代码非常短，而且
几乎没有详细系统设计的过程，不用关心数据库的设计等很多优点；
但怀疑它是否能实现复杂的功能，还有运行速度。我用事实证明了功能
的强大和不低的统计查询速度（百万记录级测试），但他们还是不愿意采用，
因为需要时间去理解，并且要把“面向对象”的旧思维转换到“面向需求”
并不容易。老板就更不会采用我的GBDP了，因为采用新方法的风险很高，
况且又不用他自己维护程序（相信每个维护过别人程序的人都有到健身室
打沙包的强烈欲望）
我把软件开发划分为3个时代：
--面向过程（过去）、
--面向对象（现在）、
--面向需求（未来）
过去的东西就不浪费时间了，面向对象的方法是我们现在编程的主要
方法。一般的实际工作流程是：确定需求、系统设计、编码、测试、维护。
其中确定需求和系统设计最具重要性，你可以从开发人员和维护人员的
抱怨、骂街中了解和体会。需求确定后，核心就是在系统设计阶段构造模拟
现实的对象模型，并根据这个模型设计数据库等等。
这种方法，有点美国的M16步枪的风格，在风和日丽的环境中，
射击精度高,如果地球像个温室的话。
但有一个致命伤，就是当需求变动的时候，恶心、偏头痛、神经
衰弱就成了程序员的常见病，尤其是中国的客户经常喜欢节外生枝的告诉你
新的想法和规划，没有人负责，没有人知道全局应该是怎样，反正告诉你了
就得做,这就是国情。我希望自己的作品能够让更多的人可以偷懒的完成工作
任务,就像我国的5.8毫米枪族,风霜雨雪春夏秋冬照样吐火舌.
当然理解我的方法需要一些时间，但你会发现这些时间是值得的，我
没有时间给你写太多的使用说明，希望你多看看我的代码,从项目中学习;
这也是本土风格，尽管不好。等你弄通了GBDP的精髓，你会发现jsp,asp
编程竟隐藏有如此诱人的魅力。
我用C++BUILDER开发过财务软件，用EJB+ORACLE做过分销系统, 给美国
Brio公司解决过他们自己的工程师解决不了的软件BUG；但jsp，用它开发项目
最随心所欲，可以发挥你的灵感和创造，方便快捷实用通用。
在目前我所遇见的项目中,还没有发现用GBDP技术实现不了的。
为了验证它的性能,我打算有空了用GBDP技术开发一个"靓女资源计划"
BRP, 相信难度不亚于"企业资源计划"ERP :)
---------------------------------------------------------
GBDP技术实现设想：（General Blackbox Dynamic Programming）
开发速度快、代码量少、通用，数据库表自动生成，记录自动增加，
修改，删除，系统设计工作量少，可以在需求不明确的情况下开工，
渐进式开发，拥有需求频繁更改、代码基本不动的自适应能力。特
别适合国内软件乱序开发的国情
主要解决问题：
系统设计工作量大，需求更改影响大，项目交接困难，编程风格各
异，数据库备份困难的问题
已经实现功能：
数据表自动生成，记录自动增加，修改，删除，自动文件上传
注：发表后代码／／都变成了file:／／ , 请改正
版权声明：CSDN是本Blog托管服务提供商。如本文牵涉版权问题，CSDN不承担相关责任，请版权拥有者直接与文章作者联系解决。
newtower ( 2002-07-17 )
需要指出的是，在大型项目开发中
80%以上业务实现是简单的，只有不到20%是复杂的
另外GBDP适合于jsp,asp，不适合Delphi,C++类的编程，
站在Delphi,C++的角度,GBDP就一无是处了，但GBDP是针对JSP，ASP的
如果你真正用GBDP写过东西，你才能体会到它的好处，特别是改动需求的时候
用项目开发理论来论证GBDP的优缺点是没有意义的，因为我已经实现了相当复杂的项目（为了和同事打赌），
而且我参与开发过财务软件和ERP
套用刘华清的话，不唯上，不唯书，只唯实
gems ( 2002-07-16)
知道了吧？
功能需求是不稳定的，只有对象才是稳定的，你不用面向对象，却去所谓的面向需求（实际上是功能）。
你认为你已经解决了的问题，实际上就是你即将遇到的问题。
gems ( 2002-07-16)
面向对象、面向过程与面向需求在分类学上是不同的，面向对象、面向过程是不同的软件开发方法论，是对现实世界以不同的方法进行抽象和描述，这一切都是为了实现需求，现代软件工程是以需求为中心的——需求驱动，无论面向对象方法还是面向过程方法，都与这一点不矛盾。
你提的GBDP其实应该是一种较为灵活的架构，实现乃是以功能为核心，抽象出若干功能组件，通过功能组件的组合来实现系统，架构本身并未考虑非功能需求，因此其缺陷也是显而易见的：
1。性能：单一的数据库结构，将本应一次完成的数据库操作分散为若干次操作，难以满足大型系统的需求。
2。难以维护：数据与逻辑的紧密耦合使得程序难以读懂和修改，使得变更和维护的工作量加大。
3。实现复杂：简单的数据库结构，必然会带来业务逻辑实现上的复杂性。
可见其并不适用于大型软件的开发。
至于所说的什么面向需求简直就是胡说八道了，作者肯定没有做过大型项目，不然不至于对需求有这种理解。
顺便摘抄一段文字让你看看：
需求是不稳定的，那么需求之中是不是没有稳定的东西呢？有的，就是对象。世界都是由对象组成的，而对象都是持久的，例如动物、植物已经有相当长的时间。虽然对象也在变化，动物，植物也在不断的进化。但对象在一个相当长的时期内都存在，动植物的存在时间肯定比任何一家企业长久。面向对象的开发方法的精髓就是从企业的不稳定需求中分析出企业的稳定对象，以企业对象为基础来组织需求、构架系统。这样得出的系统就会比传统的系统要稳定得多，因为企业的模式一旦变化，只需要将稳定的企业对象重新组织就行了。这种开发的方法就被称为OOAD（Object Orient Analysis & Design 面向对象的分析和设计），而分析出的企业对象就被称为Common Business Object。 （需求的实践——林星 ）
ketao_78 ( 2002-07-16)
什么东西
-----------------------------------------------------------------------------------------------
如果您耐心的看完了这篇文章，那么非常感谢，送您下面的小故事；GBDP并非什么革命性的技术，如同下面的鸡蛋
哥伦布竖鸡蛋
为了庆祝哥伦布发现美洲新大陆，西班牙女王在王宫里举行了盛大宴会。许多达官贵人纷纷前往向哥伦布祝贺。
一位朋友看到大家如此看重哥伦布，很不服气，就对哥伦布说：“这有什么了不起的，大陆本来就在那里，不过被你碰上罢了。”
哥伦布笑了笑，随后从茶盘里拿起一个鸡蛋，让这位朋友把它竖在桌子上。这位朋友拿着鸡蛋左摆弄，右摆弄，急得满头大汗也立不起来。
哥伦布把鸡蛋往桌子上磕，鸡蛋底部碰碎了，鸡蛋竖了起来。他说道：“许多事情看起来很简单，问题在于有人发现了，想到了，有人却没发现或没想到，就差这么一点儿。”
| -ICP -IDC -ISP |