| 首页  |  资讯  |  评测  |  活动  |  学院  |  专题  |  杂志  |  产服  |  
您现在的位置:硅谷网> 资讯> 科技>

如何成为一名优秀架构师?Mobvista蔡超给出8条建议

2020-09-18 17:43 作者:佚名 来源:网络 关注: 编辑:GuiGu 【搜索试试

还在为如何成为优秀架构师而苦恼吗?近日,汇量科技(Mobvista)集团副总裁兼首席工程架构师蔡超做客QCon+案例研习社线上发布会,为我们带来了答案。

图片来源于Mobvista

蔡超拥有17年软件开发经验,其中有超过10年在HP、Amazon等世界级公司任职软件架构师/首席架构师。先后领导开发了网络安全管理系统(TopAnalyzer)、HP(中国)移动设备管理系统、亚马逊全球的新外部直运(External Fulfillment)平台、亚马逊物流+系统、亚马逊全球客服系统以及大型弹性集群管理平台SpotMax等。基于多年实战经验,蔡超总结并分享了他在架构师成长之路上的8大窍门,为同行们带来更多思考。

右1为汇量科技(Mobvista)集团副总裁兼首席工程架构师蔡超

以下是蔡超的分享内容:

到现在我工作17年了,期间不仅在HP,Amazon这样的世界级团队中担任过架构师,也在汇量科技这样快速成长的企业中担任过技术领导。基于超过十年的架构师工作经验,我将和大家分享一下这些年的成功与失败,希望能帮助大家避开那些我曾踩过的坑。

“提出问题”难于“解决问题”

作为技术人员我们往往习惯于给出设计方案,做一个问题的解决者,而很少做一个问题的提出者,去思考要设计什么。团队中最常见的典型矛盾是产品团队和研发团队的矛盾。作为研发团队,我们常吐槽产品团队的需求不合理,不懂技术等。

其实我们可以尝试把自己的工作在往前移一下,不仅仅是去设计架构实现产品的需求,而是去实现客户的需求,甚至发现潜在需求。

变成在设计上提出问题的人后,你会发现提出问题同样需要深入思考,设计一个好的问题,有时候甚至比解决问题更难。

即便是软件开发领域的大神Frederick P. Brooks Jr.(《人月神话》的作者)也会有同样的感叹,“The hardest part of design is deciding what to design.” 这句话便是出自他的《The design of design》。

决定“不要什么”比“要什么”更难

也许是由于人性的贪婪,对于软件系统我们同样想要更多:更多功能,更好的性能,更好的伸缩性,扩展性等等。作为软件架构师要明白软件架构设计其实是一种取舍或平衡。当大家都在往里面加东西的时候,架构师更应该来做这个说不的人。

软件设计和定义过程中存在很多取舍,如完善功能和及早发布的取舍、伸缩性和性能的取舍等。如何做好取舍?著名的CAP原则就是一个很好的关于取舍的指导策略。为保持架构风格的一致性,在一开始架构师就应该根据系统的实际需求来定义一些取舍的原则,如:数据一致性拥有最高优先级,提前发布核心功能优于完整发布等。

非功能性需求决定架构

很多设计人员可能会认为架构是由要实现的功能性需求决定的,但实际上真正决定软件架构的其实是非功能性需求。因此,架构师需更加关注非功能性需求,如性能,伸缩性,扩展性和可维护性,甚至包括团队技术水平和发布时间要求等。能实现功能性需求的设计方案有很多,只有考虑了非功能性需求后才能筛选出最合适的设计。

《面向模式的软件架构》这套书为不同的非功能性需求提供了很好的参考和指导,多年来一直是架构师们的必读经典。下图的架构模式便是来自这本书的第一卷,图中的Micro-Kernel模式,更加关注可扩展性和可用性(错误隔离)。

“简单”并不“容易”

很多架构师常常会提到保持简单,但有时候我们往往会混淆简单和容易。简单和容易在英语里是两个不同的词“simple”和“easy”。 

史蒂夫·乔布斯曾说过“Simple can be harder than complex: You have to work hard to get your thinking clean to make it simple. But it’s worth it in the end because once you get there, you can move mountains. To be truly simple, you have to go really deep.”

真正的简单方法往往是来自于对问题和技术的更深入理解,简单可以说蕴含着一种深入的巧妙在其中。下面我来举一个例子。

据数据显示,在一款软件系统的生命周期中,成本消耗占比最大的部分往往在于维护。因此如果能简化维护部分,对于整个项目将具有全局性的意义。

