VCL已死，RAD已死(5)

VCL已死，RAD已死


——SD2C中未能尽言的话题


<<<-- 上一节


五、后RAD时代：领域的成熟
－－－－－
从界面可视，到界面可描述的变化，使UI设计渐已成为一个相对独立领域。UI团队与UED团队之
间并没有严格的、学术性区别，在不同的公司中它们的定义并不一样。一般而言，我们称前者
为参与UI的全体，而UED则更关注于用户体验的这一部分。有些时候，我们也习惯性地称之为
前端开发，或UI开发团队。

在这个领域中有一些明显的特点，例如界面开发过程中采用一种领域设计、开发语言（当然，
XML力图成为“通用的描述语言”，于是便有人力主用XHTML来推翻HTML——这个世界上，有
领域就有跨领域的“通用”）。我们关注一下HTML+CSS带来的描述能力，首先HTML负责了内
容的布局和内容的语义（例如TABLE或IMG），相辅相成的是，CSS则带来了对“上述内容（元
素）”的效果修饰。不太为人知的事实是：CSS早期其实是参考传统排版印刷规范而定义的一
个子集。

所以，事实上HTML+CSS构成了视觉的“版式”与“修饰”。从这个角度上来看，它们是更接近
设计领域的领域语言。而Javascript适时地出现，给HTML+CSS带来了活力，这一切更深层面
地源于DHTML/DOM的出现。这是从文档结构的抽象上来看，HTML可以描述为“内联+块”元素
的集合，前者是块的一个特例。而块的文档结构形式只会有“并列和内嵌”两种，这就是DOM
模型中的Sibling与Parent语义的由来(*注1)。所以，DOM可以用非常简单的概念来描述整个
HTML。同样的，CSS天生具有“属性继承/覆盖”的特性（层叠样式表的本义），它描述的语义
与UI设计中的“效果叠加”是完全对等的。因此，由HTML+CSS天生地更为亲切设计人员，并带
来了以“效果展现”为主体的WEB设计的繁荣。

这个领域进一步地扩大，我们看到了更多的东西，开发人员也通过DOM/DHTML走向了前端的领域。
在过去的十年中，JavaScript大多数时候被作为“一门简单的语言”用在一些入门编程人员出
现的地方：例如网页制作，便被人看作是设计师而非专业程序设计人员的工作。本质上说，这
是“富服务器端”思想的必然产物。在这种思想下，浏览器端是不必有多少编程的——网页制
作人员只需要知道一个按钮上面有一个onclick事件，并可以指向一段（甚至是由其它专业的
开发人员提供的）代码即可。

然而当浏览器演变为“富客户端”时，开发人员侵占了网页制作者们的领地。因为用户不再仅
仅满足于功能，而开始要求更为友好的体验。我们在前面讨论过：效果是美术设计来保证的，
而体验则由前端开发来保证。所以，网页制作者大多数退到网页设计师的战线后面，另一部分
则变节了，也成为了“专业程序设计人员”——感谢上帝赋予了他们既艺术又理性的头脑。

这就是这个领域的起源与结构。

同样的，B/S开始取代C/S。当浏览器成为普通用户使用计算设备时（包括移动的、桌面的、嵌
入的等等）的首选，它便隔离了操作系统与WEB环境下的UI。我们没有在任何地方看到一项要
求说：一个Page必须要有一个跟浏览器Toolbar风格相同的工具条，或跟窗体风格相同的菜单。
本质上来说，是浏览器的便捷与普众，催生了B/S结构下的应用和服务开发。而这样一来，
桌面原生的客户端就不复存在了，C/S渐渐地开始消失——除非在客户端存在较大的运算、逻
辑或对计算环境的控制。

重量级的客户端软件越来越少，因为从根底里来说，人们不喜欢用复杂的软件。领域的边界，
从浏览器编程界面，退缩到网络界面——我的含义是指：B端的开发人员不再要求“能够调用
Win32 API”，而是要求“能够进行网络交互”。而当这一阵线真正的推进到面向socket的二
进制编程时，操作系统就被从这个体系中切割了出去。

Flash Socket，以及HTML5中的HTML Socket带来了这种趋势，这种趋势让微软措不及防。一
方面SliverLight还在为Flash仓促应战，另一方面IE+JScript的结构尚未成完成六年来最大、
最根本的变革（IE8或IE9或IEx）。然而，即使如此，一个如同操作系统一般庞大的WEB的领
域，已然形成。这个领域中，微软仍在第一战线，且树敌良多。

当我们把WEB看着一个象操作系统一样的产品平台，“程序员”便成为产品生成链条中的一环，
程序员文化是被重点考虑的对象，但不是全部。包括平面开发人员等在内设计师、架构师、部
署专家、行业分析人员等在内的团队模型必然会建立。小型的XP团队仍将存在，但这取决于应
付的系统规模，以及在纵向切分上的同质性的多少。

横向切分将出现在浏览器端开发的整个过程中，这不但是指整个UI，还会有UI过程中的各个细
节，例如框架、数据交互、网络界面等等。在这一过程中，纵向切分依然会成为补充。例如说
将网络界面与数据交互并成一个独立的部分，交由Flash socket来实现，或交由独立的comet
兼容层来实现。但更确切地说，横向分层仍会带来更细分领域的繁荣，例如JSON或其它微数据
格式，或其它基于socket或htttp/https进行交互的二进制数据格式成为专门的研究领域。

真实的原因，在WEB客户端（浏览器端、B端）带来的领域必然扩大到一个无法通过纵向切分来
一次性交付的地步，因而必然在这一端出现更细化的横向分层。从经验来看，当一个领域足够
成熟时，就意味着它可以接受横向的分层了，就如现在的桌面作为一个领域，就可以接受UC、
UCC，以及NDA等(*注2)更为细化的分层一样。

横向切分是领域合作的模式，这也导致横向切分与金字塔式的管理模型结合时，会存在多领域
专家汇聚在金字塔顶端的情况。当这种情况出现时，需要更高的决策层来应对——这也意味着
决策层需要更多的经验和能力。当然，我们仍然会失败。因为即使我们把系统先纵后横地切成
网状，我们仍然面临总体规模上的复杂性。同时，管理规模的扩张，也导致我们的成本增加，
周期拉长。

所以，如果你不是做3~5年的规划，或者常常被人垢病的“太空项目”，那么你不需要这样来
考虑一个问题的全集。你需要关注：在某个具体项目中，是否更合适于某些层面的横向分层，
并且有意识地培养该层上的开发人员与相关角色。

我认为可以有颠覆性的思想，但从来不指望颠覆性的变革。所以能同时兼容横向分层的后RAD
时代是漫长的，不过即使是三两年，我想，在IT业来说，也算得是漫长的了。
======================
 *注1：parentNode， nextSibling，previousSibling等属性 *注2：UC：UI/Client；UCC：UI/Control/Client；NDA：Network/Data/Application 

下一节--->>