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 结构的应
用渐渐地开始消失，除非在客户端存在较大的运算、逻辑或对计算环境的控制。


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

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

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

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

这其中的原因是，在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

下一节--->>