我理解的架构能力

我翻看了我的历史文章,写了不少技术相关的东西,但发竟然没有架构设计方面的文章。所以今天就来聊聊这块。

写这篇文章前,我仔细想了一遍,架构设计这么重要的东西,我怎么会一篇都没有写呢。后来我想,可能是我这么多年的工作里面,几乎没有参加过什么架构学习或架构培训等方面的事情。同事间也极少提起过所谓的架构学习等类似的事情。 我参加过不少分享系统设计经验方面的会议。但这种跟一般意义上的学习很不一样。更多是在看别人做系统的时候,是怎么想的,那个特定的场景,会有哪些坑,更多是经验的分享。 所以,可能也是这方面的原因,导致在我的潜意识里面,不存在架构学习的概念。架构能力更多是来自实践和经验。

能力本身由知识加经验融合而来。知识可以通过书本,课程等的学习习得。经验则要通过实践才能获得。代码能力,算法能力都是如此。需要边学习知识,边动手实践。相对于代码能力和算法能力,架构能力更加偏经验化。代码和算法能力,可以通过边看书,边做习题的方式提高。而且十分有效。 但架构能力用这种方式、却难有效果。究其原因,我觉得是这样的。

相对于架构设计,代码和算法逻辑上更加严密,而且容易验证学习效果。你在学习一个代码特性和一种新的算法思想的时候,你可以先看书,在理解完相应的知识点后,就可以通过自己写代码或做题,来验证自己是否掌握了这部分。这种验证是确定的,只要你的代码能跑通,结果符合预期,你几乎就掌握了这部分。但架构设计却不太行。 一来架构设计的很多原则都是经验性原则。比如高内聚低耦合,比如依赖倒置原则,都很经验性。怎么样的内聚程度叫做高,怎么样的耦合叫做低,不同的人的理解也不一样。没有统一标准的办法去判断。所以就算你理解了这种设计思路,但你也没办法验证你是否真的掌握。 当然,你可以实践,但架构设计的实践门槛是很高的。 如果你只有一个人,你至少要做个耗时几个月规模的项目,你才能从中体会到设计原则的一些好处。而且这种个人项目,所积累的经验,在多人项目中还不一定适用。 因为架构设计的重要目标,就是为了解决多人协同开发的问题。 所以要积累这块的经验,就必须要去公司了。 基于这种原因,就导致架构能力很难,甚至没办法像代码和算法那样去学习。 

一个人架构能力的高低,除了努力和天赋,还有一个很关键的点,是他历史上曾经参与设计实践的系统规模的大小。

因为架构能力,具有规模向下兼容性,向上却不行。

以互联网行业来说,曾经参与设计实践一个面向亿级用户系统的架构师,再去设计一个面向千万级用户的系统,是可以完美胜任的。但反过来,却不行。 无论是前端,客户端,后台都是一样。 例如客户端,在面向千万级用户的客户端里面,偶尔出现,不影响整体的问题,当用户规模到达一个亿后,至少会成10倍的放大,当各种问题同时出现,可能会引发更大的崩溃。这时候就需要去解决千万级别没有遇到的问题。所以面向亿级的设计要比面向千万级的设计难很多。 但反过来,就容易的多,一个拥有过亿级用户系统设计经验的架构师,在设计一个千万级系统的时候,所面对的问题,在亿级的时候都是面对过的,需要做的就是不要过度设计。具体做的时候,有点像是在亿级系统设计方案上进行裁剪。当然有经验的架构师可能很容易判断哪些点需要,哪些点不需要。在设计之初,他就已经想好了,所你看不到这么个过程。 因此也可以看到,在大公司经历过大规模系统设计实践的架构师会相当抢手,因为架构设计能力是可以向下兼容的。

所以我个人觉得,因为代码和算法能力的实践门槛低,这方面厉害的人,靠的是天赋和自身的努力。 而架构设计能力,除了自身的天赋和努力外,还要外加一些运气。 如果在你的职业生涯里面,没有遇到好的规模大的项目,你就没办法进行这块的实践,自然也没办法拥有这方面的经验能力。

以上,是个人对架构能力的一些想法。可能不同的人,有不同的理解吧。不过架构能力确实是高阶技术人员很核心的竞争力。想在技术领域有长远发展的同学,一定要关注这块。 最后,这篇没有介绍架构能力提升等方面的内容,后面找个时间再来写写这块的内容。

猜你喜欢

转载自blog.csdn.net/zl1zl2zl3/article/details/88760792
今日推荐