怎样成长为优秀的软件架构师?

分享七牛云CEO「许式伟」对于这个话题的思考 。
 
怎样成长为优秀的软件架构师?

文章插图
你好,我是许式伟 。从今天起,我想和你一起来聊聊架构的话题 。
开始之前,我先来和你简单介绍下我自己 。
我是2000年开始工作的,曾经做过wps的首席架构师,也在盛大从事过技术研究方面的工作,后来在2011年创立了七牛云,现在我是一名创业者、CEO 。但不管角色怎么轮换,我觉得我的另一面始终是一名程序员、架构师 。
让我们来想象一下,如果把信息世界看成一座大厦,把程序员看成这个世界的建筑师,那么,现在的你在负责什么样的工作呢?
当我们把程序员类比成建筑师时,按照能力水平来分,我觉得大体可以分为三个层次:搬砖师、工程师、架构师 。
软件搬砖师之名对应到建筑行业的建筑工人,他们的编程能力和业务基本上停留在堆叠代码,按照要求去实现功能需求的层面 。
只要能让程序跑起来,能正确地实现业务逻辑,就可以称为“会编程”的人 。有时候,我们也会看见程序员自称为“码农”“搬砖的”,虽然二者的工种不同,但从基础工作的相似度来说,确实有可类比的成分 。
【怎样成长为优秀的软件架构师?】很多外行的人都会觉得程序员是一个很神秘的职业,但实际上程序员的基础门槛并不算高 。我自己从2016年2月开始至今,一直在教几位8~12岁的小朋友学习编程 。这个实践经验告诉我:小学生完全有能力学编程 。而且,并不是只有部分小学生可以,而是任何一位小学生都可以学会 。
然而,只让代码跑起来是不够的 。这个世界是不断变化的,作为程序员,我们更多的时间是用来维护代码:增加新的需求,对已有的功能进行调整,修改之前代码遗留下来的问题,优化性能等等 。
这是因为一个软件诞生之后,后续就是需要花费大量的代价去维护它,演进它 。一个人是完全维护不过来的,需要更多的人,很多的团队一起协作 。如果面临了员工离职、岗位调整等情况,还会导致软件代码在不同人之间流转 。
所以,一些有追求的程序员会关注代码的质量 。代码质量的评判可以有这样一些基本维度:可阅读性(方便代码流转)、可扩展性/可维护性(方便修改功能,添加新功能)、可测试性(质量管理)、可复用性(简化后续功能开发的难度) 。
这一类致力于不断提升软件代码的工程质量的程序员,我们可以称他们为软件工程师 。
工程师不会简单把写代码看作一门工作,把任务交代过去就完事 。他们会有“洁癖”,代码在他们眼里是一种艺术,是自己生命的一部分 。
他们会把写出来的代码改了又改,直到让自己满意为止 。阅读和维护软件工程师写的代码会有一种赏心悦目的感觉 。
但是,大部分商业软件都是一项极其复杂的工程,它们远比很多传统的建筑工程复杂得多,无论是涉及的人力、时间还是业务的变数都要多很多 。
人力上,大部分大型的软件系统都有几千甚至几万人的规模,而这几千几万人中,却没有两个人的工作是重复的,他们都是在从事着前所未有的创造性工作 。
时间上,只要软件还在服务客户中,程序员们的创造过程便不会停止,软件系统仍然持续迭代更新,以便形成更好的市场竞争力 。
这些都与传统建筑工程的模式大相径庭 。一幢建筑自它完成之后,所有的变化便主要集中在一些软装的细节上,很少会再发生剧烈的变动,更不会持续地发生变动 。但软件却不是这样,它从诞生之初到其生命周期结束,自始至终都在迭代变化,从未停止 。
所以,光靠把控软件工程师的水平,依赖他们自觉保障的工程质量,是远远不够的 。软件工程是一项非常复杂的系统工程,它需要依赖一个能够掌控整个工程全局的团队,来规划和引导整个系统的演变过程 。这个团队就是架构师团队 。
软件架构师的职责,并不单单是我们通常理解的,对软件系统进行边界划分和模块规格的定义 。
从根本目标来说,软件架构师要对软件工程的执行结果负责,这包括:按时按质进行软件的迭代和发布、敏捷地响应需求变更、防范软件质量风险(避免发生软件质量事故)、降低迭代维护成本 。
那怎么才能成长为优秀的软件架构师?软件架构师和软件工程师最根本的差别又在哪里?我认为关键在于四个字:掌控全局 。


推荐阅读