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


VCL已死,RAD已死

——SD2C中未能尽言的话题


<<<-- 上一节



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

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

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

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

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

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




 
 
 
 
评论 16
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值