我们曾经为移动运营商开发过一个系统设备管理系统,移动运营商期待通过该系统管理移动设备,因此,系统需实现包括设备的自动注册,固件和软件的同步等管理功能。这些功能可通过一些管理系统与移动设备间的预定义的交互协议来完成,过程中,电信专家们会根据业务场景及需求来调整和新增这些交互协议。起初我们采用了一种容易实现的方式,即团队中的软件工程师根据电信专家的说明将协议实现为对应代码。

但很快我们便发现这样的方式不仅没有让项目更容易,反而让我们的工作变得更复杂。

“I believe that the hardest part of software projects, the most common source of project failure, is communication with the customers and users of that software.”--Martin Fowler

正如软件开发大师MartinFowler所说“沟通”往往是导致软件项目失败的主要问题。这个项目最大的问题是在系统上线后的运行维护阶段,电信专家和开发工程师之间会不断就新的协议修改和增加持续沟通,而由于双方的知识和词汇存在很大区别,导致了沟通效率低、系统维护(协议的修改)变得十分艰难,协议更新上线慢等问题。同时,由于软件工程对于电信协议的理解程度有限,很多问题往往在实际上线后才暴露出来,导致了很多交换和反复。

针对这一问题,我们和电信专家一起设计了一种协议设计语言(并提供可视化的工具)。这种设计语言使用的是电信专家所熟悉的词汇,然后通过一个类似于编译器的程序将电信专家定义好的协议模型转换为内存中的Java结构。整个项目的运行与维护因此变得简单高效,省去了低效的沟通和不准确的人工转换。

不难看出,一开始按电信专家的说明直接实现协议看似更为容易,但放在整个软件的生命周期中,这却并非一个简单高效的方法。

永远不要停止编码

架构师也是程序员,代码是软件的最终实现形态,停止编程会逐渐让你忘记作为程序员的感受,更重要的是忘记其中“痛”,从而容易产生一些不切实际的设计。在亚马逊,高级副总裁级别的distinguish Engineer,如被称为Java之父的James Gosling等每年的编码量均不低于10万行。

风险优先

架构设计很重要的一点是识别可能存在的风险,尤其是非功能性需求实现的风险。因为这些风险往往没有功能性需求这么容易在初期就被发现,但修正的代价却比修正功能性需求的代价大很多,严重时甚至可能导致项目失败。

因此,我们应该在原型或早期的迭代中确认风险,并通过合理的架构解决风险。绝对不要把风险放到最后,就算是一个项目要失败也要让它快速失败,这也是一种敏捷。

从“问题”开始,而不是“技术”

技术人员对新技术有着一种与身俱来的激情,总是乐于学习新技术和使用新技术。这容易导致一个通病,就是“当我们有一个锤子的时候看什么都是钉子”,因而使用一些不适合的技术去解决手边的问题,导致简单问题复杂化。

我曾经的一个团队便发生过类似事件,原本是一个用MySQL作数据存储的简单服务,但由于当时负责该项目的人员对彼时新出的DynamoDB产生了兴趣并学习了相关知识,因此该成员决定使用DynamoDB替换MySQL。

之后很快发现DynamoDB并不能很好地支持事务特性,在当时只有一个性能极差的客户端类库支持事务,而由于采用了客户端方式,引入了大量额外交互,导致性能差别达到7倍之多。

这时候,这个成员就采用了当时在NoSQL领域广泛流行的最终一致技术,通过一个Pub-Sub消息队列来实现最终一致(即当某对象的值发生改变后会产生一个事件,然后关注这一改变的逻辑,就会订阅这个通知,并改变于其相关数据,从而实现不同数据的最终一致)。

接着由于DynamoDB无法提供SQL那样方便的查询机制,为了实现数据分析不得不又引入了EMR/MapReduceJob。

到此,大家可以看到虽然最后实现了一样的功能,但是项目的复杂性大大增加,维护工作也由一个人变成了一个团队。

过度繁忙使你落后

对于IT人而言,加班是家常便饭,“996”似乎成为了公司高效的标志。但事实上没日没夜的忙碌往往会挤压我们的学习时间,导致我们失去知识更新的意识,不知不觉变得落后,最终失去跳槽的能力与勇气。

在今天这个高速发展的时代,我在工作经历中发现过度繁忙往往会带来以下问题,首先是缺乏学习导致工作能力难以提升无法面对日益复杂的需求;其次,在技术上与业务上丧失领先优势,只能被动追赶,而被动追赶又会让我们更加忙碌,最终形成恶性循环。

