抽象的水平大佬们怎样评定出色系统架

序言

写这篇目的是为了以前在一篇文章中提到，我见习那会有一个朋友们很牛皮革，业务水平嘎嘎嘎强大，但后面发展趋势一般般，这造成我的思考，近期有个同事发篇腾讯官方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的观念，只不过是别人现在也有名号罢了～

运势

这一也不进行了，有点儿风水玄学，也看投胎转世，也看老天爷赏不赏饭吃。我认为嘛，无论有没有有运势，都需要不骄不躁，不断提升自己，许多结论我决定不掉的，可是全过程我们能来定，人生不都是这样嘛，那就好好尽力而为吧～

最终

《矛盾论》，或是里边的见解，我们应该全方位的认知自我定位，寻找自己的长处，不断突破自我。有一些强大，仅仅短暂性的，而从长远来看，仅仅冰山一角。