文/余晟

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

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

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

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

那么,架构师到底应该干什么?

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

余下全文(1/3)

本文最初发表在微信公众号,文章内容属作者个人观点,不代表本站立场。

分享这篇文章:

请关注我们:

发表评论

电子邮件地址不会被公开。 必填项已用*标注