第18章 每个人都是架构师，除非他们有其他身份

很多软件团队都朝着敏捷和自组织努力，在这种对现代软件开发团队的描述中，软件架构角色如何融入并不是显而易见的。

每个人都是架构师

在Extreme Programming Annealed中，格伦·范德堡（Glenn Vanderburg）讨论了极限编程实践适用的层次，他强调了架构和集体所有制之间的联系。当我们谈论集体所有制时，通常指的是集体拥有代码，以便团队中任何人都有权做出改动。这种方式奏效暗示团队中每个人至少都对“大局”有一些基本的了解。想想你目前的项目，跳转到代码库的任何一部分，你都明白发生了什么吗？

想象一下，如果你有一队经验丰富、能够在大局内外自如切换的软件开发者，一队真正会动手的架构师，这样的团队太棒了，所有通常会跟软件架构联系起来的元素（非功能需求、约束，等等）都会得到解决，不会漏掉任何一样。从技术的角度来看，这就是一个自组织的团队。

除非他们有其他身份

对自组织团队的想法，我有一个大问题，我们在行业中谈论了很多，但很少看到实践。这可能是在咨询的环境中工作的副作用，因为我的团队总是随着项目而变化，而且我不太可能跟某一个客户在一起超过几个月。或者，我怀疑，真正的自组织团队非常少。把自组织作为努力方向是值得尊敬的，但对很多软件团队而言，这就像是还没学会走就想跑了。

在“Notes to a software team leader”中，罗伊·奥谢洛夫（Roy Osherove）描述了他的“弹性领导”概念，这种领导风格需要根据团队的成熟度有所变化。罗伊用一个简单的模型对团队成熟度做了分类，每个等级需要不同的领导风格。

(1) 生存型（混乱）：需要一种直接指挥和控制的领导风格。

(2) 学习型：需要一种指导的领导风格。

(3) 自组织型：需要简易化来确保平衡不受影响。

就像我说的，团队里每个人都是经验丰富的软件开发者和架构师，那就太棒了，但我还没见过这样的团队。大多数项目的团队连一个对“大局”之类的东西有经验的人都没有，一团乱的代码库、不明确的设计、很慢的系统，类似这些都是明证。从技术角度来看，这种情况最为多见，我建议团队中由一个人来承担软件架构角色的责任。

罗伊举了流程经理角色的例子。在成熟的初始阶段，一个人承担流程经理的角色来帮助团队向正确方向前进，这将使团队受益。另一方面，自组织团队不需要别人告诉他们做什么。名字就是线索；从定义上，他们是自组织的，可以自己承担这个角色。我想说，软件架构的角色是同样的，因此技术领导的角色也是。

敏捷需要架构吗

可惜，许多团队把“大局”上的技术技能看作一种不必要的邪恶，而不是重要的补充，可能是因为他们过去深受大型预先设计之害。有些人也过于渴望“敏捷”，以至于忽略软件开发流程的其他方面。接踵而至的是混乱而非自组织，这样的团队也面临着需要更直接的领导方式的挑战。毕竟，他们在努力变得敏捷。单个点负责项目的技术层面，也跟他们对敏捷团队的想象相冲突。这种冲突使人认为敏捷和架构是对立的：你只能拥有其中一个。与敏捷对立的不是架构，而是大型预先设计。

敏捷软件项目仍然需要架构，因为那些围绕复杂非功能需求和约束的棘手问题不会消失，只是对架构角色的执行不同。

集体代码所有制，每个人都要能在架构的层次上工作，因此每个人某种程度上都是架构师。还不是自组织阶段的团队如果试图跑太快，就会陷入挣扎。尽管人们的愿望是变得敏捷，集体代码所有制和架构角色的分配都有可能阻碍混乱的团队，而不是帮助他们。混乱的团队需要更直接的领导方式，单个点负责软件项目的技术层面，将使他们受益。换句话说，他们会受益于一个人负责软件架构的角色。理想的话，这个人会指导别人，让他们也能以这个角色产生帮助。

软件架构师要一个还是多个？一个人承担责任还是团队共同分担？不论敏捷与否，软件架构的角色都是存在的。只有所处语境会告诉你正确的答案。