`
javasee
  • 浏览: 965499 次
  • 性别: Icon_minigender_1
  • 来自: 北京
文章分类
社区版块
存档分类
最新评论

VCL已死,RAD已死(3)

阅读更多

VCL已死,RAD已死


——SD2C中未能尽言的话题 <<<-- 上一节 三、RAD之死与系统的复杂性 ----- RAD在较小规模应用的开发上,具有相当的优势。同时,它具有两方面特性: 1、对于应付在各个模向分层上需求相对均势,并且在开发工具商提供的方案可应付的区间的需 求,RAD以及使用RAD开发的团队具有极大的能量。例如早期的C/S模式下的数据库应用。 2、对于系统可以纵向切分(为多个子项目或独立模块),而且各个块满足上述第一项的特性时, RAD应付规模增长的系统时,也具有极大的能量。例如群件、或中间件等。 对于上述两个特性之外的系统,RAD的团队难于组织、管理,也难于复制。显然,RAD对个体特性 的要求过高,不利于团队的成长。大公司的高人们,难道真的没有看到这一点么? 不是,他们看到了。VS.NET开始把产品做成产品线,发布开发产品的不同版本:设计师的、架构 师的、测试工程师的……等等这些。与此相同的,各家都开始这样切分产品。但是相同的产品线 名称迷茫了开发人员:大多数时候,我们要么选用不分这种版本的早期产品,要么选用这种产品 的最完整版本。而后者,正是大公司的销售经理最喜闻乐见的,他们会相互吹嘘自己买出去多少 个Site Suite版本,并同时拿Web Devleper版本的业绩来开涮。同时,大产商也不会无视市场的 价格而鼓吹单一版本,因为那样的结果是:“网页制作应该用macromedia的”、“图形设计应该 用adobe的”、“数据库得选Oracle的”、“服务器最好用Linux便宜”…… 拆开来买的“大”产品,虽然不至于一文不值,但至少没大产品值价。这个与传统产品不同,其 根源在于开发工具的“大”产品没几家做得出来,而“精”却很多人能做得到。大公司可不会为 了理论上的正确性而无视于市场盈利。 所以大厂商对RAD工具的细分其实只是假象,用来说明他们的工具足够牛足够大和足够好的一个 旁证。这些“细分”的背后是极强的相互依赖性,结果是:整个解决方案还是一家独大。 我认为,系统的复杂性需要横向的切分来分解。因为横向的切分产生的是领域,与之对应的,就 是不同领域、产业的力量,而非某个个人或团队或公司的力量。不同领域、产业带来的,是整体 性的推动,而不是某个个体的畸形发展。同样的,他也带来了个体品质的提升,例如有了最好的 砖瓦匠和水电工,也带来了在更高分层上独立思考的可能性,例如建筑师与城市规划设计师。 当然,我相信很多人认为自己拎上一把锤头就可以做水电工——我前两天在CSDN论坛里就看到了 这样的观点,我也相信很多人认为建筑师与城市规划设计师都是饭桶,他们存在的目的仅仅是就 业安置或者消耗粮食。我完全相信这种观点的存在,但不同意它。我曾经做过电工,我知道用一 把锤头敲击就听出设备的好坏是需要10年以上的功夫的;我也知道如果没有规划师,城市会比现 在更乱而不是更好。 你可以批评别人做得不够好,但把你放在相同的位置上,你未必做得更好。这与横向分层理论带 来的效果是一样的,你可以认为自己能做好所有层次上的工作,但你真要去做的时候,却未必做 得到。以及,由于你——这个个体不能被拆分,所以你的工作是串行的、效率是有限的,结论正 是:在这样的思想下,大的系统会越做越糟糕。 横向分层带来的结果要变成良性的,就必然是相信每个层面上有相“匹配”的人员。你要信任它, 并主动合作,你要相信团队是一个多层结构,相信团队中的其它人会给你帮助,以及需要你的帮 助。你做不到一切,你依赖于别人而达到你的成功。 同样的,你也必须认识到:没有任何一个团队一开始就是这样的。团队需要清理,需要沉淀。需 要花费一些成本来建立沟通,并逐渐形成合作的模式、默契。当然,另一种更加不错的方式是: 整个教育和培训行业相信这一点,在程序员走向商业产品开发之前就培养他们的团队组织与协作 能力,从习惯于服从和配合,到学会观察与学习,以及在团队中如何自我提升。等等这些,才是 我们传统行业——例如我们常常提及到的建筑行业中的职业进化模式。 产业的、领域的推动才会解决系统复杂性的问题,而不是某一个或几个大公司在他们各自有限的 领域中折腾。他们折腾的目的、根本只是为了商业利益,而不是为了解决问题。 下一节(插播下下) -->>> 第四节 后RAD时代:界面可视,到界面可描述 -->>>


  


  
分享到:
评论

相关推荐

Global site tag (gtag.js) - Google Analytics