我理解的架构师

我理解的架构师

文/余晟

　　昨天参加了了 TopGeek 在浦东软件园举行的架构师大会，与新老朋友讨论了一些关于架构师的话题。其中不少正是我近来一直在思考的问题，索性把我的观点写出来，与大家共同探讨。

　　首先说说为什么“架构师”这么热门？

　　软件行业的热门工种是时常变化的。十多年前热门工种是项目经理，然后是产品经理，最近又成了架构师。背后的原因是什么？不正经地说，哪个工种让大家不爽，让大家备受折磨，它就很可能成为热门工种。

　　在软件开发没有规范化流程化，大家都感觉自己的工作被浪费了的年代，项目经理当然是千夫所指；在产品定义不清楚，无理需求控制不住导致大量无效劳动的年代，产品经理当然被大家所痛恨；在系统复杂度明显上升，开发人员还要大量参与维护迭代升级，却不得不被同一个架构缺陷坑上很多次，架构师当然成了众矢之的——尤其是一些架构师竟然不需要写代码，只需要玩玩幻灯片就能交差，这更是人神共愤了。

　　那么，架构师到底应该干什么？

　　按照我的理解，架构师是个“跨界”的工种。他一脚踩入现实的泥潭，深入理解“这是什么问题”；一脚跨进软件的世界里，知道有什么工具可以用来解决这种问题，并且评估这些工具的风险、投入、代价、效果。最终，产出“如何用软件和系统来解决现实问题”的方案。

　　经常有人拿建筑架构师为例，解释软件架构师的工作。但是，这个例子未必合适。在建筑行业，设计和结构是两个完全不同的工种。设计关注的是风格、美感，至于用什么结构把设计蓝图给实现了，那是结构的事情。建筑行业的朋友讲过一个真实的例子：某建筑请来国际知名设计师，设计案也通过了，真正要建造时大家却傻眼了，不得已去询问设计师，对方非常潇洒地回答说“我只管设计，怎么造，那是你们的事情”。

　　在软件开发行业，很难想象有这样严格的“设计”和“结构”的分野（坑爹的产品经理不算）。架构师常常必须身兼二职，既要理解问题，拿出确实可以解决问题，而且让用户认可的设计，又要确保这个设计是可以实现的，而且是低成本、高可靠、容易维护的。这样看来，架构师真不是个容易的差事。

　　既然这样，程序员和架构师有什么区别呢？

　　确实，很多架构师都是程序员出身，因为架构师既然不能不管实现，就必须有相当的开发功底。但是，程序员一路走下去，就必然能成为“架构师”吗？答案当然是否定的。根据我的经验，程序员和架构师有两点重大区别。

　　第一，程序员更关心具体语言和工具的熟练，架构师则更侧重抽象的问题。

　　我们说一个程序员“称职”，具体表现通常是他熟悉语言和工具，能搞定各种问题，快速而且高质量地提交代码。我们说架构师“称职”，具体表现通常是他能够把握问题的本质，给出经得住考验的解决方案，为了能够把握问题的本质，架构师就需要进行更抽象的思考。

　　可以回到建筑行业的对比。优秀的建筑架构师不会满足于熟练建造某一类型的建筑，比如亭子、车站、会场等等，他必然需要更深层的思考：这个建筑需要用到哪些结构？是梁柱还是梁板？这些结构的特点是什么，是否适合这个场合？在这里“梁柱”和“梁板”更多是抽象的概念，或者是解决问题的模式，在这一层进行思考，对架构师来说是非常重要的。然而在软件行业，很多开发出身的架构师还不能抽象到这一层，而只停留在“有哪些实现方案/现成框架”的水平，这是不够的。我在面试时会问一些软件开发原则的问题，许多候选人对流行框架非常熟悉，对基本的软件开发原则——比如“关注点分离”——却没有概念，所以受制于现成框架给不出好的解决方案，因此距离架构师还是有差距的。

　　我曾经在《收割庄稼 v.s. 砍伐大树》中讲过，抽象就是找到一个层面，能把“看起来不同”的问题归一化，下面可以讲个我自己的例子。我曾经做过几年的搜索，自认为对搜索比较了解，也熟悉 Lucene，Solr，ElasticSearch，Sphinx。有天和朋友聊天，才知道他们竟然用 Memcache 来做搜索，一开始我很震惊，听他讲完却不得不承认，在这个场景和特性下，Memcache 确实是个有效的方案。再仔细反思，我之所以震惊，其实是自己对“搜索”这回事的理解还不够深入，还不能抽象到“打通 Memcache 和 Solr”的程度。所以如果我虽然有过做搜索的经验，但处在他那个场景下，未必能给出很好的解决问题的架构。

　　第二，程序员更擅长解决困难问题，架构师更擅长解决复杂的问题。

　　“困难”问题不同于“复杂”问题，我是做了很多年开发才意识到的，而且庆幸自己意识到了。用我的话说，困难问题可以用几个简单的指标还衡量，比如系统响应速度要提升到多少，系统的数据量要支持到多少。为达成这些指标，当然需要完成大量的工作。但总的来说，这种问题的解决思维是线性的。

　　复杂问题则不同，它很难用几个简单指标来衡量，别说指标，就连问题在开始都不清楚，需要去摸索和定义。复杂问题的面铺得更广，需要的能力也更综合。想做软件架构师的朋友不妨去看看《软件架构师的 12 项修炼》，里面讲的很多并不是“技术”内容，架构师应当怎样沟通，怎样协商，怎样施展领导力，怎样面对公司政治…… 给我留下深刻印象的一点是：在设计解决方案之前一定要清楚各个利益相关方，他们的诉求是怎样，态度是怎样，否则你设计的解决方案很可能不能实现。

　　在今天的会议上有听众提出：我设计了一个很好的软件架构，但公司的组织架构与它不符合，软件开发团队也不能很好地理解和执行它，我应当怎么办？在我看来，这个提问很好地折射出开发人员对于“架构师”，对于“困难问题和复杂问题”的理解偏差。如果对于架构的评价只是从纯粹的“美”出发，而没有考虑到公司的组织架构（并评估自己影响公司组织架构的能力），以及软件开发团队的现实水平，这种“美”就是残缺的，这种架构就不是真正的“美”。

　　看起来，从软件开发人员到架构师还有相当长的路要走，那么成为架构师之后，软件开发的技能还重要吗？

　　我的答案是：非常重要。架构师或许不能保证自己在每个领域每个环节都最精通，但绝对需要足够的技术能力来维护自己对技术架构的感觉。否则，不但可能会受到开发人员的挑战，甚至自己都会丧失对架构的信心。

　　我曾经历过一个“推进全部 Web 接口走 HTTPs”的项目。大方向是没错的，性能也做过评估，但是中途发现某些接口转 HTTPs 之后会造成调用成功率大幅下降，出错几率甚至到了3% 左右，这明显是不可接受的。开发人员和运维人员调了好几天也找不出原因，大家甚至动了“中止推进”的念头，但是这么做会严重影响到整个系统的安全架构。幸亏我还记得 HTTPs 的原理，之前也手工调用过几次 OpenSSL，所以自己动手检查（并求助专门的朋友），终于发现原因在于服务器证书配置上的问题，解决之后整个项目才可以继续下去。架构往往被划为“重要而不紧急”的范畴，会因为实现中的问题而被舍弃，如果架构师没有足够的技术能力，之前设计的架构再优秀，都可能被实现中的妥协冲击得七零八落。

　　关于架构师的话题今天就说这么多，欢迎大家积极留言讨论。如果大家对这个话题的兴趣足够多，我可以接着写下去。