背景

---

周末参加topgeek组织的2016年度中国架构师大会，日程之一是圆桌会议：“如何成为顶级架构师”。有意思的是，四位嘉宾一致和不写代码的“PPT架构师”撇清了关系，均表示至今还在撸代码。不出意外，台下的架构师们报以经久不息的掌声。

怎么定位软件架构师？

---

角色是无法自赋其意义的，就好比我偶尔喝高了，斗胆号称一家之主，老婆大人一定会招呼我一个巴掌:-)。角色存在的价值必须从他和环境的相互关系中去寻找。我们试着看看一个典型的软件开发组织中不同干系人对架构师的期望。

客户
不要奇怪，客户也会关心架构，比如兄弟所在的行业，你不把自己的技术方案和演进路线说清楚，客户是不敢把他上亿的资金还有他未来10数年的基础设施演进押在你身上的。

产品经理
期望方案方案价廉物美，关键还要能频繁修改，能迅速上线。

CTO
CTO是老板在技术方面的代理人，他既关心公司的当前利益也关心长期利益。他的期望是架构师的方案既能满足当前需求，也匹配公司的长期技术演进路线。传说CTO还有一个变态的需求--你得在电梯开门之前把你的思路讲清楚。

其他架构师
你的架构至少得通过其他架构师的评审。你得证明你的架构是“好”的。

项目经理
技术风险是否可控，架构是否能在期望的时间内被团队落实，系统是否被有效分解为子系统以便安排团队齐头并进。

开发团队
开发团队最关心的是自己负责的子系统的职责是否被清晰定义。这样他们可以安排资源，估算进度，安心撸代码。此外，不同的团队领导可能会对开发任务在不同领域（团队）的映射有不同想法，这个模块应该是隔壁领域的自留地？开发团队中有一些能人，他们可能会对你的架构评头论足；开发团队中还有一些初级员工，无论你觉得你的架构阐述得多么清晰，他们总是一脸茫然。

以上这些职责都假设架构师技术功底扎实，但真正的挑战其实在于沟通技能。显然，不要说撸代码，就算能整出一套漂亮的PPT也未必搞得定楼上各路诸侯：

架构是份新工作

---

从局部到全局
既然贵公司设定了架构师这个职位，说明贵老板已经意识到系统的规模已经超过了单个能人能搞定的程度了。你现在的工作内容绝不会是以前的工作减去编码。横向看，你要搞清楚系统所涉及的不同方面，你以前可能是后台的高手，现在可能要涉及到前端，以前可能是支付领域的高手，现在可能还要看看物流；纵向看，你得对这个系统接下来的发展有点想法，你的架构制品首先要满足当前需求，这是没错的，但是人们期望它不要和可以看见的未来冲突......

你之前是个C#高手，或许你意识到用这个技术的兄弟公司越来越少了，少到HR都不好找人了，而且你听说有个叫阿里的公司开放了很多用Java写的中间件，似乎你们恰好也用得上，那下一步是不是要把平台切换到java呢？对了，老大昨天很开心的告诉你，用java的竞争对手最近正在为核心员工被淘宝挖走发愁哪！看来这个决定似乎不是那么好做了。

从代码到PPT
是的，我猜中了，你痛恨写文档，而且你还知道有个什么宣言支持你说凡是不是代码的东西都是浪费。如果我又没猜错的话，你在这家公司的成长路线是这样的：

成长的烦恼

---

小兵变牛人
一开始，你默默无闻，埋头coding，首先是公正的电脑上帝发现，你的程序从来不出错，后来测试组妹妹也发现，bug都是其他人的（再后来，即便是你的bug她也不敢相信是你了），一直到这个时候，你的代码主要是被机器阅读的，机器好啊，它老人家只管对错不挑美丑，回车键一敲，编译，单元测试，部署，自动测试，OK，一把全过，多爽啊！你一定很回味这个感觉对不对？接下来，组长大哥也发现你是一个人才，开始分配一些体量大一点的工作给你了。

