程序原本（八）：VCL 已死，RAD 已死

编者按：本文节选自周爱民著《程序原本》一书中的部分章节。

VCL 已死，RAD 已死

节选自博客文章“VCL 已死，RAD 已死”（2008 年 12 月），文章从用户界面开始，最终推进到对象系统界面与组织方式的思考。

当浏览器成为普通用户使用计算设备（包括移动的、桌面的、嵌入的等）的首选时，它便隔离了操作系统与 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 等¹更为细化的分层一样。

¹ UC：UI/Client；UCC：UI/Control/Client；NDA：Network/Data/Application。

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

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

我认为可以有颠覆性的思想，但从来不指望颠覆性的变革。所以能同时兼容横向分层的后 RAD 时代是漫长的，不过即使是三两年，我想，在 IT 业来说，也算得上是漫长的了。

再接下来，更为迎合这种面向领域组织团队并开发的工具便会出现。但这种工具不再期望整合各个领域的实现技术（注意我不是说“开发技术”），而是提供领域间的交付标准，或者更为直接地提供交付物。更多领域专精的公司受到关注（例如现在的 Macromedia），大厂商开始并购更多的专属领域的公司，以整合他们的业务。更大的平台化产品会出现，远程的、分布的、可迁移的运算理论和解决方案被普及；而与此同时，更细分的领域带来了更多的专属工具和专精人才；项目的整体规模扩张，并由多个团队来实现（像工程的包工队一样）；而单一团队中人员结构更为复杂，但团队规模仍然被保持在 10 人以内，以 15~20 人为上限。类似于测试等技术，将会作为领域而出现，类似于现在建筑业的工程验收与监理也会出现。这些专属领域仍然有它独特的标准、技术与工具，并提供独立的交付物。

对于整个工程来说，RAD 彻底死掉了。也许类似于建筑行业中的沙盘/模型制作公司会出现，并成为产品过程中的一环，但再也没有了在多个横向切分层面上贯通的 RAD 工具。基于原型理论的 RAD 过程，以及迭代的 RUP 会慢慢地退出去。因为如同没有人能够提供一个楼房建筑的迭代过程一样，工程的复杂性已经让人远远不能控制单次迭代的成本。在这种规模级别之下，对层间界面的控制决定了系统的稳定性，以及能否持续开发。因此架构师在全程成为必须，而且架构的职责将更为细分，例如精密到一个数据 IO 界面，可能都需要特定的架构师来确认和论证。同样地，局部的失败或失效将在系统的更早时间内被发现和验证，返工在局部成为常态，但在全程却不复存在——或直接地让整个工程失败掉。

工程越来越依赖于经验，以及由经验带来的技术模型。例如我常常提及的塔楼式建筑，并不是某个工程学家或领域专家头脑风暴的产物，而是在实践中总结的经验。工程的可复制性增强，而复制规模和环境则更趋简单（过于复杂的规则与界面是难于复制的），这一切依赖于横向分层的界面上的简洁性。

模块的复用与重构依然会长期存在，绝不会消亡。更细的复用粒度必然从现在的对象扩展到业务组件复用，但本质上仍然是以无业务逻辑存在的基础对象复用为前提。用户界面（UI）作为组件将会在很长的历史上出现、消亡与重现；更多的层间界面（interface）将以协议标准的形式出现。而在各自独立的层上，基于层间界面的逻辑组件将成批地涌现，“数据”仍然是它们的唯一约束与编程本质。

我们会有对计算模型的新的尝试，但本质仍与如今一致。函数式语言将会走向前台，脚本语言成为领域间的粘合剂（尽管现在在某些领域间已是如此），确定的语言将在确定的层次上大放异彩（或这也是领域语言的一个代名词）；同时掌握关联的多个层次上的开发工具的专家，以及领域专长的、与程序无关的专家将成为热门。对于整个体系来说，前者主要是实现具体的业务逻辑，而后者则专注于数据定义。不过，可以想见的是，没有多少人会特定用 XML 来作为这些数据定义的载体，专属的数据格式将是层间交互的首选。

最后，从工程实践的角度上来讲，二十年之内，我想不会出现一本名为《软件工程之营造法式》的书。当然，某些噱头制造者或纸张贩售者的吹嘘除外。

图书简介：https://www.ituring.com.cn/book/2429

相关阅读

程序原本（一）：应用开发基础

程序原本（二）：应用开发技术

程序原本（三）：开发视角下的工程问题

程序原本（四）：系统的基础部件

程序原本（五）：海量数据运算中公开的秘术

程序原本（六）：继承与混合，略谈系 统的构建方式

程序原本（七）：像大师们一样思考