讲述下我所理解和认识的架构师

    作者:课课家教育更新于: 2019-05-05 15:07:37

      首先,软件开发师是一个神圣且重要的职位,而架构师是软件开发师中如今比较热门的,而为何会如此的热门,必定有他背后所存在的原因。讲述下我所理解和认识的架构师_软件架构师_软件开发师_软件架构视频_课课家

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

      总之,架构师作为人软件开发师的一个新型代表,必定会给软件开发行业注入前所未有的新的活力,从而更好的推进软件开发行业的进一步向前发展。

课课家教育

未登录

1