前言

写这篇文章目的是之前在一篇文章中谈到，我实习那会有个老哥很牛皮，业务能力嘎嘎厉害，但是后面发展一般般，这引起我的思考，最近有个同事发了篇腾讯pcg的同学关于review 相关的文章，里面也谈到架构师的层次，也再次引起我关于架构师的相关思考，接下来我们展开聊聊吧～

摆正初心

我写这篇文章，初心是为了找到导致这样结果的原因，而不是站在一个高高在上的位置，对别人指手画脚，彰显自己多牛皮。（PS:我也鄙视通过打压别人来展示自己，你几斤几两，大家都是聪明人看得出来，如果你确实优秀，别人还打压，说明他急了，哈哈哈）

查理芒格说过一句话：如果我知道在哪里会踩坑，避开这些，我已经比很多人走得更远了。

思考结果

我觉得是没有一个层级的概念导致的，这个原因筛掉了大部分人，突破层级的难度筛掉了另外一批人，运气和机会又筛掉另一波人。

没有层级概念

为什么这么讲呢？

我们打游戏的时候，比如说王者，会有废铁、青铜、钻石、铂金、荣耀、荣耀王者，对吧。它的层级大家都清楚，但是在现实生活中，你会闷逼了，我当前处在那个阶段，上一层是什么水平，需要什么技能，什么样的要求。

其次也会对自己能力过高的评价，如果你一直在组里面，你可能一直是一把手，到了集团，可能变成10名内，到了公司排名，可能几百名后。我们需要站在一个更高、更全面的角度去了解自己的位置。

出现这种情况也很正常

举个栗子，以前我实习那会，有个老哥业务能力特别强，啥活都干得快，嘎嘎牛皮，这是个背景

如果团队里头你最厉害了，那你的突破点，你的成长点在哪里？

对吧，大家都比你菜了，自然你能从别人身上学习到的就少了，还有一种情况是你觉得你是最厉害的，这种想法也是最要命的，会让你踏步不前。这时的解法，我认为是自驱力，如果你学哲学，就知道向内求，自我检讨，自己迭代更新，别人就是你，你就是别人，别人只是一面镜子。

层级的概念

那时看到他搞业务特别厉害，但现在看是做需求厉害，但是缺乏深度。我对比以前的开发经历，跟现在在架构组的工作经历，感受很明显。一个是为了完成任务，一个需要深度，什么深度呢？这个埋下伏笔，为后面架构师层级再展开聊聊。

从初级到中级，到高级，再到主程、再到TL，技术经理，再到架构师，再到负责人。当完成任务的时候，是最基本的事情，深入的时候，从coding入手，在代码上有所追求，比如说可读性，用用设计模式，再深入想到代码可扩展性。。。

当你了解下一个层级的要求的时候，有了目标才能有效的突破它。

突破层级的难度

这是在上一个原因基础上一个加强版，你了解了各个层级的要求，但是突破这些要求，可能由于阅历，或者能力，或者天赋不足，导致突破困难。

这里我想聊聊架构师的思考，之前在转正答辩上，一个领导问我你怎么理解架构的，我当时没有概念，但是接触相关工作以及观看相关文章，有了更深理解。

• 腾讯工程师，万字长文说 Code Review

这里讲的是coding部分，属于架构师负责的一部分，规范。

我不禁想想平时什么工作内容涉及到这个？

比如说契约，规定了依赖jar版本；定义了协议，什么类型输出的格式，转换的类型；开发的规范，设计文档的样式；像文中review的过程，确实比较少，目的是为了减少代码的坏味道。就像文中讲到，如果你定义的一个规范，可以在300+人里面hold，让系统一直在正常迭代，那么算合格的架构师。

一次广义上review

我一般下班会遇到基础服务的小伙伴聊聊天，我说话很少，就喜欢听听别人聊点什么，他跟我聊了几天，我发现问题是现有商品代码已经不足以支持业务的快速迭代，因为冗余其他东西太多了。比如说一个毛胚商品，然后它也快速的加上其他属性，变成一个加工品。但是现在场景变成了它就是一个加工品，你想拆成其他加工品，很困难，就是字段冗余到商品表里头了。

这个时候到架构已经不适合业务快速迭代了，需要重构，大破大立，还需要大佬牵头。review狭义上是代码层发现问题，如果你从一线同学那里听到的东西，能发现问题，也是一种review。

架构师不止规范，需要深度

需要什么深度呢？

从一个做需求的点看，从需求理解，这个是业务深度，从设计文档上，严谨程度，扩展性、风险点、可行性，设计深度。从开发阶段，coding，技术规范，技术功底，这个是技术深度。

跳出需求的点，从大的面来看，需求为了解决什么问题，不做行不行，业务价值在哪里？做了这一期还有后续吗，这是业务的前景。然后规划是怎样的，先从哪里入手，然后有木有计划去推进？这是思考的深度。

抽象的能力

• 大咖们如何评判优秀架构师？

里面反复提到抽象的能力，比如说逻辑、物理架构图，这个有助于你理解整个系统的调用关系，形成闭环，可以从全局的角度去理解，我当前做的需求在什么位置，为了解决什么问题。

再到通过问题看到本质，从技术方案看到实质。有一次一位同学跟我探讨DDD,跟我说防腐层不应该是这样写的，你只是用了策略模式去写，应该有个一个门面，然后后面是实现逻辑。我听到这里就明白他被绕进去了，DDD是一个思想，他幻化出来一些对应的框架，它的精髓是高内聚、低耦合。你说策略模式，能否将外部rpc调用分隔开呢？当然可以，它算不算防腐层呢？也算～

最近一次做代码优化的时候，我用了责任链的设计模式，将190行的代码，拆分成4个模块，每个类大概30行，当然190行包括换行。但是实际效果除了行数变少外，每个模块分工特别清晰，这个模块在处理特定的逻辑，当某部分有问题的时候，直接找到那个模块修改即可。（这就是高内聚的魅力）

抽象另一种体现：模块化

最近在牵头做账单，其实我也没做过，我就找了几篇大厂的文章看看，拿来吧你，哈哈

分为几个步骤，下载账单，解析账单，对账，差异处理（平账）。是不是瞬间有了几个模块，文件模块，包括上传、下载，解析文件对吧。然后是账单模块，可能会分成订单，还有一些退款的，然后是对账处理结果，属于对账模块，文件解析出来的东西跟账单对比，哪些是对的上的，哪些又是异常的，这个模块还有后续的处理结果，自动平账，或者人工处理。

模块化也是高内聚的体现，这就是DDD的思想，只不过人家现在有名头而已～

运气

这个就不展开了，有点玄学，也看投胎，也看老天赏不赏饭吃。我觉得嘛，不管有没有有运气，都要不卑不亢，努力提升自己，很多结果我们决定不了的，但是过程我们可以说了算，人生不也是这样嘛，那就好好享受过程吧～

最后

《矛盾论》，还是里面的观点，我们需要全面的认识自己的定位，找到自己的优势，不断突破自我。有些厉害，只是暂时性的，而长远来看，只是冰山一角。