ICode9

精准搜索请尝试: 精确搜索
首页 > 其他分享> 文章详细

架构师成长之路:如何提升技术掌控力?

2020-02-21 14:40:11  阅读:242  来源: 互联网

标签:掌控 架构 功能性 业务 成长 技术 产品 架构师


简介: 在很多人眼里,架构师就犹如古代的将军一般,既能运筹帷幄决胜千里,又能独闯敌营取人首级,是所有士兵们崇拜的偶像...好了,其实我只是想说:能成为一名优秀的架构师,确实是所有工程师的梦想。那么,架构师应该具备什么能力呢?

聊聊自己

前几天看到阿里云小编姐姐在群里抛出了《架构师成长之路》这个专题,其实蛮开心的,因为我终于可以“被迫”总结下这些年的经验了,所谓压力才是生产力,偶尔对自己施压总结,提升最大的还是自己,假如读者也能从中有一点收获,那我大概是赚翻了:-)

在这之前,我先卖卖自己。

我大约10年前入行,一直从事软件开发类工作,以Java技术栈为主,偶尔用Node,其他技术也略有涉及。期间做过各式各样的产品,包括但不仅限于政务、电商、教育、社交、金融及区块链等等。18年出版过一本技术书籍《Akka实战》(机械工业出版社),今年也可能会出一本译作。我目前坐标上海,担任多家公司高级技术顾问,提供技术分享、培训和咨询等服务。同时今年也非常荣幸,被授予阿里云最有价值专家(MVP),希望能在自我提升的同时,也带给大家一些有价值的思考。

我算是一个典型的白羊座,以及非典型的工程师。为什么这么说呢?因为我多多少少有点冒险精神,也擅长折腾,中途曾多次尝试过创业,有的是自己主导的,有的是跟随合伙创业,但无论怎样,都一直没有脱离技术圈。在任何组织里,都是以技术负责人或者架构师的角色存在,算是见证了多个产品从0到1,然后从1到100的成长过程。在这个过程中,无论是研发体系还是业务体系,甚至HR体系,都会快速发生变化,正是因为我亲历过这些变化,才使得我能以业务全局和团队整体情况来考虑技术架构问题,而不会从最开始就陷入技术细节之中。

我是一个非常喜欢写作和分享的人,这算是我迄今为止养成的一个最重要的习惯。互联网行业发展太快,要学习的东西非常多,我们每天都能接收到来自四面八方的信息,仅依靠大脑来做瞬时的过滤分析,已基本不可能,甚至会出现思维钝化的情况。写作,可以让自己内心平静,对信息进行有效去噪,然后将所思所想真实的记录下来,形成自己的知识财富。同时,分享给其他人,看起来是帮助别人,但可能会因为收到有价值的反馈,反而提升了自己。所以说,分享者往往是最大受益者,正如我写本篇文章一样。

回到架构师成长之路这个话题,在很多人眼里,架构师就犹如古代的将军一般,既能运筹帷幄决胜千里,又能独闯敌营取人首级,是所有士兵们崇拜的偶像...好了,其实我只是想说:能成为一名优秀的架构师,确实是所有工程师的梦想。架构师这个title,没有一个统一的标准,大多数都是公司内部按照一定职级设定的,甚至有的工程师一直在做架构师的事情,但仍然没有架构师的title,这都很正常。我相信大多数人不是为了混title才想当架构师的,最终还是希望自己能达到架构师的能力级别。那么,架构师应该具备哪些能力呢?基于我近几年来的一些血泪经验,大致总结出了下面几点:

1.有扎实的技术功底,对底层有庖丁解牛的能力;
2.对领域内的技术栈有全面的了解,能做合理的架构评估;
3.对新技术敏感多情,并能预判其引入风险;
4.有较强沟通、学习、分享、协作能力;
5.有较强业务分析能力,深刻理解业务及产品价值;

大家会看到,这里面大概有一半儿与技术有关,另外一半儿纯属软技能,这些都非常重要。我们以前评价一个技术牛人,都会以【技术实力】强来描述他,但实际上,作为一个架构师,技术实力只是他能力模型的一部分,我认为,一个更能描述架构师能力的词汇应该是【技术掌控力】,上面列的这5点,其实都属于其范畴。本篇我们主要看看,什么是技术掌控力?以及如何提升技术掌控力?

什么是技术掌控力?

