我的架构思想(四十七):附录 1

阅读数:25 2019 年 10 月 16 日 15:05

我的架构思想(四十七):附录 1

附一:做人、做事,做架构师——架构师能力模型解析

节选自《程序员》杂志 2008 年第 4 期同名文章。

架构是一个从全局到局部的过程,而实施正好反过来,是从局部到全局。这也正是“设计做大,实施做小”的另一个层面的含义。“设计大”才可以见到全局,才知道此全局对彼全局的影响;“实施小”才可能关注细节,才谈得上品质与控制。

事实上,大多数情况下架构是在为“当前项目之外”去考虑,这可以看成全局关注的一个组成部分。因此我们需要界定所谓“全局”的范围:若超出公司或整个产品系列、产品线或产品规划的范围,则是多余的。所以当架构决策谈及“全局”时,其目标并不见得是“保障当前项目”,而又必须由当前项目去完成。1

1 通常这是指系统架构的一部分工作,但一些技术架构可能也需要这样的全局眼光才能正确决策。

一个经常被用到的例子是:如果仅为当前项目考虑,那么只需要做成 DLL 模块;如果为产品线考虑,可能会是“管道+插件”的结构形式。而“管道+插件”的形式显然比做成 DLL 模块更费时,这个时间成本(以及其他成本)就变成了当前项目的无谓开销。

这种全局策略对局部计划的影响是大多数公司不能忍受的,也被很多团队所垢病。然而这却是架构师角色对体系的“近乎必然”的影响——如果你试图在体系中引入架构师这个角色的话。一些情况下,体系能够容纳这种影响,例如“技术架构师”试图推动某种插件框架,而正好开发人员对这项技术感兴趣,那就顺其自然地花点工夫去实现了。但如果实施者或实施团队看不到“多余的部分”对他们的价值,来自局部的抵触就产生了。

这种情况下,平衡这些抵触就成了架构推行的实务之一。在我看来,“平衡”是全局的艺术和局部的技术。也就是说,一方面架构师要学会游说,另一方面也要寻求更为简洁的、成本更小的实现技术。只有当整个体系都意识到(你所推行的)架构的重要性,而且实施成本在他们可以接受的范围之内时,他们才会积极行动起来。

所以所谓平衡,其实也是折衷的过程。构架师只有眼中见大,才知道哪些折衷可以做,而哪些不能。所谓设计评估(模型图2中的实现能力→设计能力→设计评估分支)并不是去分析一个设计结果好或不好,而是从中看到原始的需求,看到体系全局的意图,然后知道在将设计变得更为“适当”时可以做哪些折衷。同样的原因,架构师也必须知道自己的决策会产生的影响,才能控制它们,以防它们变成团队的灾难。有些时候,架构师甚至需要抛弃一些特性,以使得项目能够持续下去,因为产品的阶段性产出只是整个战略中的一个环节,而不是全部。

2 这里的模型图是指与本篇文章同时发表的一个“架构师能力模型”,并非本书中所论的模型。该模型可参阅《程序员》杂志中的原文或我的个人博客。

评论

发布