如何成为架构师?3条有效的实战经验

希望你看完这一篇,能充分认知和了解架构师,认知对了,事就好办了。

01

架构师的准确定义

架构师的职责应该是立足于技术和业务之间的中间角色或者平衡点, 在针对业务深刻理解的基础上,针对业务中存在诸多变数,挑选适合的技术架构和技术方案。

结合现有的技术团队的水平与特点,选择合适的技术架构进行落地和实现。

02

首要任务,技术的选型

当你做架构设计时,必然会面临技术选型的抉择,不同的技术方案,架构也可能完全不同。

比如架构后端语言选型,采用java语言开发,还是php语言,c#开发,ruby开发,还是python开发,还是groovy开发等。

为什么要选择这门语言?这是重点,是业务需(能快速开发发布php),还是人员需要(java开发资源多),还是未来可拓展架构需要(.net大型网站全面转型java,你还会继续使用.net么),还是技术需要(python在网络爬虫以及未来人工智能的使用场景)…

再比如移动端选型,App是纯原生开发,还是Web App,抑或Hybrid App?iOS开发,语言上是选择Objective-C还是Swift?架构模式用MVC,还是MVP,或者MVVM?

很多技术架构的选择没有弄清楚,盲选选择技术架构,不仅不有利于开发,更不有利于业务需要。

这里普遍犯错的地方就在于大部分都是半桶水,以为按照网上的经验就可以直接copy,直接搬砖过来,实则根本没有这块的经验。

再举一个例子,早期访问量巨大的.net转java,京东、携程..等等,为什么要转是一回事,怎么转是另外一回事,再比如最近某一国内最大的游戏网站.net开发,现在要转java,找了一批人,最后发现java领域精通的人,往往并不知道.net领域的问题,这就涉及到怎么转,哪部分可以转java,哪部分不能转,而不是全转,为什么?

所以,架构师在做每一个决定需要考虑诸多因素,再比如高效的技术选型需要很高的学习曲线,在工期与人员素质之间需要权衡。精妙的技术架构并不能解决业务的快速迭代和变化,技术架构都是后知后觉的,无法准确的预知业务层面的变更与方向,故只能是跟随的角色,这样就必然会面临技术架构迭代和升级的需求,技术架构从来都不是建立了之后,就无需修改,可以承载各方的多重期望。

03

其次,业务理解和拆解能力。

这一项是架构师的胜负手,大部分做IT的朋友,对业务的理解和拆解能力是比较差的,总以为把技术选型,架构搭建,技术难点发展为最核心的架构师能力。

今天,借用优知学院再次重申,这样的观点是及其错误的。没有商业,没有访问量,没有增长,没有业务需要,需要技术来干什么?关于这一点,很多同学不以为然,之所以技术这10年发展迅速,需要感谢互联网的快速发展,否则我们都失业了。特别是这一波人工智能的发展,未来基础性的开发人员肯定会锐减,为啥?根本不需要这么多开发人员,基础性开发工作,可替代性太强了。

架构师需要深入理解业务,不管是业务的流程,还是整块业务需求,甚至包括业务细节,你需要重点关注,这一点很多做需求评估的时候,架构师不参加也是极其错误的。

也有很多公司在架构升级的时候,架构师根本不懂业务,就开始独立拆分,就开始上手,拜托,业务没搞懂就上来拆解,这就跟医生没有临床试验就开始做手术一个道理。

总之,公司的架构师不懂业务,这就是扯淡。

作者简介

陈睿|mikechen,10年+大厂架构经验,大厂资深面试官,就职于阿里巴巴、淘宝、百度等一线互联网大厂。

以上!

关注作者「mikechen」公众号,获取更多架构面试干货!

后台回复架构,即可获取《阿里架构师进阶专题全部合集》,后台回复面试即可获取《史上最全阿里Java面试题总结

评论交流
    暂无讨论,说说你的看法吧