大家都知道,技术实力是架构师安身立命的基础,也是你的同仁或朋友对你打的最重要的一个标签,你在团队内的影响力大概率由你的技术实力来决定,假如在技术上有明显问题,那么在这个团队内基本上没有未来。那么,技术实力是怎么体现的呢?我这里简单列出几个常见对话,大家可能一看就明白了:

“张某某的算法写的真好哎,技术牛人一枚啊。。。”

“李某某刚才解决了一个并发问题,技术真牛逼啊。。。”

“王某某刚采用了一个新的中间件,一下解决了耦合度过高的问题,膜拜一下。。。”

不得不说,这三个人的技术实力肯定是不错的,他们都能在自己的方向上解决产品上的问题,但是,假如要做一个优秀的通用型架构师,仅仅在某一方向偏科是不行的。架构师不仅要能在某一方向上做到顶尖,更应该【对领域下的技术栈有全面的掌控力,并有能力通过技术手段让业务及产品发挥出最大价值】,这里的领域可以理解为当下要做的事情,比如产品、方案、系统升级等。说的更具体一点,所谓【技术掌控力】,大致包含两个方面:

1.从技术层面来说,能够对各类技术方案的核心底层逻辑有非常清晰的了解,然后根据实际情况进行架构评估(比如易用性评估、扩展性评估、替代方案评估、风险评估等等),最终做出一个最合适的架构方案。

2.从业务和产品层面来说,能时刻关注业务产品发展现状,以及预判未来发展趋势,进而动态的、持续的调整和完善架构方案,通过技术手段,实现业务产品的最大价值。

所以说,技术掌控力,是技术实力的全方位升级,是更加全面的一种能力。笔者认为,工程师假如要往架构师方向发展,应该将技术实力进化为技术掌控力。

至于如何提升技术掌控力,笔者有下面一些看法。

苦练内功

很多工作几年的工程师,在精通CURD之后,往往会陷入技术上的停滞状态,
这时候可能会出现两个极端:
1.由于没有学习目标,所有学习想法只停留在脑袋里,最终出师未捷心先死;

2.由于学习目标太多,频繁在各个技术领域来回划水,最终弱水三千一瓢都没取到;

老实说,每个人都可能会在某段时间内突然失去目标感(没有目标或者目标太多),包括笔者自己,每个月也有那么几天是这样:-) 

其实这个时候最好的做法就是去苦练内功,就好比你打篮球一样,当周围全是防守人员,挡住了你传球的思路,什么都做不了的时候,那么最好的做法就是:拼命往球框的方向扔就完事儿了,进不进无所谓,至少方向是对的吧...而苦练内功,绝对是最正确的方向。

不知道大家爱不爱看武侠,在武侠中,内功是所有绝学的基础,只会招式而内功缺乏,战力非常有限。比如《射雕英雄传》,主角郭靖武功盖世,人人敬仰,是我们年少时的偶像。那么他的武功是怎么一步步达到顶尖的呢?郭靖在年少时,由江南七怪教他练一些拳脚功夫,以招式为主,内功基本没有,打打小流氓不在话下,假如遇到高手,肯定会输的吐血,会再多的招式也没用。后来,全真派马珏传授了2年全真内功,武力值一下提升了数倍,这才为日后练习降龙十八掌打下坚实基础。假如没有内功基础,我想洪七公肯定是不会贸然将此神功传授于他的。包括后来学会老顽童的空明拳、以及被骗学会九阴真经,都是因为他有强大的全真派内功基础。

其实在技术领域,道理是一样的,技术领域的底层基础,既是内功。对于工作两三年的工程师来说,想入门一个新的编程语言、框架,其实都非常简单,搭建完环境,跑跑demo,看看API,相信一天内能完全搞定。但是,你要开发生产级别的产品,你会发现,以前用A框架要面对的问题,用B框架也仍然需要面对。就以最常见的并发、GC这类问题来说,只要你用Java,采用任何框架都是逃不掉的。而这类问题,就属于内功问题,一旦内功提升,哪怕用最简单的招式,也能解决很多问题。同时,学习其他新技术的时候,也自然可以融会贯通。

在我看来,练习内功(底层基础)其实是蛮简单的一件事,大部分情况下,你不需要依赖其他环境,比如说学习并发编程,直接打开IDE就可以开始做了。再比如GC,只需要配置几个启动参数,学会几个命令,就直接可以开始看了。相对于其他各种大而全的框架技术来说,它对环境的依赖程度非常低,提升效率非常高。

所以,当大家不知道学什么,而又想提升自己的时候,练内功吧,成长速度比自己想象的要快,We can do this all day...

