架构师成长系列 - 能力认知（3）

之前写了关于认知的两篇文章。感觉写的还是不够透彻，可能很多人看不明白。

我决定还是再次用比较详尽的一个例子，和我给别人one by one中聊到的认知成长部分来再次说明一下这个问题。

在我的成长路径中，认知是非常非常重要的。所以我争取把这个问题聊的透彻一点。

需要强调，成长绝对不是只有一条路径的。我分享的，也只是我的成长经历。

到底啥是认知

认知，其实很简单，就是我们对客观事务的感知，知觉能力。处理能力。好像有点偏哲学。

具体来说就是我们是怎么看待一个客观事务的，怎么定义一个问题的，然后我们思考的方法是什么，我们的处理手段是什么。

比如，我在腾讯的面试里面说道过：我研发效率极高，有效代码行和代码贡献度是其他人的三倍。

那么我们怎么看待我这句话的描述呢？

可以思考

1. 单纯的就是写代码能力很nb。

2. 用代码行来评价研发效率是很蠢的一件事情。

3. 代码贡献度是别人的三倍无法说明能力很强，没办法证明。可能就是写代码的机器。上面都是对于这句话的认知，每个都代表我们学习到不同的知识之后就有新的见解了。可能有人学了软件工程管理，所以知道“代码影响力模型”可能就知道不同的评价方法。

我这里介绍一个：辩证思维-对立与统一。

假如我真的是一个及其高效的开发者，有什么坏处吗？

很容易想到：越高效的开发者，越喜欢亲力亲为。越难以扩大团队规模和团队协作。

因为别人可能需要一个星期，我自己一个人一天就搞定了。

所以当时我老板评价我说，我是一个极强的独立贡献者。所以他需要给我安排一个10个人才能完成的任务，让我感受到个人力所不能及。我当时没有理解到这点，所以当年325了。（也可能是pua）

我用这个例子想说明，我们有了一个新的知识之后，就会有一个新的思考维度。

比如：哪怕是典型的优点，那么背后也一定有一定的缺陷。

关键不是缺陷是什么，关键是我们有了辩证思维之后，遇到一个事情，一定会从正反两个角度去思考

上面就是想再次说明，什么是认知，有了不同的知识之后，我们看待世界的角度就不一样了。

要成长和培养这个能力，就需要时刻思考一下，我可不可以从另外的角度来看待这个问题？

现在想想，中国古人说：福兮祸之所伏，祸兮福之所倚。也是非常辩证和多维的。

接下来，我会回到架构认知部分。通过两方面来解释一下我们怎么培养体系化，知其然知其所以然的认知能力。

登录系统

我在学习java的时候就写过登录系统，因为这个很典型。

这个简单的小功能，会涉及到从前端到服务器，后端，DB一些列的知识。我们以典型的一个BS架构网页登录为例

1. 需要学习html能力，写一个最简单的用户名，密码框和按钮

2. 需要学习JS能力。知道比如一些ajax的技术。发起对服务端的请求。

3. 需要知道一些web容器的技术，比如tomcat。

4. 要写一个登录功能服务端，可以直接用servlet。或者干脆springMvc，spring，mybatis。

5. 写建表语句，写sql，要进行服务器访问。这个时候还需要注册功能。

这是一个初学者对于“登录系统”的全部认知，这里会遇到很多的框架和技术，比如前端框架，spring，web容器，数据库。等等这些技术知识，当学习完毕了之后，我们就可以写出来这样一个登录注册功能。

当我们有不同的知识，这个问题会发生什么变化？

我们可以按照广度来思考这个问题。

比如如果是一个大规模业务处理系统的登录，那么一定是分布式系统的。其他的不聊，我们的知识就多了一个Nginx。需要对服务器做负载均衡。

进一步，我们需要对业务进行一定的水平拆分。

如果我们是一个多个网站的业务，那么这里又涉及到全局单点登录SSO的问题。我们又要学习cookie跨域，登录状态共享，session共享，分布式session等等的知识。

我们也可以按照深度来思考这个问题。

比如，我现在有数十亿的用户需要登录了。其他的条件都不变。怎么做？

可能我们要进行数据拆分，那么就又有数据路由。如果是上万的QPS呢？如果是登录的RDS校验呢？

这里具体的功能就涉及到方方面面。

上面，就是一个典型的初级程序员到高级程序员的认知变化 就是我们对于“注册登录功能”这个问题的看待角度不一样，我们看到了更多的技术框架需要使用，我们看到了更多的功能和业务场景。

让我们继续

当我们慢慢设计到一些“架构”的知识了之后，这个问题会发生什么变化吗？

首先，架构，一定是解决具体问题的。比如，大型电商系统里面的登录。

这个时候存在特别多的业务模块，都需要登录校验，并且用户维度上有非常多的标记状态，比如冻结。

用户也存在多个维度的账户：手机号，用户名，邮箱，身份证。

如果所有的业务系统都自己写登录，或者直接连接用户DB，那简直不可以想象。

这个时候，我们需要独立一个用户服务，让别的业务系统来调用，并且需要配套的建立一个独立的系统，可以单独的部署。

那么架构师，就需要围绕用户模型，设计用户服务：注册，登录，鉴权，打标，查询等等。

这里面涉及很多的架构方案涉及，比如一笔电商业务，用户服务可能被调用几十次（因为每个系统都需要通过uid查询用户信息）。那么极高的并发如何处理。

又比如，用户ID是需要全局唯一，那么分布式ID的技术方案是如何处理。

上面是技术难点和标准技术方案的设计。

还有没有别的维度呢？业务复杂度。

如果公司是多个app的一个大型集团，比如我们有盒马会员，有天猫会员，有淘宝会员。如果想做会员中台，那么我们怎么进行业务的划分和隔离？会员体系如何打通？

