架构师与架构

一位独立的架构师
不应受感性驱使，
而应依靠反思。
——汉斯·沙隆

#key# M. E. 康威：著名的计算机科学家和黑客，开发了协程、UNCOL语言，并参与了Pascal编译器的工作。他在1968年发表于《Datamation》杂志的文章《委员会如何创造？》中提出了康威定律，原文第28页写道：

设计系统的组织，其产出的系统结构必然与其自身的沟通结构一致。

这一规律后来被多位未署名作者进一步拓展，他们通过实践经验总结出以下观点：

• 系统的架构是组织架构的复制品。
• 系统的结构由团队的结构决定。
• 要理解一个团队，只需观察它所开发的软件：如果软件迟缓臃肿，说明团队同样迟缓臃肿；如果软件精简敏捷，说明团队也精简敏捷。

这些经验揭示了非技术因素对架构的深刻影响。然而，还存在另一个关键影响因素，这在尼古拉·约苏蒂斯作为大型关键项目首席架构师的经历中得到了最清晰的表达：

项目的规模，或者说团队的规模，会影响架构的设计。

“架构”一词听起来非常稳固，这可能与敏捷流程的理念相冲突；提及“架构负责人”更会强化这种印象。但真正重要的是找到合适的手段（无论是否传统）来构建一个能够支持后期变更的灵活系统。实现这种灵活性的关键，在于对项目成员的信任，以及架构负责人所承担的重要责任。

架构负责人的职责

在一个典型的敏捷项目中，若团队规模较小，我们往往不会设立专门的架构负责人，因为整个团队成员地位平等，共同承担项目的全部责任。尽管这本应是大型团队的理想目标，但在实际操作中却难以实现——否则开发将失去协调，方向分散。

俗话说得好：“人多手杂，反坏汤。” 当团队人数庞大时，系统中很可能会出现大量不同的概念和想法，而这些想法之间很可能相互矛盾。我们需要的不是多样化的创意，而是概念一致性——这是大型系统最重要的质量特征：

与其让系统包含许多优秀但彼此孤立、缺乏协调的想法，不如让它放弃某些异常特性或改进，而始终体现一套统一的设计理念。

架构负责人正是迈向概念一致性的关键一步。除了提供架构指导外，设立架构负责人还有其他重要原因。通常我们会发现，并非所有团队成员都能以一种有助于团队做出正确决策的方式描述整体蓝图。若缺乏这种全局视野，正如弗雷德·布鲁克斯所说：“在大型团队中，子团队往往会为了达成自身目标而局部优化，而非考虑对用户整体的影响。这种方向上的脱节，是大型项目的主要风险。”

这对项目内外的人都至关重要——架构负责人将成为特定问题的主要对接人。如果没有这样一个核心联系人，大型团队很快就会陷入混乱。根本原因在于，所有成员都难以明确责任归属，也不清楚谁拥有最终决策权。这正是架构负责人的职责所在。因此，他们才是那个“掌控全局”的人。架构负责人还应培训团队成员，例如通过协作帮助他们建立全局视角、培养责任感。因此，架构负责人不仅是关键思想的记忆者，更重要的是思想的传播者，使越来越多的人对系统形成一致的理解。