第10章 软件架构师应该是建造大师

把建筑的隐喻应用到软件不见得合适，尽管在中世纪，设计建筑的人只是极少数，却组成了建造大师的高端社团。之所以做这样的隐喻，是因为建造大师名副其实是他们这门学问的大师，一旦达到了这种高度，建造大师是继续建造还是让其他名气不大的人来做？几百年后，我们似乎又在对软件行业问同样的问题。

联盟的状态

在过去的十年间，由于“大型预先设计”和“分析麻痹”等问题，软件架构已经失宠。这多半源于为了更有效地交付软件系统，敏捷方法作为主要的催化剂，减少了很多团队都要做的预先思考的工作量，结果现在“架构师”在软件团队里往往被看作是多余的。很多团队都向着扁平化和自组织努力，从表面上看这不需要再专设技术领导。

另一个因素是，许多人认为架构师都在做高层次的抽象思维。我相信你已经见过“象牙塔架构师”或“PPT架构师”等说法，用来指代那些设计解决方案时从不考虑细节的人。如果我们回顾一下过去，这可不是架构师的角色。

回顾过去

如果你追溯“架构师”（architect）一词在拉丁语（architectus）和希腊语（arkhitekton）的源头，直译就是“首席建筑师”，从字面上看，这些人是他们这行中的佼佼者。在中世纪，“建筑师”一词指“石匠大师”，因为石头是当时的主要建筑材料。下面这句话对这个角色做了很好的总结：

石匠大师，就是石头的操作者、艺术家和设计师。

这句话同样适用于我们软件开发者。

建造大师真的会建造吗

关键问题是，建造大师是否真的建造了什么？如果你研究一下人们如何实现“石匠大师”的角色，就会发现一些类似的东西：

尽管石匠大师受人尊敬、通常也很富有，然而在达到行业顶峰之前，他必须经历石匠、监督的历练来证明自己的价值。

架构师的维基百科页面说了相同的话：

在古代和中世纪的历史中，大多数建筑设计和建设都是工匠完成的：下至石匠和木匠，上至建造大师。

有趣的是，对于这些石匠大师参与过多少建筑，并没有一个统一观点。比如：

他实际上做了多少，其实是有争议的。这个术语可能会有所不同，但是，以我的理解，中世纪石匠大师基本的组织和角色跟今天的首席建筑师是类似的：这也许反映了建筑建造不变的基本。

真正有意义的是看看这个角色承担了什么。引用另一段话：

顶尖的石匠就是一个石匠大师。然而，建筑大师这个头衔，指的是全面负责建筑工地、让石匠大师们为他工作的那个人。建筑大师也负责木匠、玻璃工匠等。实际上，每个建筑工地上的人都在建筑大师的监督下工作。

再加一些额外的细节：

然后，石匠大师为将要建造的东西设计结构、美学和象征等方面的特性，组织后勤，还要评定工作的优先级并决定它们的顺序。

象牙塔

如果这听起来很熟悉，等一等，看看团队过去是如何工作的：

每一个小石匠都遵循大师设定的方向和对主要结构或美学的所有决定，解决那些问题都是大师的工作。

显然，容易看出很多软件团队的传统运作方式与此相似，敏捷软件开发团队希望采用一种不同的方法也就不奇怪了。很多现代的软件开发团队试图让一群人分担技术领导者的角色，而不是安排一个远离细节的专门角色。当然，很多架构师远离细节的主要原因之一是他们没有时间。这通常导致架构师在现实的团队日常工作中被移除，慢慢变得脱离实际。过去的石匠大师也被这个问题困扰：

看起来同时进行多个任务是很平常的事情，石匠大师很少参与体力工作（即使身体条件允许）也就不足为奇。1261年，尼古拉斯·德·比亚德（Nicholas de Biard）在布道中斥责“只靠言语就做判断”的石匠大师的明显懒惰，给出了这一假设的证词。

下面这段话来自瑞秋·戴维斯和丽兹·赛德利所著的《敏捷教练：如何打造优秀的敏捷团队》，突出了这种现象在软件行业中造成的一个常见后果：

如果你了解如何编程，往往会忍不住对开发者该如何编写代码提出建议。小心，因为你可能在浪费时间：如果你没有参与项目的编程，开发者多半会无视你的编码经验。他们还会认为你越权，影响了他们的工作，所以尽量别在这方面指指点点。

为了掩盖这种局面，很多人会把软件架构的角色看作其组织内的一个高级职位或级别，从而加剧了开发者和架构师之间的脱节。看来，石匠大师也有相同的境遇：