对技术敏感多情

以前在面试的时候,我经常会问候选人几个额外的问题:

1.你会经常逛什么技术社区嘛?哪些社区?
2.最近有哪些想了解的新技术?
3.你关注了哪几个技术类的公众号?
4.最近读的一本技术书籍是什么?(偶尔还会问下对方作者是谁?)
5.最近技术圈儿有什么八卦没?
6.......

之所以会问这些问题,主要是想考察候选人是不是经常关注IT圈子,对一些新的技术或技术牛人有没有过了解,我认为,哪怕是天天在社区里面灌水或者搞八卦,也比什么都不闻不问强。可是,很多工程师自诩热爱技术,却连技术社区都不逛,对新技术新名词一无所知,让人如何相信呢?

我认为,工程师一定要对新技术保持敏感,“花心”一点。每种新技术的出现,肯定是为解决当下问题而出现的,虽说解决问题的方式有很多种,但最终肯定有一种最优解法,对新技术理解的越多,在做技术选型时就会越从容,更易做出最优选择。我们经常说,要学习一门技术,得通过项目实践才能真正掌握,这是一句正确的废话。很多时候,你想要学习的技术,并不一定会在实际项目中采用,你能做的,只有自己创造Demo场景,然后编写各种测试代码进行研究。笔者在工作的前几年,也经常抱怨不能通过实际场景学习新技术,然后心安理得的拖着不去做研究,以至于在遇到真实案例时,只能边学边用,出过很多严重的生产问题,后悔不已。

所以,大家要尽早放弃用生产案例供自己学习新技术的想法,任何机会都是留给有准备的人的。

学会识别风险

虽说我们要对新技术保持敏感,但是在真正选型时需要格外慎重,有句话说的好:大胆尝试、小心求证,我觉得放在这里非常合适。有很多新技术,虽然能解决现有的问题,但是也可能带来新的问题,所以很多时候,工程师都是在不停填坑,然后挖坑,最后继续填坑的反复循环中。作为架构师,需要识别任何新技术带来的风险问题。

这里举一个笔者之前经历过的一个小例子。当时有个老产品,除了做运营活动时会出现一定的性能波动,其他时间一直平稳运行。团队中某工程师发现,之所以会出现性能波动,是因为在订单处理时同时会做一些积分、赠券相关的计算,当量大的时候,计算量水涨船高,占用了极大的资源,也会导致更长的延迟。该工程师提议,可以在订单处理时引入MQ,将订单更新成功的消息发往一个计算服务去执行,这样不仅使订单落库的更快,还解耦了这块的复杂逻辑。老实说,这是个非常好的方案。但是呢,仔细思考,这个做法会带来下面的风险:

1.引入MQ中间件,势必要保障MQ的高可用,假如出问题了怎样?运维是否有能力hold住它;

2.万一发现RabbitMQ存在问题,RocketMQ能不能在尽可能少改动代码的情况下进行快速替换;

3.计算服务独立出来,需要增派人手进行开发(人是否够?),并且也需要纳入运维的日常巡检管理;

4.计算服务既不能少算,也不能重复计算(幂等性),可靠性要非常强;

5........

当然,这里面还有很多细节问题,不再一一列出。由于这确实是个好的方案,所以最终采纳并完成实施,在解决完这些风险后,顺利上线了。顺便说一下,第1、2个问题,由于考虑到当时团队现状,直接上云保平安了。

所以大家看,即使这么一个看起来非常简单的方案,也需要考虑很多问题才能最终执行。笔者一直认为,能有效识别风险,是架构师技术掌控力的最佳体现。

关注非功能性需求

应用程序一般包括两类需求:功能性需求和非功能性需求。功能性需求是指应用应该实现的业务功能,这类需求一般由产品经理提出并形成PRD。非功能性需求是指应用的性能、维护性、扩展性、可靠性、以及高可用等运维保障性需求。本质上,我们做架构,大部分时候都是在做非功能性需求,这是架构师最重要的工作之一。

