我理解的架构能力

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

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

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

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

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

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

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

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

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