VCL已死，RAD已死(3)

三、RAD之死与系统的复杂性
－－－－－
RAD在较小规模应用的开发上，具有相当的优势。同时，它具有两方面特性：

1、对于应付在各个模向分层上需求相对均势，并且在开发工具商提供的方案可应付的区间的需
求，RAD以及使用RAD开发的团队具有极大的能量。例如早期的C/S模式下的数据库应用。

2、对于系统可以纵向切分（为多个子项目或独立模块），而且各个块满足上述第一项的特性时，
RAD应付规模增长的系统时，也具有极大的能量。例如群件、或中间件等。

对于上述两个特性之外的系统，RAD的团队难于组织、管理，也难于复制。显然，RAD对个体特性
的要求过高，不利于团队的成长。大公司的高人们，难道真的没有看到这一点么？

不是，他们看到了。VS.NET开始把产品做成产品线，发布开发产品的不同版本：设计师的、架构
师的、测试工程师的……等等这些。与此相同的，各家都开始这样切分产品。但是相同的产品线
名称迷茫了开发人员：大多数时候，我们要么选用不分这种版本的早期产品，要么选用这种产品
的最完整版本。而后者，正是大公司的销售经理最喜闻乐见的，他们会相互吹嘘自己买出去多少
个Site Suite版本，并同时拿Web Devleper版本的业绩来开涮。同时，大产商也不会无视市场的
价格而鼓吹单一版本，因为那样的结果是：“网页制作应该用macromedia的”、“图形设计应该
用adobe的”、“数据库得选Oracle的”、“服务器最好用Linux便宜”……

拆开来买的“大”产品，虽然不至于一文不值，但至少没大产品值价。这个与传统产品不同，其
根源在于开发工具的“大”产品没几家做得出来，而“精”却很多人能做得到。大公司可不会为
了理论上的正确性而无视于市场盈利。

所以大厂商对RAD工具的细分其实只是假象，用来说明他们的工具足够牛足够大和足够好的一个
旁证。这些“细分”的背后是极强的相互依赖性，结果是：整个解决方案还是一家独大。

我认为，系统的复杂性需要横向的切分来分解。因为横向的切分产生的是领域，与之对应的，就
是不同领域、产业的力量，而非某个个人或团队或公司的力量。不同领域、产业带来的，是整体
性的推动，而不是某个个体的畸形发展。同样的，他也带来了个体品质的提升，例如有了最好的
砖瓦匠和水电工，也带来了在更高分层上独立思考的可能性，例如建筑师与城市规划设计师。

当然，我相信很多人认为自己拎上一把锤头就可以做水电工——我前两天在CSDN论坛里就看到了
这样的观点，我也相信很多人认为建筑师与城市规划设计师都是饭桶，他们存在的目的仅仅是就
业安置或者消耗粮食。我完全相信这种观点的存在，但不同意它。我曾经做过电工，我知道用一
把锤头敲击就听出设备的好坏是需要10年以上的功夫的；我也知道如果没有规划师，城市会比现
在更乱而不是更好。

你可以批评别人做得不够好，但把你放在相同的位置上，你未必做得更好。这与横向分层理论带
来的效果是一样的，你可以认为自己能做好所有层次上的工作，但你真要去做的时候，却未必做
得到。以及，由于你——这个个体不能被拆分，所以你的工作是串行的、效率是有限的，结论正
是：在这样的思想下，大的系统会越做越糟糕。

横向分层带来的结果要变成良性的，就必然是相信每个层面上有相“匹配”的人员。你要信任它，
并主动合作，你要相信团队是一个多层结构，相信团队中的其它人会给你帮助，以及需要你的帮
助。你做不到一切，你依赖于别人而达到你的成功。

同样的，你也必须认识到：没有任何一个团队一开始就是这样的。团队需要清理，需要沉淀。需
要花费一些成本来建立沟通，并逐渐形成合作的模式、默契。当然，另一种更加不错的方式是：
整个教育和培训行业相信这一点，在程序员走向商业产品开发之前就培养他们的团队组织与协作
能力，从习惯于服从和配合，到学会观察与学习，以及在团队中如何自我提升。等等这些，才是
我们传统行业——例如我们常常提及到的建筑行业中的职业进化模式。

产业的、领域的推动才会解决系统复杂性的问题，而不是某一个或几个大公司在他们各自有限的
领域中折腾。他们折腾的目的、根本只是为了商业利益，而不是为了解决问题。