第14章 软件架构不是接力运动

更敏捷的软件团队很可能由除了一项核心专长，还具备更多综合知识和经验的通才组成。理想状况下，这些跨领域的团队成员会一起工作，运作和交付一个软件项目，承担从收集需求和架构到编码和部署的所有事情。尽管很多软件团队都朝自组织的方向努力，然而现实中他们往往更大、更混乱，而且由专才构成。因此，这些团队往往需要，也确实有一个人担任技术领导。

解决方案架构师

有很多人，特别是在大型组织里，自称“解决方案架构师”或“技术架构师”。他们设计好了软件，为自己的方案编写文档，然后扔给一个单独的开发团队。这个方案一旦“完成”，架构师就会去别的地方重复这个过程，甚至往往对开发团队的进展看都不看一眼。如果再加上“不是我发明的”综合症，结果往往就是接手的团队不会对这个方案负责，最初创建的“架构”变得脱离现实。

我曾见过不少这样的架构师，我主持过的一次面试就是这种软件开发方法的缩影。在照例抛出“谈谈你的角色和最近的项目”这个问题之后，我就清楚地知道，面前这个（为一个大型“蓝筹”咨询公司工作的）架构师的所作所为，就是给一个项目创建软件架构，写好文档然后到其他地方重复这个过程。他告诉我，给出“方案”后就很少或不再参与项目，然后我问他怎么知道他的软件架构是管用的。他被这个问题困住了，最后他声明这是“实现细节”。他自信地认为自己的软件架构是正确的，如果开发团队没有让它工作，那是他们的问题。在我看来，这种说法简直荒谬，这让他看起来像头蠢驴。他的方法也就是AaaS……“架构即服务”！

要有人负责大局

不同于典型的软件开发者，软件架构角色需要通才。这肯定是在软件项目起航阶段掌舵的角色，包括管理非功能性需求，整理出对上下文和环境因素敏感的软件设计。但也要不断地转向，因为你选择的航线可能需要在途中调整。毕竟，敏捷方法已经向我们展示了，不一定预先就有（或需要）所有的信息。

创建一个最初的愿景，交流，并在整个软件开发的生命周期中潜在地演化它，这些对一个成功的软件项目是必需的。单是这个原因，让某人来创建这个愿景，然后让另一个团队去（试着）交付，就毫无意义。当这种事情发生时，初始的设计方案本质上就成了在架构师和开发团队中传递的指挥棒。这很低效，甚至无效，文档交换也意味着很多与创建愿景相关的决策上下文也丢失了。祈祷开发团队永远不需要问任何关于设计或其意图的问题吧！

真正的自组织团队不会有这样的问题，但大多数团队还没有成熟到那个程度。在整个交付中，要有人负责大局，同时为保证软件顺利交付承担责任。软件开发不是接力运动，顺利交付也不是“实现细节”。