还在为如何成为优秀架构师而苦恼吗?近日,汇量科技(Mobvista)集团副总裁兼首席工程架构师蔡超做客QCon+案例研习社线上发布会,为我们带来了答案。
图片来源于Mobvista
蔡超拥有17年软件开发经验,其中有超过10年在HP、Amazon等世界级公司任职软件架构师/首席架构师。先后领导开发了网络安全管理系统(TopAnalyzer)、HP(中国)移动设备管理系统、亚马逊全球的新外部直运(ExternalFulfillment)平台、亚马逊物流+系统、亚马逊全球客服系统以及大型弹性集群管理平台SpotMax等。基于多年实战经验,蔡超总结并分享了他在架构师成长之路上的8大窍门,为同行们带来更多思考。
右1为汇量科技(Mobvista)集团副总裁兼首席工程架构师蔡超
以下是蔡超的分享内容:
到现在我工作17年了,期间不仅在HP,Amazon这样的世界级团队中担任过架构师,也在汇量科技这样快速成长的企业中担任过技术领导。基于超过十年的架构师工作经验,我将和大家分享一下这些年的成功与失败,希望能帮助大家避开那些我曾踩过的坑。
“提出问题”难于“解决问题”
作为技术人员我们往往习惯于给出设计方案,做一个问题的解决者,而很少做一个问题的提出者,去思考要设计什么。团队中最常见的典型矛盾是产品团队和研发团队的矛盾。作为研发团队,我们常吐槽产品团队的需求不合理,不懂技术等。
其实我们可以尝试把自己的工作在往前移一下,不仅仅是去设计架构实现产品的需求,而是去实现客户的需求,甚至发现潜在需求。
变成在设计上提出问题的人后,你会发现提出问题同样需要深入思考,设计一个好的问题,有时候甚至比解决问题更难。
即便是软件开发领域的大神FrederickP.BrooksJr.(《人月神话》的作者)也会有同样的感叹,“Thehardestpartofdesignisdecidingwhattodesign.”这句话便是出自他的《Thedesignofdesign》。
决定“不要什么”比“要什么”更难
也许是由于人性的贪婪,对于软件系统我们同样想要更多:更多功能,更好的性能,更好的伸缩性,扩展性等等。作为软件架构师要明白软件架构设计其实是一种取舍或平衡。当大家都在往里面加东西的时候,架构师更应该来做这个说不的人。
软件设计和定义过程中存在很多取舍,如完善功能和及早发布的取舍、伸缩性和性能的取舍等。如何做好取舍?著名的CAP原则就是一个很好的关于取舍的指导策略。为保持架构风格的一致性,在一开始架构师就应该根据系统的实际需求来定义一些取舍的原则,如:数据一致性拥有最高优先级,提前发布核心功能优于完整发布等。
非功能性需求决定架构
很多设计人员可能会认为架构是由要实现的功能性需求决定的,但实际上真正决定软件架构的其实是非功能性需求。因此,架构师需更加