个人技术的成长就像健身,仅靠锻炼还不够,营养的补充同样重要。当你在一个领域工作一段时间以后,工作对你而言就主要是实践了,随着你对该领域的熟悉,能学习的到的技术会越来越少。所以每个技术人员都要保证充足的学习时间,否则很容易成为井底之蛙,从而陷入前面提到的恶性循环。

最后,以伟大诗人屈原的诗句和大家共勉“路漫漫其修远兮,吾将上下而求索“希望我们大家都可以不忘初心,保持匠心!

【对“如何成为一名优秀架构师?Mobvista蔡超给出8条建议”发布评论】

版权及免责声明:
① 本网站部分投稿来源于“网友”,涉及投资、理财、消费等内容,请亲们反复甄别,切勿轻信。本网站部分由赞助商提供的内容属于【广告】性质,仅供阅读,不构成具体实施建议,请谨慎对待。据此操作,风险自担。
② 内容来源注明“硅谷网”及其相关称谓的文字、图片和音视频,版权均属本网站所有,任何媒体、网站或个人需经本网站许可方可复制或转载,并在使用时必须注明来源【硅谷网】或对应来源,违者本网站将依法追究责任。
③ 注明来源为各大报纸、杂志、网站及其他媒体的文章,文章原作者享有著作权,本网站转载其他媒体稿件是为传播更多的信息,并不代表赞同其观点和对其真实性负责,本网站不承担此类稿件侵权行为的连带责任。
④ 本网站不对非自身发布内容的真实性、合法性、准确性作担保。若硅谷网因为自身和转载内容,涉及到侵权、违法等问题,请有关单位或个人速与本网站取得联系(联系电话:01057255600),我们将第一时间核实处理。
广告
相关
头条
如何抓到幽灵粒子?能否洞悉宇宙历史和物理学未来? 如何抓到幽灵粒子?能否洞悉宇宙历史和物理学
宇宙线中电子中微子和中微子,它们和中微子之间可以相互转换。图片来源:IceCube/NASA……
·科学家造出世界最小的存储:其尺寸小到让人惊
·运行数年的国际空间站故障频出 许多人担心可
·如何抓到幽灵粒子?能否洞悉宇宙历史和物理学
·质量差、无端乱扣费,共享充电宝行业标准亟待
·火星赛季开启,中国天问一号准备出发带三项任
图文
热烈祝贺北京中宇豪荣获国家高新技术企业认定
热烈祝贺北京中宇豪荣获国家高新技术企业认
科技行业发展到了关键节点 全球监管不可避免
科技行业发展到了关键节点 全球监管不可避
疫情催化,“移动营销”成为企业家们的必修课
疫情催化,“移动营销”成为企业家们的必修
西安:长安区引镇土地整理项目竟成坑农工程(图)
西安:长安区引镇土地整理项目竟成坑农工程
热点
·疫情催化,“移动营销”成为企业家们的必修课
·西安:长安区引镇土地整理项目竟成坑农工程(
·武汉TCL华星光电留守员工撑不住了 强制返工引
·我在千里之外内蒙古阿拉善养了一棵树(组图)
·发现行星望舒 中国发现首颗系外行星被命名望
旧闻
·三星开发出石墨烯电池 专家:商业化还需过几
·全基因组测序检测之难 关键在怎样解读基因密
·估算:赤龙号无人飞船火星登陆计划投资3亿美
·中国第五个南极考察站选址确定:人类航海极限
·唯一一家中国企业 特斯联成为2020年迪拜世博
广告
硅谷精选
热烈祝贺北京中宇豪荣获国家高新技术企业认定
热烈祝贺北京中宇豪荣获国家高新技术企业认定
科技行业发展到了关键节点 全球监管不可避免
科技行业发展到了关键节点 全球监管不可避免
上市公司“金质量”奖项揭晓,中孚信息荣膺“科技创新奖”
上市公司“金质量”奖项揭晓,中孚信息荣膺“科技创新
软筑信息入驻南宁网易联合创新中心,推动智慧口岸建设
软筑信息入驻南宁网易联合创新中心,推动智慧口岸建设
达摩院2021十大科技趋势,一起看未来(组图)
达摩院2021十大科技趋势,一起看未来(组图)
施耐德电气:云边协同 加速布局行业新机遇
施耐德电气:云边协同 加速布局行业新机遇
关于我们·About | 联系我们·contact | 加入我们·Join | 关注我们·Invest | Site Map | Tags | RSS Map
电脑版·PC版 移动版·MD版 网站热线:(+86)010-57255600
Copyright © 2007-2021 硅谷网. 版权所有. All Rights Reserved.

硅谷网备案号:京ICP备12003855号-2