猴年马月谈GBDP2004高速编程技术体系

猴年马月谈GBDP2004高速编程技术体系

2004-12-02

GBDP 技术演示网站：
http://www.universecommerce.com
　　　　　　　　　　　
GBDP　is　a　new　software　developing　system.　It's　simple,　efficient　
and　powerful.　The　terminator　of　J2EE.　

　　两年前, 我在网上公布了GBDP技术体系的1.0版本（实现了初级的需求随动功能，不足以商业应用）, 大家给予了很多褒贬不一的评价, 当然贬的多一些, 在这里先谢谢大家。对手是最好的老师, 因为大家的质疑, 才让GBDP技术体系在目前到达了一个全新的水平，目前是4.0版本，实现了微对象、需求随动、高速访问缓存、高速数据库访问、连接池、对象池、客户定制、加密等细节技术。如果您是第一次听说这个技术体系，那么我再简单的介绍一下：


　　GBDP：通用黑盒动态编程法 General Blackbox Dynamic Programming , 它不是单纯的一个技术，而是诸多优秀技术和中国现实国情结合成的一个技术开发体系，个人认为按照这个趋势发展下去，未来GBDP也许会把J2EE挤出历史舞台，这样说狂妄了点，可我私下里认为J2EE还不如GBDP，因为J2EE的目标是分布式的企业级业务处理（通俗的说，就是把技术难点转包给J2EE，回扣高了点:) ），而GBDP的目标是开发人员可以端着咖啡笑看客户肆无忌惮的更改需求，培养并树立软件公司“白发渔樵，青山依旧，几度夕阳”的风范。

　　GBDP目标：统一的代码风格，最短的开发时间，最少的代码，低廉的维护和管理成本，工厂流水式的开发模式，允许客户任意的变更需求（:)当然要多给点钱），允许逐次逼近的需求实现，项目交接简单，学习快速。

　　GBDP特点：需求随动（通俗点说，就是软件做得差不多后，客户想不给加班费就要你改程序），统一了单机、CS、BS的开发架构，使用相同源码。制作电子商务动态网站仅仅是它的一个用途，完全可以实现
ERP、财务软件、物流等大型软件的架构。自动建表，自动增删改记录，自动文件上传，自动事务处理，简单业务无须数据库，自动数据库备份。（不要误认为GBDP是一个MIS系统）



对软件开发“不很了解”和“了解过头”的朋友，可把GBDP看作应用软件开发中的
李小龙、歼10、空中突击师、东风41、等等

GBDP的市场定位：
1.　蛋糕：“中国特色的ERP”市场 （国外传入的ERP在中国像传销一样水土不服），
　　　　　这是一个巨大的市场，如同没有穿鞋传统的非洲
2.　年糕：“党政军、公检法”市场；（微软通过免费派发摇头丸让你上瘾，然后杀
　　　　　年猪占据的市场），同样一个巨大的市场，但需要培育和耐心，建议看看
　　　　　《曹刿论战》；跟我一起摇啊，铜板叮当响啊
3.　内二外八糕：“盲人骑瞎马”市场；在这里，客户不知道自己具体需要什么，软
　　　　　件开发者也不知道要做成什么；呵呵，这也是商机

GBDP缘起： 诞生有点像J10，本想养了卖的，不料“臭老九”做的太好，结果得宠成了贵“飞”
　　曾几何时，叹2001
　　前有客户发飙，
　　后则老板督阵；
　　加班已，
　　悟人生；
　　GDP，无我份
　　莫学后主甘称臣
　　铸剑惊鸿绝长恨

GBDP的缺点：
0.　在某些情况下，运行性能稍逊色于普通的编程模式
1.　空间消耗大：采用空间换时间、空间换性能、空间换灵活的方法，导致数据存储多
　　占用30%-100%
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不是想象的那么美好，中国人有足够好的东西，只是缺乏成功登上舞台的一些因素。

　　
　　下面回答一些大家的典型疑惑：

　　疑惑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 (离线，常查)