现实情况是,Boss或产品经理往往只会关注功能性需求,它们最常见的说辞就是:我要加个这么小的功能怎么这么麻烦?老实说,我理解他们,因为站在他们的角度,都是以业务实现来看待研发问题,能把功能性需求的逻辑整自恰了就已经很好了。而作为架构师,此时的价值就需要体现出来,不能完全被动接受纯功能性开发的需求,老实说,即使你用最糟糕的语言、最糟糕的架构,你都能实现Boss给你的任务,但是一旦产品稍微有点起色,就免不了完全推倒从来的风险,最后不仅给自己和团队挖坑,还会对公司造成损失。有的工程师可能会吐槽,产品开发周期有限,功能性需求都可能做不完,非功能性需求更加没空做。确实存在这种问题,笔者认为,即使由于deadline太紧而无法顾及更多非功能性设计,也应该在整个架构设计文档和开发文档中加以说明,这是作为“技术负债”的一部分,是需要给产品或者Boss详述报告的。除了让他们对当前产品有个合理的预期之外,也给团队以后“还债”预留时间和空间。顺便提一句:假如永远没有还债的机会,可能公司并不需要一名架构师:-) 

我们工程师很容易进入一个误区,那就是总觉得只有大一点的产品才需要考虑非功能性需求。实际上,不同阶段的产品有不同阶段的非功能性需求。比如说,很多互联网公司的产品,特别是创业阶段的产品,都遵循MVP(最小可行性产品)策略,即用最短的时间内完成最核心的功能,然后小范围投入市场进行反馈收集,并持续迭代。这种产品开发形式,虽然不考虑高性能、扩展性等问题,但是仍然需要考虑快速迭代、快速发布、稳定性等问题,否则用户会吐槽“你这款产品本身就已经极简了,不仅发新版慢,还各种卡死闪退”,好不容易积累的种子用户也会消失殆尽。随着产品不断发展,非功能性需求会原来越多,工程师需要关注更多更复杂的非功能性需求,比如考虑性能问题、服务或数据拆分等问题。假如一直坚持下去,不仅可以持续为产品发展带来价值,自己也能得到很大的提升。

学会交流与分享

在我入行的时候,经常听求伯君当年单枪匹马一年多,写出了WPS的传奇故事,总是感觉热血沸腾,不能自已。在那时候,我心里的技术大牛,就像武侠中的世外高人,他们独来独往,身怀绝世神功,但不为外界所知,而一旦横空出世,必定威震武林。事实上,在几十年前的IT行业,确实存在着大量顶尖高手,他们以一己之力推动者行业的发展。那个时候的高手们,是孤独的,就像求伯君说的:“有了难题,不知道问谁,解决了难题,也没人分享喜悦。”。

不过,IT&互联网行业发展到现在,已经不是当初的样子了,应用的复杂度急剧上升,靠单打独斗已经搞不定了。过去之所以个人英雄主义更多,其实是因为信息传播能力、交流协作工具等受限,人与人之间基本是信息孤岛,不像现在,有Github,各种社区、甚至微信群,可以很方便的进行交流协作。

事实证明,当信息传播能力越强,交流协作工具越来越高效,IT行业的整体水平都有更快发展,以Github为例,它吸引了全世界最知名的互联网公司,以及最有创造力的工程师群体,最终产出了最顶级的开源软件,为整个IT行业的发展做出巨大贡献,这是集体智慧发挥到极致的典型案例。

作为工程师个体来说,我们不应该故步自封,关起门来搞建设,而应该多和外界交流学习,无论是社区、行业大会,还是高质量的微信交流群,直播群,都可以尽可能的去参加,以吸取大家的集体智慧,这对增强行业见识,拓宽技术视野都是很有帮助的,当然了,假如能持续在Github上 show your code,那肯定是最高级的交流方式了:-) 

笔者一直相信,人的精力非常有限,不可能所有技术都能完全精通,在我们自己冥思苦想仍不得解的时候,可能别人的一句话就点醒了自己,反过来也一样,这些都在笔者身上时有发生。老实说,以前的自己,也不太喜欢和人交流,内心总有点小傲气,总觉得人家讲的都是XX,有那么一点“技术相轻”的意思,而自己想去和别人分享心得吧,又抹不开面子,生怕自己讲不好,毁了自己的人设。直到后来,因为做了一次讲师,我才改变了这个观念。那是我人生第一次受邀做分享嘉宾,对方是一知名外企。第一次嘛,我亚历山大,也格外认真,在准备内容的过程中,竟然把我有关该主题的一些不起眼的盲点全部扫清了一遍,当时我就两个感觉:
1.这次分享我收获最大,这么爽的事儿以后不要钱都干啊;
2.分享的讲师之所以有底气站在台上,肯定是掌握了听众不知道的东西;