秀才遇到兵
为了控制代码质量，你们开始做代码评审了，有些同事（或许就是你）觉得代码能工作，跑得快还不够，还要写的好，妈蛋！什么叫写的好写的坏啊，总之评审会是乱成一锅粥，每个人都振振有词，每个人都说服不了别人！是的，现在没有电脑这个说一不二的裁判了，上帝已死！

你不得不思考代码好坏的客观标准了，你脑补了一堆实现模式，设计模式，架构模式，还有什么坏味道之类的，停一停，凭什么这些家伙讲的就是对的？于是你进一步钻到故纸堆里，发现这些真理后面的真理在上个世纪70年代就整理好了，而且还要言不烦。于是你信心满满，下次代码评审会侃侃而谈，不对！那些在你看来就像“两点之间直线最短”这么铁的设计准则，为什么写浆糊代码的兄弟就是死活听不进去！作者自己，一路刨根究底，最后一头扎进认知心理学

这下你知道生活不容易了吧，自己搞懂是一回事，把真理传播给别人是另一回事，否则的话，小学班上的王二小也不会老是数学考不及格了。没错，我相信你从此以后真的是把代码写好了，但是你并没有说服其他人。

架构编档
现在你是架构师了，什么，拿代码说话？把开发团队撤了，就保留你一个人行吗？一开始，你的文档整得太细了，首先你自己觉得这样写下去还不如直接上代码来得爽快，其次软件团队觉得你规定得太细了，有些地方和实际有出入，没法照着你写的做，再次，项目经理在催你了，因为还有其他几个团队的兄弟等着你的输入好开张。慢慢的，项目进展到集成阶段了，你发现模块之间的配合才是真正的问题，于是你渐渐不操心局部模块的问题了。

工作中总是有一些让人烦心的事，有时候，你踌躇于究竟该用圆角矩形还是直角矩形来表示一个模块；有时候，你把各种箭头的形状都尝试完了，还是没法把心中的那个关系痛快的表达出来；更要命的是，你绞尽脑汁做出来的PPT,有人觉得他就是看不懂，或者有个点子你明明画在图上了，可软件团队的兄弟跟你说他压根就不知道你是这个意思，有时候你明明是这个意思，人家读者非要感觉是那个意思。

是的，我没猜错，UML, 你又找到法宝了。可是问题还是不断出现，首先是你自己也总是觉得这东西的表达能力好像也有那么一点局限，虽然不再为圆角矩形还是直角矩形纠结了，可是什么关系都用一条线来表示是不是也太简陋了，要知道之前你可以直接用大框套小框来表达包含、用上下关系来表达堆叠，多么形象啊，现在都没啦。

沟通为王
我知道聪明的你最终搞定了架构编档，你能够得心应手的表达自己的想法了，更加重要的是，别人也能透过文档看懂你的想法了。而且你还是个技术牛人，你的架构很美！

但是问题来了，你也知道，软件的质量属性有时候是互相冲突的，有时候为了效率你不得不破坏封装，有时候为了可靠，你不得不引入冗余，牺牲简单性....., 问题来了，你觉得简单性重要，他偏偏觉得效率更加重要，你觉得让当前特性尽快上线迫在眉睫，他觉得把结构整理清楚刻不容缓。

架构组中有个把老顽固，他们死活就觉得你的设计不那么美，虽然私下里你觉得是他们知识结构老化导致的，可是领导说，没获得大家的一致同意，你的架构就是不能通过，领导还偷偷的告诉你，其实他也同意你的设计；还有，有时你觉得某个现成的中间件完全能满足项目的需求，但是会导致某个正在造轮子的团队关门......

好悲摧！好不容易把PPT撸顺了，到头来发现还要去撸心......

台上的嘉宾，很可能是代码、PPT、别人的人心、自己的心都撸过一遍了，所以他们有闲暇去撸撸代码，台下的你，极有可能刚刚把代码撸顺，你应该知道有没有功夫去享受这份奢侈。