为了避免这种争斗，文艺复兴后期的艺术家们不再被视为只是普通的工匠，而石匠大师似乎被神话（在我看来）为贵族后裔。此外，由于对所掌握知识秘而不宣，他们制造了一种神秘感，让自己有别于其他不那么“神秘”或“高尚”的职业。

建造大师角色的差异

多数看法都一样：建造大师并没有太多时间去建造，尽管他们具备这样的技能。回到软件行业，软件架构师应该写代码吗？我直截了当地回答：“理论上，是的。”更完整的答案可以在这本书里面找到。为什么？因为技术不是一个实现细节，你需要理解为自己的决定所做的取舍。

那么现代建筑师为什么不为实际的建造过程出力呢？为了回答这个问题，我们要看看这个角色这些年是如何演化的：

在古代和中世纪的历史中，大多数建筑设计和建设都是工匠完成的：下至石匠和木匠，上至建造大师。直到现代，建筑师和工程师之间也没有明显的区别。在欧洲，建筑师和工程师的头衔主要因地域不同而经常交替使用，但指的都是同一个人。

结构工程的维基百科页面提供了更多信息：

自从人类开始修筑属于自己的结构，结构工程就出现了。在19世纪末的工业革命期间，建筑专业体现出了与工程专业的不同，成为一个更正式的专业。直到那时，建筑师和结构工程师通常还是同一个人：建造大师。19世纪和20世纪初，随着结构理论专业知识的发展，专门的结构工程师才开始出现。

本质上，传统建筑师的角色已经分化为两种。一种是结构工程师，确保建筑物不倒塌；另一种是建筑师，负责与客户交流，收集他们的需求，从美学的视角进行建筑设计。马丁·福勒（Martin Fowler）的bliki有一个页面谈到了两种角色差异的意义：

软件架构师被看作是首席设计师，是把项目的每件事凝聚在一起的人。但建筑师可不会干这些。建筑师关注的是与想要建筑的客户交流。他的精力集中在客户觉得重要的事情上，比如建筑的布局和外观。但建筑也不仅限于此。

因其背后蕴含的包括物理定律在内的丰富知识，建筑现在被看作是一门工程学科，这些知识能够建模和预测建材的行为。相比之下，软件开发行业还比较年轻，正以惊人的速度发展。今天的建筑大多还是使用和几百年前相同的材料，但似乎我们每20分钟就会发明一种新技术。我们生活在“互联网时代”。除非我们这个行业发展到软件的构建方式和预测工程项目相同，否则团队中有人一直跟随技术的发展，有能力做出如何设计软件的正确决策，还是很重要的。换句话说，软件架构师还需要扮演结构工程师和建筑师的角色。

实现角色

最后，简要地说一下，人们如何实现石匠大师的角色。下面这段话来自维基百科的“石匠工艺”页面：

中世纪对石匠技能的需求很大，行业协会的成员按水平被划分为三个等级：学徒、帮工和石匠大师。学徒要和师傅签订契约，以此换取师傅的培训；帮工的技能要高一些，可以到外面去协助别的师傅；石匠大师被看作自由人，可以按自己的意愿选择主顾的项目。

这反映了我自己担任软件架构角色的经验。它是一个渐进的过程。像很多人一样，我的职业生涯始于在别人的监督下写代码，渐渐地，当我获得更多的经验，就开始承担更大的设计任务。不同于中世纪的建筑行业，对于如何从初级开发者到软件架构师，软件开发行业缺乏明确的路线。我们没有普遍的学徒模式。

架构师要和团队一起工作

对很多组织来说，这里有个大问题：找不到足够的架构师。虽然石匠大师可能没有太多时间自己去跟石头打交道，但还是和团队一起工作。我常常遇到一些架构师，他们要协助多个不同团队。很明显，如果和多个不同团队一起工作，要向软件交付的实践部分做出贡献是不现实的，你没有时间写任何代码。

在多个团队中扮演软件架构角色，并不是一个有效的工作方式。通常这种情况发生时，都有一个由被视为共享资源的架构师组成的中心组（比如“企业架构组”）。根据我所读到的，石匠大师任何时候都会只关注一个建筑工地，这也正是我们的软件开发团队应该采用的方法。如果你认为这不可能，就看看中世纪建筑行业是怎么解决这个问题的：

每个石匠都会带一个为他工作的学徒。当石匠接下一份新工作，学徒也会跟着他。如果石匠觉得自己的学徒已经对行当足够了解，就会让他在石匠行会接受考验。

再次回到了典型的学徒模式，这也是为什么指导和辅导应该是现代软件架构角色的一部分。我们需要培养未来的软件架构师，每个软件开发团队都需要他们自己的建造大师。