本人从事软件开发和项目管理多年,看过也做过架构,最近在读 Fundamentals of Software Architecture ,体会颇深。借着这篇博客文章分享给大家,希望跟大家交流一下。
本文英文版同步发表在 Medium,望大佬们指点。
以下是正文。
"架构就是处理一些重要事情,不过鬼知道那是些什么。" -- Ralph Johnson
架构师( Architect )应该是一个很有份量而又饱受尊敬的职位。每当听到某某是某公司的架构师时,会不会有一种肃然起敬的感觉?在大众看来,架构师通常跟系统设计、技术实力、领导力、影响力有着密切联系。也正是这个原因,企业中很多架构师的岗位都是由经验丰富、技术能力扎实的资深软件工程师担任。然而,软件行业对于架构师的定义,其实并不明确:亚马逊、阿里云之类的云服务商有自己的架构师团队,不过大多是顶着架构师的名头进行客户售后服务而已;在某企业里的架构师,无外乎就是利用自己的丰富经验和过硬实力,来解决技术难题,相当于资深软件工程师。这些都跟我们心目中的设计高大上架构图的、无所不知的架构师,有很大差别。
本文中所指代的架构师相关概念,主要来自于最近阅读的一本书《软件架构基础》(英文名:Fundamentals of Software Architecture ,作者 Mark Richards 、Neal Ford )。本篇文章会简单介绍更具实用意义上的架构师需要做什么,以及相关的必备技能。
架构师首先是整个软件项目中的总工程师,需要对软件工程的整体设计、实施、质量负责。因此,对于软件架构师来说,其需要具有优秀的编程技能,熟悉软件项目开发流程,以及在各种技术领域具备一定的广度和深度。不仅如此,由于架构师是技术侧的总负责人,他(或她)通常需要站在系统的整体角度,来思考各个模块之间是如何交互的,功能服务的划分是否合理,整个系统的瓶颈会在哪里,等等。而这些,都是技术层面的东西。
当一个软件工程师经手了很多大大小小的项目之后,都应该会对软件工程以及架构有一些深刻理解,再加上一些系统学习,应该都可以有成为架构师的资质。因此,单从技术层面来看,软件架构师相当于资深的软件工程师。
大家或许都或多或少看过架构师们画的各式各样的架构图:分层式架构图、物理网络拓扑图、流程示意图、交互逻辑图,等等。但要回答架构图是否重要的问题,咱们需要稍微理解一下为什么需要架构图。架构图主要目的,是帮助对内部工程师或外部技术人员快速理解其中包含的系统模块信息。因此,那些看似酷炫、专业、赏心悦目的架构图,如果缺乏内涵,对帮助理解来说不一定有帮助。反倒是简洁、清晰、易理解的架构图,即使看起来很丑,对于软件开发者来说也帮助巨大。因此,架构图是重要的,但主要目的是清晰简洁的展现系统模块信息。
前面说过,架构师作为软件工程的总工程师,会承担技术侧的责任。但是现实当中,很少有只聚焦于技术层面工作的架构师,或者至少只精通技术方面技能而能在项目中游刃有余的架构师。成功的架构师、或者具有影响力的架构师,至少需要具有良好的领导力或团队管理能力。
《软件架构基础中》中关于架构师的 8 项技能要求列表中,有一半跟技术不直接相关。我们来看一下这本书提及的技术和非技术要求。
你可能会惊讶于后半部分对架构师的非技术要求,例如为什么架构师需要考虑政治?笔者在之前做单纯的技术人员时也不明白,但随着项目经历不断积累,直至自己也成为项目管理者之后,才发现企业中的很多架构决策不单来自于架构本身的技术合理性,而是跟企业政治有关。这里说的政治不是传统意义上的官僚主义,而更多的是指代各部门之间协作或竞争关系;特别是当企业规模非常大时,这种考虑犹为重要。限于篇幅原因,这里不细说,后面有机会可以单独聊一聊。
可惜的是,不少从工程师提拔起来的架构师,还是在技术领域不断钻研,而忽视了非技术的东西。因此,本篇文章所强调的观点,就是架构师的职责和要求绝对不只是技术和架构本身,而需要考虑更多非技术方面的技巧和经验积累。例如,如何在合规性、资源、开发效率之中作出平衡;自己负责的软件项目,对公司提供什么商业价值,会对业务造成什么影响;如何向非技术人员(特别是老板)解释专业术语;面对外部部门不配合的情况,如何从中周旋,保证项目顺利进行。诸如此类的问题都需要非技术技巧和经验,而想要在职业道路上更进一步的架构师,或许更需要考虑这些。跨出自己的舒适圈,才能有效开始学习和成长。
如果您对笔者的文章感兴趣,可以加笔者微信 tikazyq1 并注明 "码之道",笔者会将你拉入 "码之道" 交流群。
本篇文章英文版同步发布在 Medium,技术分享无国界,欢迎大佬们指点。