这里就涉及到非常复杂的业务架构部分。

而业务架构部分，不是具体某个技术框架就能解决，是需要我们进行架构设计 此时我们对于问题的看法和处理方式，就从技术框架，延伸成了架构设计。这样，就迈出了架构师的第一步了。

让我们继续

上面从技术复杂度，和业务复杂度分别解释了，我们对于这个“注册登录”功能的不同看法。

那我们还可以继续吗？用之前说的，多问一个why的方法。

我们可以问：我们公司，为什么要做登录功能？

所有的问题都可以问一个为什么，当我们问了这个之后，可以还原业务本质，直面业务的核心。这样才能更好的理解业务处于什么阶段，会往什么方向发展。

架构，至少一半是面向未来的架构，如果业务不发展，那么一定不需要做新架构

当我们的认知扩展到，为什么要做登录功能之后，我们可能会有接下来一系列的发现。

比如，因为公司要有会员系统，因为一个app的注册会员和会员活跃度，是公司的核心业务价值。如何能够转换会员到GMV或者转换会员进行盈利，就是公司核心目标。

那么我们问题的答案也就不一样了。如果我们仅仅是做用户到盈利的转换，是不是就不需要登录系统了？

其实很多很多的小程序都开始这样做了，当我们发现这点之后，也会知道授权登录，就是我们发展的方向。整体的匿名用户转换也是我们提高业务转换率的一个方向。

我们的认知，就发生了不同的转变。

简单总结一下，我们可以横向思考和纵向思考我们的工作内容。

横向：业务维度和业务场景的扩展。比如电商到社区，到生鲜。用户登录系统到分布式，sso等等。

纵向：分技术深度和业务深度。技术深度需要我们处理更有技术挑战的内容，需要我们把技术做深，比如用户量级一个亿，十个亿。我们的方案是不一样的。

业务深度，是思考业务本质，思考公司为什么要这么做，这么做怎么赚钱，通过业务深度的思考，转变成我们对于未来架构的判断

以上这个例子，就是让大家理解，我们对于认知是怎么定义的，是通过哪些不同的思考方法来帮助我们成长的。

工作中成长

我在上一篇文章中具体介绍了三个小方法：抽象，分层复用，业务本质。

并且在用户登录系统里面，其实也分别解释了我们怎么进行抽象，怎么在架构层面上进行分层（技术方案和业务架构），还有最后的，登录系统的业务本质分析。

接下来，我介绍一些在工作中，我们可以尝试去做的事情，可以帮助我们成长。

要了解全貌

不管我们是做什么业务，哪个公司的开发。一定一定是在某个业务系统里面研发的（或者项目project）。我们需要了解这个系统的全貌。

比如一个系统十个人负责。我们需要知道其他人在做的需求功能是什么，我们负责的系统支撑的全部业务场景有哪些。

通过这种方法，我们就可以知道当下这个“系统”所有的业务场景，业务场景就是我们架构要解决的问题。架构最终还是要为业务负责的。

如果是非常厉害的IC（独立贡献者），可能一个人就维护一个系统，或者几个系统。那么需要扩展一点视野，看看自己的系统最终是为什么业务服务的。这些业务是怎么赚钱的。是怎么产生价值的。

基于全貌做抽象

我在上一篇文章中说，我们在工作中尽量写代码的时候写的“抽象”一点，尽可能多的给别的业务功能也使用到。

这样做了之后很多人会问我，有的时候是不是过度抽象了？也经常有人问我，如何判断是不是过度设计？

我的回答一般是：问这个话的人，既不懂“过度”，也不懂“设计”。

在我的理解里面，什么叫“过度”？

我认为架构是有发展阶段的，如果越过下一个阶段，做出和当前业务发展阶段不match的架构，就是过度。

什么叫“设计”？

设计是基于我们对业务当下阶段的理解，以及对未来发展判断，做出抽象定义以及职责划分的方案。

那么按照我的这个理解，“过度设计”这个问题的答案也就出来了。

我们要清晰的了解业务和架构的发展阶段，我们要基于我们的业务视野进行架构抽象。

如果能清晰的定义以上两个方面的事情，有的时候“过度”，有可能是有意为之的。

从上面我的定义来看，我们的“抽象”和设计，一定是我们了解了别人在做什么事情，才能抽象出来别人也能用功能。

抽象不是写个泛型，或者用什么反射+配置的方式支持某个功能，这种往往是技术通用化。

抽象，是某个语义维度的上升。

基于业务发展判断做分层定义

上面一段，我简单聊了一下我们尽量通过抽象，把自己的功能写的通用一点。能够支撑别的业务场景。

随着我们做的越来越多。会发现“一组”功能的复用。这“一组”功能，往往就需要分上下层来定义。

这样就能够尽最大的可能进行复用度，把我们代码功能从加法，变成乘法。

但是在一开始接触分层定义的时候，我们该怎么判断呢？我的建议是根据业务发展判断。

比如最典型的三层架构：controller，service，dao。

这是一种按照功能职责分层的，也可以认为，我们可能需要更换DB服务，这样就不用修改service层了。

“更换db服务”，就是我们针对性的对于未来的判断（虽然往往不会更换）。但是对于不同的分层，就可以基于未来能力扩展的部分进行分层定义。

比如我们登录注册服务，核心部分是用户模型，围绕用户模型的CRUD。但是如何创建用户就是一种服务，可能是根据第三方登录，手机号快速注册，账号密码注册等等模式来的。这些就非常适合划分成不同的分层定义（或者多个模块服务）

以上就是我对“认知”，以及在工作中我们围绕认知这个维度怎么进行成长的经验。说白了也简单，大家没事多想想。