VCL已死，RAD已死(6) - 结语与预测

VCL已死，RAD已死


——SD2C中未能尽言的话题


<<<-- 上一节


六、更远的将来
（有限无责任预测）
－－－－－

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

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

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

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

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

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

==========================

我的一些相关文字的联接：

关于“VCL已死、RAD已死”答读者问
http://blog.csdn.net/aimingoo/archive/2008/12/22/3583348.aspx

VCL已死，RAD已死(插播)
http://blog.csdn.net/aimingoo/archive/2008/12/07/3467787.aspx