之前在公司，有小伙伴在向别人介绍我的时候，经常会有人这么说：“刚哥是我们的architcture”，如果来人是老外，心中一定是一惊，心中暗叹，“这位匪首看上去貌不惊人，难道已经做到了架构和本人天人合一和最高境界了？” 回头，我不免又要唠叨两句，“同学们，没文化，很可怕，我是架构师 architect，不是架构 architcture” 就像我上次跟大家聊的一样，人是架构要解决的核心问题之一，那么说“人暨架构”，似乎也是有些道理。但是你要是硬说架构师就是架构，恐怕你是对架构师有什么误解。

从企业的角度来看，会定义不同的架构师的角色，像什么系统架构师，解决方案架构师，软件架构师等等。我们要谈论的是软件架构师这个角色。其实很多的软件企业和团队，都没有定义架构师这个角色。在我早期参与的软件开发团队中，主要的角色无非是产品，开发，测试和管理角色。后来的敏捷开发就更为简单的分成三个角色Scrum Master， Product Owner， Dev。在这样环境中，并不是说没有架构师，也不是说不需要架构设计，而是说，架构设计的工作被团队经理，开发等其它的角色所承担。

“一千个人眼中就有一千个哈姆雷特”，每个程序员，每个组织，每个企业也都会有自己心目中的架构师，那么我今天就来聊聊我对架构师这个角色的看法。

我眼中的架构师不一定有颈椎病，不一定秃发，但一定首先是一个程序猿，一个软件工程师，一个码农。

经常看到有小伙伴讨论架构师要不要写代码？我认为这是个伪命题，就像我之前说的，大家根本没有对架构师有一个统一，一致的定义，那么讨论架构师要不要写代码根本就没有意义，有的架构师需要写代码，有的并不需要。但我眼中的软件架构师一定是一个优秀的程序猿，软件开发是一个实践性非常强的工作，你不能指望通过学习几本二十一天入门类的书籍就能对软件开发有一个深入的认识。软件开发并不是有人说的艺术，也不是科学，软件开发需要的工匠精神恰恰是来自于大量的实践。 ‘Talk is cheap，show me your code’， 架构师不仅仅是画画架构设计图，做些炫酷的PPT和演讲，虽然这几样都是我非常喜欢和擅长做的工作。

我眼中的架构师是一个技术领导者。

杰拉尔德·温伯格 (Gerald M.Weinberg) 是我最喜欢的软件类书籍的作家，他是软件顾问和问题解决的专家。他的《成为技术领导者》也是一本值得反复阅读的书籍。

我们经常会有关于领导和领导力的话题和讨论，那么组织中的领导究竟要干什么，我们不是有经理么，经理不就是领导么？我认为领导和经理的区别在于，领导做正确的事，而经理的主要职责是正确地做事。做正确的事通常意味着作出正确的选择，这里的难点在于，什么才是正确的？回答这个问题就要上升到哲学的角度了。墙裂推荐哈佛大学迈克尔·桑德尔教授法学系列课程《公正：该如何做是好？》 一般来说，按照我们之前对软件架构的定义，正确的选择意味着有助于实现软件功能，有助于使得团队可以更好的协同工作，有助于提升开发的效率。温伯格在《成为技术领导者》中说到 “用乘法而不是加法”，好的架构也都是以倍增的方式来改进软件开发的效率，例如云平台Kubernetes，前端框架react等等。在我们日常的软件开发过程中，经常会面对着这样那样的诸多选择，好的架构师能够帮助团队选择最适合的那个，也就是我们说的“正确”的决策，这个很难，但是这还不是最难的。当你做出了你认为是正确的选择的时候，下一步是什么呢？有同学说，那就开始干呗！很多时候，架构师不像是经理，直接管理团队，也就是说架构师并没有最终的决策权。架构师说，“同志们，我看这样做挺好，咱们就这么搞吧！” 团队成员直接怼过来，“为什么要这么搞吧？我看那么做也挺好么”。要让一个好的决策落地，架构师需要说服团队，让大家相信这真的是一个正确的决策。这就像是“狼人杀”游戏中，你作为一个逻辑严密的玩家，通过聆听一轮发言，准确的辨别出所有的狼人，然而你却无力说服队友你是对的。“狼人杀”这个游戏的精髓就在于，这是一个团队游戏，你怎么认为并不重要，重要的是你的团队是怎么看的。

所以，作为一个优秀的架构师，除了技术之外，你需要有很优秀的逻辑思维和表达能力，良好的人际关系以及不错的口碑。程序猿是一个很有特色的群体，他们通常都有一个特点，就是非常的“固执”。说服一个程序猿放弃自己的观点，简直堪比送神州火箭登上月球。所以永远不要试图证明程序猿错了，也不要证明他的观点不如你的观点。因为所处的角度不同，我相信自己是正确地的同时并不意味着要证明别人是错误的。

一个好的架构师，作为一个技术领导者的核心能力是影响力。当然这个影响力是建立在能够真正作出正确的选择的基础上的。最糟糕的情况是，作为一个领导者，因为能力不足，选择一个错误的方向，然而因为其强大的影响力，就像乔布斯那样拥有扭曲现实的能力，而你又恰恰拥有一个执行能力很强的团队，那么结果只有一个，你会离你的目标越来越远。