所以可以看到,无论是当分享者还是当听众,都是会有很大收获的。这里特别提一下,假如大家在公司内外都能做几场成功的分享,你自身的影响力也会逐渐提高,然后对很多事情的掌控能力也会越来越强,这对自己未来的职业发展是有很大帮助的,至少,你可以来申请阿里云MVP,对吧:-)

关注产品与业务

笔者和很多工程师一样,早年间只迷恋技术,对业务开发非常排斥,对业务的理解仅限于最基本的逻辑,对业务功能所能带来的价值更是不了解,让我理解用户?对不起,我可能连用户是啥群体都还没摸清楚。所以在头几年里,总感觉自己一身武艺,却没有发挥的地方,实际上是自己“作妖”导致的。后来在积累了更多开发经验后,就发现,假如对业务的理解有偏差,做出来的技术架构,开发出来的产品,基本上都是“不良品”,正是印证了那句话:虽然懂得很多技术,但仍然做不好架构,原因就在于此:-) 

以笔者看来,IT行业对架构师的业务理解与分析能力的要求是越来越高的。以往有很多人,把架构师分为技术架构师和业务架构师。技术架构师,通常负责做好技术选型、搭建技术框架、攻克技术难点等工作。而业务架构师,通常负责平台架构、产品规划、领域模型等工作。但实际上,技术类架构师越来越需要拥有业务架构的能力,因为技术肯定是为业务服务的,他需要对实现业务价值做出自己的贡献,而脱离业务场景谈技术架构纯属耍流氓。

举个最常见的例子,大家现在都在讨论微服务架构,我们都知道微服务化是有诸多好处的,比如提高可扩展性、可维护性、资源利用率等等,这是会对产品带来长期价值的非功能性需求,是每个架构师都想做好的一件事。其实做微服务,最难的点已经不是技术栈了,毕竟SpringCloud、Dubbo这类框架已经非常易用了。最难的实际上是领域模型、服务拆分等问题。什么叫领域模型呢?这是DDD(领域驱动设计)中的常见词汇,它是指通过业务需求建立的具有统一术语的业务实体模型,它指导着程序的开发实现,同时,DDD中的另外一个概念叫限界上下文,对它的识别可以有效解决微服务拆分的问题。而这些概念,都与业务息息相关。所以说,假如对业务分析不足,是不可能做好微服务架构的。

笔者平日里也经常和众多研发团队负责人进行交流,大家有个共识就是:假如某个小团队里存在一位只追求用新技术或所谓“底层”技术而对业务完全不care的架构师,是非常容易出问题的。而且说句可能会被喷的话,对于大部分中小互联网公司来说,业务发展的规模可能还远远不到拼技术(我是指硬核的那种)的时候,这些公司架构师产出的,其实是业务产品。更何况,由于云计算的普及,有很多以前看起来“高高在上”的技术,已经完全达到开箱即用,便利性犹如水电煤一样。当然,这倒不是说技术无用,然后大家转型去做业务专家算了。技术实力仍然是架构师最重要的能力,但是,我们不要忽略业务领域知识的重要性。时常关注业务与产品,不仅对当前架构的合理性进行有效评估,还能够让自己对产品未来发展有个更好的预判,以便提前做出合理的架构规划,笔者认为,业务与产品的深入理解,其实也是【技术掌控力】的一部分。

最后,送给大家一句话:技术能力将决定你能走多快,而产品(业务)能力将决定你能走多远!

阿里技术官方号 企业博客 发布了272 篇原创文章 · 获赞 907 · 访问量 46万+ 私信 关注

标签:掌控,架构,功能性,业务,成长,技术,产品,架构师
来源: https://blog.csdn.net/alitech2017/article/details/104427179

本站声明: 1. iCode9 技术分享网(下文简称本站)提供的所有内容,仅供技术学习、探讨和分享;
2. 关于本站的所有留言、评论、转载及引用,纯属内容发起人的个人观点,与本站观点和立场无关;
3. 关于本站的所有言论和文字,纯属内容发起人的个人观点,与本站观点和立场无关;
4. 本站文章均是网友提供,不完全保证技术分享内容的完整性、准确性、时效性、风险性和版权归属;如您发现该文章侵犯了您的权益,可联系我们第一时间进行删除;
5. 本站为非盈利性的个人网站,所有内容不会用来进行牟利,也不会利用任何形式的广告来间接获益,纯粹是为了广大技术爱好者提供技术内容和技术思想的分享性交流网站。

专注分享技术,共同学习,共同进步。侵权联系[81616952@qq.com]

Copyright (C)ICode9.com, All Rights Reserved.

ICode9版权所有