我眼中的架构师是技术和产品的之间的桥梁

我们圈子中经常会流传着程序猿和产品经理之间的各种小故事。作为软件圈里的世仇，他们的故事还可以讲述很久很久

（图片来自https://mp.weixin.qq.com/s/hGIuHzD-9VNsS-JO2z7dWw）

我们看到产品和开发作为拥有不同世界观的两个群体，很难理解对方，而我眼中的优秀架构师应该成为产品和开发之间的一个沟通的桥梁，一个能理解两个世界，精通两门语言的的翻译。架构师需要把产品功能翻译成程序猿能够理解的技术语言，同样架构师需要把开发面临的挑战以非技术的语言，转达给产品经理。所以架构师应该同时是产品和开发的好朋友！

我眼中的架构师是一个团队的催化剂

讲一个笑话，我的一个朋友最近加入了一家创业公司，他说他入职的那一天，公司的CEO，CTO，CFO，产品经理，测试，市场，司机，厨子，保安都来欢迎他的入职。我对他说，“你太有面子，公司看来对你很重视呀，派出这么多人来欢迎你。” 他说，“哪里呀，不就一个人么！”

今天的软件开发对团队的依赖程度非常的高，所以架构师首先是这个团队的一个成员，需要有良好的团队精神。诺兰大师在他的电影《盗梦空间》中讲述了一个精彩的关于团队合作的故事。

架构师（筑梦师）无疑是团队中的重要角色，但是一个良好运作的团队，需要各个角色协同工作，离开谁，这个团队都不完美。好的团队应该是1+1 > 2。公司的意义在于通过把拥有不同的背影，知识，思维模式的人组织在一起，创造出个体无法实现的新的创意，新的产品。而架构师正是实现新的创意和产品的催化剂，让团队中的每一个人都能发挥出比之前更出色的作用。

我眼中的架构师是一个导师和布道者

软件行业是一个令人激动的行业，技术和产品的以不可思议的速度迅速的发展着，今天的明星技术和明星产品，过不多久就会成为昨日黄花，软件产品的生命周也越来越短，我想了想我参与的软件产品，至今仍然在运行的，仍然在给用户带来价值的，大概是微乎其微的。所以不断的学习，不断的创新是我们这个行业必须要面对的宿命。我眼中的架构师应该是一个创新和新技术的倡导者，这里我并不是说新技术一定就是更好的或者更合适的选择，但是我们应该持有开放的心态，积极的去了解这些新技术带来的影响。作为导师的架构师，应该在团队中创造这样的开放心态和持续学习的文化。

在多年的软件开发生涯中，我和许多优秀的架构师一起工作过，我最后要聊一聊的是我遇到的架构师中的极品。之前在一家德国公司开发ERP产品，我们团队中的架构师来自德国，我们就称呼他为“老卡”吧。这位“老卡”继承了德国人优秀的哲学思维，如果你跟“老卡”讨论问题，他总是采取“否定一切”的哲学态度，首先说你错了，然后会告诉你为什么你错了。最为致命的是，通常你只能理解他说的你是错的这个观点，而“老卡”所有其它所说的内容，你完全听不懂。一般而言，德国人的英语水平是非常好的，所以并不存在因为语言问题而带来的交流困难。“老卡”喜欢用一些古怪的“大词”或者缩写，结合一些奇怪的逻辑，给对方产生一种深不可测的错觉，我想这就是传说中的架构师的终极形态吧！就像这个故事中的应试者：

面试官：你对电脑懂多少？
应试者（普通青年）：懂一点，我戴过电子表，玩过任天堂，房间有一台电视……还有，我看过同学用dos开机，两次…
面试官：下一位！
面试官：你对电脑懂多少？
应试者（2B架构师）：嗯，那要看是哪一种电脑了。一般的超次掌上型矽单晶片时脉输出电脑（电子表）比较简单，我小学时候常常使用他的解译编码作业流程（闹铃功能）。 至於多功能虚拟实境模拟器（任天堂）就复杂得多，不过我曾经完整测试过许多静态资料储存单体（只玩卡带破关）。长大後我对於复频道超高频无线多媒体接收仪器（电视）开始产生兴趣，每天晚上都会追踪特定频道的资料(指八点档)。 至於传统的数位电脑，我手下的一位工作伙伴（同学）经常在我的监控之下进行主储存矽单体与磁化资料存取器之间的信号交换（指dos开机）……

后来和印度同事聊天，他们好奇的问，你们都是怎么和“老卡”交流的，他说的你们能听懂么？我当然不能给中国人丢人吧，就说能！印度同事投来崇敬的目光，在他们眼中，因为无法理解老卡所说的一切，“老卡”俨然成为他们心目中神一样的存在，能和神交流的，也应该不是凡人吧！

所以我要对有志成为架构师的小伙伴提个建议，如果你的技术不扎实，学习能力不佳，沟通有困难，这都不是事。努力学习如何让别人听不懂你所说的话，渐渐的，你就会成为架构师了。

参考

• 刚哥谈架构 （一） 软件架构的定义
• 宿命之战：程序员VS产品经理