「阿里技术」微信公众号 钉钉扫码进开发者社群

    扫一扫二维码图案，关注我吧技术人具备“结构化思维”意味着什么？ 1

    优秀工程师必备的三大思维，你拥有哪些？ 11

    优秀工程师必备的一项技能，你解锁了吗？ 18

    如何在工作中快速成长？致工程师的 10 个简单技巧 39

    技术三板斧：关于技术规划、管理、架构的思考 62

    程序员如何自我学习？阿里资深技术专家这样做 67

    从计算机知识到落地能力，你欠缺了什么？ 77

    阿里资深技术专家的 10 年感悟 90

    如何量化考核技术人的 KPI？ 98

    如何成为优秀的技术主管？你要做到这三点 104

    在阿里做了五年技术主管，我有话想说 121

    如果我是一线技术主管…… 141

    目录阿里工程师的自我修养 < 1

    技术人具备“结构化思维”意味着什么？

    作者：张建飞 高级技术专家

    阿里妹导读：在日常工作中，我们时常会碰到这样的情况，有的人讲事情逻辑非

    常混乱，罗列了很多事项，却把握不到重点，无法把一件事情说清楚。这种思维混乱

    是典型的缺少结构化思维的表现。结构化思维非常重要，不仅仅体现在表达上，也

    体现在在我们分析问题的过程中。具备结构化思维，才能将问题分析地更全面、更

    深刻。

    什么是结构化思维？

    那么到底是什么是结构化思维呢？简单来说，结构化思维的定义就是：逻辑+

    套路。

    表达要有逻辑

    所谓逻辑是指我们的结构之间必须是有逻辑关系的。例如，你说话的时候用“第

    一、第二、第三”这个逻辑顺序是合理的，但是，用“第一，第二，第四”就会显得

    很奇怪。当然，即使你用了”一、二、三”，也不一定就意味着你的内容有逻辑关系。2 > 阿里工程师的自我修养

    想让内容有逻辑关系，我们要学会四种组织思想的逻辑关系：

    1)演绎(因果)顺序： “大前提、小前提、结论”的演绎推理方式就是演绎顺序。

    比如，经典三段论：所有人都要死，苏格拉底是人，苏格拉底要死。

    2)时间(步骤)顺序： “第一、第二、第三”，“首先、然后、再者”等，很多的时

    间顺序同时也是因果顺序。

    3)空间(结构)顺序： “前端、后端、数据”，“波士顿、纽约、华盛顿”，化整为

    零(将整体分解为部分)等都是空间顺序。

    4)程度(重要性)顺序：比如“最重要、次重要、不重要”等。

    实际上，所有的逻辑关系都在这四种顺序之内。只要我们的思想和表达在这四种

    逻辑顺序之内，就是有逻辑的，否则就会显得没有逻辑性。

    做事要有套路

    套路是指我们解决问题的方法论，这个也非常重要。比如，5W2H 分析法就是

    一个非常好的，可以帮助我们分析问题的一个”套路”。试想一下，面对任何一个问

    题，你都能从 Why、Who、When、Where、What、How 和 How much(如下图

    所示)，七个方面去思考。是不是比不知道这个方法论的人，用点状的思考，5W2H

    分析法就全面得多。

    图片来源：https:zhuanlan.zhihu.comp45492055阿里工程师的自我修养 < 3

    例如，我们在对问题域进行分析和领域知识提炼的时候，就可以用上5W2H。

    5W2H模型给出了具有指导意义的约束，要求我们提炼的领域知识必须具备模型的六

    个要素。这就好比两位侃侃而谈的交谈者，因为有了确定的主题与话题边界，一场本

    来是漫无目的野鹤闲云似的闲聊就变成了一次深度交流的专题高端对话。

    逻辑是一种能力，而套路是方法论，是经验。逻辑是道的东西，而方法论是术的

    东西。二者都很重要，只有熟练的掌握二者我们才能更好的进行结构化思考。

    如何进行结构化思考？

    逻辑性和方法论是结构化思维的底层，那么如何进行结构化思考呢？这也是有方

    法论的，总的来说是有两个步骤，首先是“建立中心”，然后再进行“分解”。

    建立中心

    建立中心也就是要定义清楚要解决的问题，要明确目标。是我们结构的顶层节4 > 阿里工程师的自我修养

    点，也是一种以终为始的思考方式。也就是说，我们首先要搞清楚 why，然后再进行

    how。

    ★ 建立中心有两种方式：

    1. 自上而下：适用于问题比较明确的情况，我们只需要找到问题的核心要素即

    可，然后进行展开即可。

    2. 自下而上：对于问题不够明确的情况，我们需要对多种杂乱的内容，进行分

    类、剪枝、归纳汇总成一个中心。

    建立中心通常不会是一次成型的，随着对问题理解的变化，对中心的抽象也会进

    行相应的调整。不同的抽象层次其面对的问题宽度是不一样的。具体要用哪个层次的

    抽象作为“中心”，要视具体情况而定。

    比如面对“系统 bug 多”的问题，向上抽象是“提升代码质量”，向下抽象是

    “加强测试”，都可以作为中心，选择哪个为中心取决于你当前要解决的问题是什么。阿里工程师的自我修养 < 5

    结构化分解

    确定完中心之后，我们需要构建一个结构，使用结构化的思维对问题进行分解。

    分解的策略就是我们上文提到的四种逻辑顺序，即演绎顺序、时间顺序、空间顺序和

    程度顺序。

    在做空间分解的时候，要注意满足 MECE(Mutually Exclusive Collectively

    Exhaustive，相互独立，完全穷尽)原则。

    比如我们要对衣服进行分类，如果按照季节和风格进行分类，就会出现互相重

    叠，并且不能穷尽的情况，也就不满足 MECE。这种分类是逻辑混乱的。

    图片来源：https:zhuanlan.zhihu.comp45492055

    我们可以按季节分：春秋装，冬装，夏装。除了这3类之外，没有其他季节了，这个就是「不遗漏」。6 > 阿里工程师的自我修养

    图片来源：https:zhuanlan.zhihu.comp45492055

    结构化思维应用

    如何落地新团队？

    想象这样一个场景，你刚刚入职一家新公司，或者转岗到一个新团队，作为一个

    技术人，你将如何落地开展你的工作呢？

    这里，我们就能用上结构化思维来帮我们理清思路，从而有条不紊的开展工作

    了。我们要知道对一个企业来说，核心要素无外乎就是业务、技术和人，也就是说这

    三个要素是我们要建立的中心。基于这个中心，我们可以进行进一步拆解，形成子结

    构。然后对子结构再进行分析找到应对策略。这样一步步递进，我们就已经在用结构

    化思维解决如何落地新团队的问题了。阿里工程师的自我修养 < 7

    ★ 1. 熟悉业务

    1)了解产品：任何一个团队都有自己要负责的产品，申请一个测试账号去用一下

    产品，是熟悉产品比较好的方式。

    2)了解流程：任何业务都有自己的业务流程，而业务流里面最核心的是信息流。

    我们可以通过人员采访，了解关键节点的信息输入和信息输出；可以画一些泳道活动

    图，理清楚系统的主要角色，以及他们之间的交互关系。

    3)客户走访：通过走访客户，我们可以更加获得业务的第一手资料，更加贴近业

    务和客户诉求。

    ★ 2. 熟悉技术

    1)了解系统架构：可以让团队的技术人员介绍下他们当初系统设计和架构的

    思路。

    2)了解领域模型：查看关键的核心表结构和系统 API，这样可以快速了解系统的

    领域模型。

    3)了解代码结构：下载系统工程，熟悉整个工程结构和模块职责。以一个最重要

    的流程为入手点，阅读代码，看清楚核心的执行逻辑。做一个小需求，掌握相关的流

    程和权限。

    ★ 3. 熟悉人

    1)了解组织结构：查看公司的组织树，知道公司大概是如何运作的，以及哪些是8 > 阿里工程师的自我修养

    KP(Key Person，关键人)。比如，一个典型的电商公司会包括产品部、运营部、销

    售部、技术部、人力资源部、财务部、法务部等。

    2)了解人员角色：了解公司都有哪些岗位，以及各岗位的职责范围。

    3)拜山头：找到和自己工作息息相关的岗位人员，比如产品和运营。积极和他们

    沟通，向他们请教业务问题，多多交流。这样一方面可以建立更好的人际关系，另一

    方面也可以更快地熟悉业务。

    打造极客文化

    我最近刚刚转岗到新部门，新部门的老板抛给我一个命题：如何帮助技术团队打

    造极客文化？

    这个问题的中心很明确，接下来，看看我是如何使用结构化思维来解这个问题

    的。首先我们从空间顺序进行分解，也就是打造极客文化，我们可以去做哪些事情。

    空间顺序分解

    确定完要做的事情，我们还可以按照时间顺序对如何落地这些事情进行分解。

    时间顺序分解

    这样把按照这两个维度进行结构化拆解的方案给到老板，老板就会很清晰地知道

    你的规划和落地策略了。

    如何做晋升述职

    作者在阿里巴巴已经做了好几年的晋升评委，发现很多同学都缺乏结构化思维，冗长的 PPT 里，却不能把价值说清楚，不能把推导过程说清楚。实际上，我们需要阿里工程师的自我修养 < 9

    有一些方法论来指导我们进行关键述职。

    接下来，我主要说一下述职中存在的两个典型问题：“罗列事情”和“价值的

    背后”。

    ★ 1. 罗列事情

    对自己做过的事情进行简单罗列，也许你的确做了不少事情。但是不能体现你对

    问题思考的深度和做这个事情带来的价值。这样的述职很难打动评委，更结构化的表

    达应该是：“提出问题，定义问题，分析问题，解决问题，最后是展望未来”。

    这是一个经典的表述问题的结构，也是麦肯锡推荐的问题解决的框架。

    类似的框架还有 zoom inzoom out。我们说事情时，应该像电影镜头一样，先

    从远拉近，再由近拉远。zoom in 是先从宏观背景开始，首先让大家知道你的事情发

    生的背景，为什么这事重要？然后讲到具体细节，怎么做成的？解决了什么问题？背

    后的思考是什么？最后 Zoom out，再从细节调回到整体，结果是什么，带来的客户

    价值是什么，你对未来的思考是什么。

    ★ 2. 价值的背后

    把价值说清楚的确很重要，正所谓：路走对了，就不怕远。如果你连价值都不明

    确，后面做的再多也是白搭。但是，仅仅阐述价值也是不够的，会让人觉得你有邀功

    之嫌。

    比如你说：“我主导研发的风控系统把公司的坏账率从5%降低到2%”。这样的

    表述是不够的，你还需要把价值背后的过程和思考说清楚。对于这个结果，评委可能

    会问：10 > 阿里工程师的自我修养

    1. 之前为什么那么高？

    2. 为什么你的方法可以降低？是如何归因的？

    3. 具体解决了什么问题？

    4. 是否可以总结出一套办法，以后别人也能用这个办法解决这些问题？

    如果你在评委提问之前，就能对这些问题进行深入思考和适当呈现。那么你就是

    既有结果又有过程了。

    通过这些案例，我们可以看到具备结构化思维，可以帮助我们快速的理清处理问

    题的思路，提升工作效率。经常锻炼结构化思维，可以极大的提升我们职场竞争力，让工作有条不紊，事半功倍。

    参考资料：

    《思维混乱，是因为大脑没有结构》

    https:zhuanlan.zhihu.comp45492055阿里工程师的自我修养 < 11

    优秀工程师必备的三大思维，你拥有哪些？

    作者：至简 高级技术专家

    阿里妹导读：不同岗位、不同职责的技术人对工程师思维的深度要求是不一样

    的，但从多维度去思考却应是每个技术人都应该具备的素养。本文整理自阿里巴巴高

    级技术专家至简在团队内部的个人分享，希望通过对工程师思维的分析和解读，让大

    家能正确对待那些在现实工作中看上去与本职岗位无关，却对团队效能影响极大的一

    些点和一些事。

    作者简介：至简，阿里巴巴高级技术专家，是集团Service Mesh方向的重要参

    与者和推动者。曾出版《专业嵌入式软件开发——全面走向高质高效编程》一书，坚

    信和倡导软件设计是软件质量之根本，并对软件开发的复杂性本质有着深刻的认识，对如何高质高效实施软件开发有着自己独到的见解和方法。

    在社会分工的背景下，软件行业的工程师群体被划分成了开发、测试、产品等诸

    多岗位，以协作的方式共同完成价值创造。高度依赖软件的互联网行业正以全新的方

    式改善着人们的生活，同时在改善的道路上对价值创造的效能提出了更高的要求，而

    背后是对个体与团队的协作效能有着更高的诉求。12 > 阿里工程师的自我修养

    专人专岗的协作模式在进一步改善团队的协作效能时所面临的最大挑战在于“岗

    位墙”，即岗位间衔接不可避免会出现一些模糊地带，而这些模糊地带又很容易相互

    忽视，导致失去关注而很大程度地拉低了团队效能。比如，开发工程师会认为保证质

    量是测试工程师单方面的职责；开发工程师不关注用户体验而只需关注实现需求，等

    等。此外，这种协作模式也会固化个体的思维和心智模式，将个体的思维和心智框定

    在所处岗位之内，以致对于岗位之外的内容不能很好地理解，使得个体在整个协作活

    动中会缺乏同理心、系统性，从而影响工作幸福感。

    相信这些现实工作场景读者并不陌生：

    ● 开发工程师对产品工程师所提出的用户体验方面的需求会认为过于吹毛求疵；

    ● 产品工程师因不理解技术的实现原理而提出天马行空、不接地气的需求(我们

    在此不讨论创新这一特例)；

    ● 测试工程师因为不理解工程效率的内涵而将自己的工作变成了体力活；

    ● 开发工程师不清楚自己对于软件质量的责任，而将那些本因自己做好的琐碎工

    作心安理得地交给测试工程师去做；

    ● 辛辛苦苦所开发出来的功能，用户抱怨难用。

    这些问题发生的最终结果，一定是团队协作效能的低下。那么在没有找到比专

    人专岗更好的协作模式的情形下，我们该如何发挥个体的力量去改善团队的协作效能

    呢？改善的起点在于全面地梳理工程师思维，帮助工程师个体在职场和职业发展中建

    立起更为全面的思维和视野，以促使每个工程师在协作过程中能最大程度地发挥个体

    能力去推动团队协作效能的提升。

    我将工程师思维分解为产品、技术和工程三大思维。每个维度主要关注的内容通

    过几个关键字去表达，如下图所示。下面针对每种思维需要关注的每个词以图中从上

    至下的顺序去解释。由于解释是基于关键词去展开的，所以段落之间的衔接可能会显

    得生硬，还请读者见谅。阿里工程师的自我修养 < 13

    产品思维

    产品思维的起源是用户(或客户)价值。用户价值是通过技术手段以产品或服务

    的形态去解决用户的痛点，或带去爽点。毫无疑问，工程师在日常工作中应时刻关注

    并理清自己的工作与用户(或客户)价值的联系，并且应该通过聚焦于用户价值去安

    排工作的优先级和分配自己的精力。14 > 阿里工程师的自我修养

    当用户价值足够时，产品能否在市场中立足并真正收获收益，首先考验的是产品

    的用户体验。良好的用户体验一定是站在用户的角度，基于用户心智来塑造概念，由

    于概念存在理解和解释成本，所以塑造的概念应足够轻、少且易掌握。概念一旦塑造

    出来则概念间的关系也随之确定，这些关系基本上决定了产品与用户的交互流程。好

    的产品体现于“易用”二字，其极致在于迎合用户的本能反应并符合各种生活或专业

    常识。

    所有产品都存在演进的过程，所创造的用户价值也在被不断地挖掘与探索，那时

    不同的细化价值需要通过产品特性去区分和表达。特性也是产品差异化的一种体现，特性也间接地确定了软件实现层面的功能模块边界。作为开发工程师，也需要对产品

    特性有非常透彻的理解，并能将其很好地抽象并转化为软件实现层面的功能模块。特

    性需要考虑通过售卖license等形式进行开启或关闭去实现售卖，这一点对于2B的

    产品甚是必要。

    为了产品更好地演进，需要通过数据闭环的形式去检验创造用户价值的效果，让

    产品的开发、运营、营销工作做到有的放矢。在产品价值创造的道路上，最害怕的事

    莫过于只顾低头干做加法，做得多却无人关心收效。而我们通过数据化闭环的形式，不仅能让整个产品大团队聚焦于核心价值，还能帮助团队在探索用户价值的道路上理

    性地做减法。大多情形下，做减法远难于做加法。阿里工程师的自我修养 < 15

    技术思维

    技术思维的源头是需求。需求可以分成市场需求、系统需求、特性需求等不同层

    次，回答的是技术层面“做什么”的问题。显然，清晰表达的需求以及对需求的精确

    理解才能确保将事做对。毋容置疑，需求一旦出现偏差所导致的浪费是非常严重的，也正因如此工程师对于需求的质量相当重视。

    需求一旦确立，会基于模块化的思想拆分成多个功能模块去降低实现的局部复杂

    度，最终将所有功能模块“拼接”在一起去实现整体需求。每个功能模块会安排给一

    个人或一个团队负责，由于功能模块是需求分解后的产物，容易导致工程师在实现的

    过程中只看到“树木”而忘记了“森林”。

    性能是工程师在实现一个功能模块时不得不关注的，特别是当功能模块被运用于

    高频、时效性敏感、算力有限的场合时性能将尤其被关注。在现实中有时会存在工程

    师乐于追求性能的极致去体现自己的技术实力，甚至出现过早追求性能而滑入过度设

    计的误区。

    毫无疑问，一个正规的团队，对于功能模块的开发工作多会以项目制、多个迭代

    的方式去完成交付。不少工程师这里会有一个误区，忘记了敏捷思想所倡导的“项目

    计划的目的是为了适应变化”，而是将“按时交付”当作是天职，各种赶工爬到终点

    时却毫不意外地看到了“一地鸡毛”的景象。

    在迈向第四次工业革命的道路上，人工智能、大数据、机器学习，Kubernetes、16 > 阿里工程师的自我修养

    Istio、Knative、Go、Dart、Flutter 等新技术不断冲击着工程师已掌握的技能。快

    速跟上技术的迭代步伐是每个有追求的工程师不断提升自己专业素养的表现之一。工

    程师的内心一定不缺乏对新技术的追求，憧憬自己所掌握的技术具有一定的先进性。

    工程思维

    工程思维的起点是流程。流程的背后是科学，以既定的步骤、阶段性的输入输

    出去完成价值创造，通过过程控制确保最终结果让人满意。由于流程涉及每一个工程

    师的工作质量与效率，其含义不只在于定义、工具化、检查等内容，而是应基于工程

    师的日常工作习惯，将流程与工程师的工作环境无缝整合。“无缝”体现于流程中的

    概念与工程师群体已建立的专业常识相一致、没有增加毫无价值的负担，根本仍是确

    保易用性。

    机制的含义是通过对所需解决问题的分析，以一种模式去解决同类问题。机制应

    体现一定的系统性，而非“头痛治头，脚痛治脚”。系统性不是一开始就能被洞察到，可能在演进的过程中逐步发现和完善的，因而需要工程师在工作的过程中不时回顾并

    付诸实践去落实。对于工程师来说，机制是通过系统性的软件设计去达成的。

    可以说产品质量直接决定了工程师的工作和生活幸福感。一个质量不可靠的产品

    一定会给用户和工程师自己带去麻烦，甚至造成无法挽回的经济损失并造成负面的社阿里工程师的自我修养 < 17

    会影响。对于工程师来说，那势必打乱个体的工作与生活节奏。为了让产品的质量做

    到可靠，单元测试、静态分析、动态分析等确保工程质量的手段应成为工程师的基本

    工作内容，通过将这些手段与 CI(Continuous Integration)流程进行整合去持续构

    建起对软件产品的质量信心。

    在互联网行业，除了软件产品的质量得可靠外，风险可控是另一个不能忽视的内

    容。而风险可控是建立于系统性机制和质量可靠之上的。对于服务端软件来说愈是如

    此。风险往往出现于资源使用的极端场景，当从外部涌入的过多事务远超软件产品的

    处理能力时，需要有一定的机制让整个产品能相对平滑地应对，或是扩充资源、或是

    限制涌入事务的流量。

    软件所需的机器成本是比较容易忽视的话题，软件成本不只与软件性能相关，还

    与软件之间的依赖、技术方案等因素相连。当一个软件需要从公司的内部对外输出

    时，平时忽视对成本的关注就会暴露出成本问题。比如，为了运行某个软件需要数量

    庞大的计算资源，所导致的资金开销对于客户来讲很可能是无法接受的。

    至此，大致介绍完了自己所理解的工程师思维。

    延伸

    了解工程师思维的价值在于，工程师个体需要在工作中逐步建立起产品、技术和

    工程三大思维，以便用更为全面的视角去看待日常工作中所面临的困境和困惑。当站

    在单一的思维去看待所面临的问题时可能觉得不合理，但从三大思维层面去审视时所

    得到结论可能完全相反。从团队协作的角度，只有团队中有更多的个体从多维度去进

    行思考，才容易发现岗位间衔接的那些无人问津的灰色地带，进而通过补位、助攻去

    更大程度地发挥团队的效能。

    显然，不同岗位、不同职责的工程师对于这三大思维的深度要求是不一样的，但

    从多维度去思考却应是每个工程师都应该具备的素养。18 > 阿里工程师的自我修养

    优秀工程师必备的一项技能，你解锁了吗？

    作者： 岩动 资深技术专家

    阿里妹导读：很多程序员在工作一段时间后会遇到迷茫期，虽有技术傍身，也难

    免会产生焦虑，反复思考怎样才能快速成长。关于如何提高自己的思考力，运用思考

    的力量推动能力提升，以此实现技术成长，阿里巴巴盒马产品技术部的岩动总结了一

    套思考方法，分享给每个正在成长的程序员。

    引言

    我们来看一下几类在程序员成长、发展的常见问题，如果你或多或少存在一些，那么恭喜你，这篇文章值得你仔细往下看了：

    · 你自认为付出了跟别人同样的努力，但是你的成长确实更慢一些，比如学得比

    别人慢，排查问题比别人慢，出方案老是有漏洞等等；阿里工程师的自我修养 < 19

    · 你觉得你只是在疲于应付需求，自己做的事情完全没有技术含量(很多人觉得

    自己做的业务开发就是没有技术含量，但我认为每个领域都有自己的技术含

    量，只是你有没有 get 到)；

    ·你发现总是在犯同样的错误，或者做的事情不断地在同一个水平循环；

    · 每次要晋升的时候，你发现根本讲不出来(很多人会认为是表达能力问题，但

    是我认为不是)；

    ·当你换到一个新的领域，你发现自己的经验好像用不上；

    · 你一直很难搞懂老鸟说的“认知升级”到底是什么概念？不同级别的技术思维

    能力到底有什么差别？为什么晋升的是他，而不是我？

    在这篇文章里，我会告诉大家一些技术成长的误区，我先点出来：

    · 只要把事情搞定了，成长是自然而然的事情——可能过段时间，你发现之前犯

    过的错误，后来一个都没有避免；

    · 我只要努力，996甚至007，我就能够成长得比别人快——可能你发现你干

    得最多，但是并没有拿到最好的结果；

    · 我尽力了，还是比别人慢，应该是我智商确实差一些——恭喜你，其实大家的

    智商并不会有太大差别；

    · 别人表现好，或者晋升了，只不过是比我表达能力更强而已——我可以负责任

    地告诉你，这并不是仅仅是表达能力的问题。

    先抛一个非常重要的结论： “思考力”是程序员需要具备的一种至关重要的素质。

    掌握了思考力，你就掌握了在互联网领域，这种高度“智力密集型”行业成长的钥

    匙。上面这几个成长的问题和误区，跟没有掌握思考力有着非常重要的关系，而且我

    发现所有发展比较顺畅的同学，他们的思考和学习能力是非常强悍的。20 > 阿里工程师的自我修养

    我个人在工作中，一直有意或者无意地锻炼自己和团队同学的思考力，包括哪些

    是对我们最重要的思考力，如何去训练思考力，有一些心得，希望能够分享给大家。

    关于思考力

    思考力是一门很深的学问，包括认知科学，心理学、教育学、逻辑学，如果要系

    统化学习，是需要看很多书的，我推荐以下几本：

    1. 《金字塔原理：思考、表达和解决问题的逻辑》 -[ 美 ] 芭芭拉·明托，这本书系

    统阐述了思考、表达和解决问题的逻辑，也是麦肯锡的思维能力基础，算是一本比较

    标准的思考力教材；

    2.《麦肯锡教我的思考武器》 - [日] 安宅和人，作者根据自己在麦肯锡公司工作

    时积累的丰富经验以及脑神经学的专业背景，设计出一套极具逻辑性的问题解决思维

    模式；

    3.《思维的本质》 -[美]约翰·杜威 ，这本书是美国著名教育家约翰·杜威的代

    表作，阐述了思维训练的基础理论和实践；阿里工程师的自我修养 < 21

    本文并不是探讨思考力的深层理论，而是分享我们从日常的技术学习和项目过程

    中沉淀下来的思考力，以及如何培养这些思考力，这些思考力几乎我们每天都可以用

    到，只要你有一定体感，你一定会感同身受。

    有哪些对程序员最重要的思考力

    原理性思维：找出知识背后的原理

    有的人会说，为什么要思考原理，而不是直接掌握知识就可以了？我只需要会用

    就行了啊。

    我们先来举一些技术方案设计的案例：

    ·为什么订单创单要先 create，然后 enable ？

    这其实是一种采用二阶段提交解决分布式事务的思路，只是从一般的事务框架

    延展到交易领域；

    ·业务系统中为什么要使用消息？

    因为消息使用的是观察者模式，观察者模式的好处是可以实现多个消费事务与22 > 阿里工程师的自我修养

    触发事务的解耦；

    ·为什么业务系统中会使用 DTS来做补偿？

    这本质上是一种最终一致性 BASE理论解决分布式事务的一种思路；

    ·为什么更新数据的时候一定要在 sql中加上版本比对或者状态比对？

    这本质上是一种借助 DB实现的乐观锁机制。

    进一步，你会发现再大到系统架构和顶层设计的案例：

    · 比如阿里系的技术框架NBF、TMF、早期的webx，各类框架设计理念，逃

    不脱设计模式，比如开闭原则，模板方法、责任链、工厂模式、开闭原则；

    · 不管是底层中间件，错综复杂的业务系统，在设计的时候永远无法离开核心的

    业务建模，比如实体与实体关系的构建；在分析这类系统的设计思想时，你会

    发现最好的工具就是 UML !

    实际上除了软件领域的原理，还有商业设计的原理，比如案例：

    · 所有的售中退款前必须要先取消履约，所有的履约过程中发生缺货都需要退

    款，为什么？因为交易的基本原则是：“钱货平衡”，钱和货的变更必须是最终

    同步的(允许短期的不平衡)，你掌握了钱货平衡的基本原理，交易中的很多复

    杂的流程设计就很好理解了；

    · 在设计财务系统、库存系统时候，业务流程、业务逻辑可能非常复杂，导致你

    晕头转向，这时候“有借必有贷，借贷必相等”的财务平衡性原理就发挥作用

    了，你只要知道这个原理，很快就能看懂各类财务流程、库存流转流程，以及

    各类数据对账逻辑；

    · 在我的领域“高可用线下收银系统”进行线下系统容灾的时候，有各种容灾方

    案的设计，会员容灾、商品容灾、交易容灾、支付容灾……不同的容灾手段看

    起来让你眼花缭乱，但是他们有没有共同遵循的原则呢？有，这就是“让消费

    者最快速度完成交易，但保持最后追溯的能力”。你只要get到这个基本原理，设计各类容灾策略就会得心应手了。阿里工程师的自我修养 < 23

    此外，我们的工作流程、管理手段，同样也蕴含着深层的原理，非常有意思，大

    家可以抽空仔细推敲一下，比如：

    1. 为什么团队机制要透明？沟通要透明？

    2. 为什么要有 owner 意识，都是在工作，owner 意识会有什么不同呢？

    3. 为什么管理者不能管得太细，也不能放羊？到底哪些该管，哪些不该管？

    所以，掌握了知识背后的原理，带来的好处是：

    · 软件系统的复杂度越来越高，我们所面对的场景越来越多，掌握原理实际上

    可以大幅度降低我们对于知识的记忆量，知识量是爆炸的，但是原理绝对是

    可控的!

    · 原理性的东西比直接的知识有更强的复用度!记住最核心的原理，当你面对

    新的场景时，你会惊喜地发现，你的理解速度大大加快!这个点大家应该有体

    会，比如可能之前我们都学习过dubbo等底层的RPC通信框架的基本原理，但是你如果仅了解了他的基本用法，你会发现对你现在做业务系统没有什么帮24 > 阿里工程师的自我修养

    助!但是，当你了解的是dubbo如何寻址，如何做容灾，如何做扩展，你再

    去做业务系统，发现设计原理是一样的，并没有本质区别!这样你之前研究中

    间件的设计思想就可以快速用到业务系统上面。

    · 另外探求原理的过程，本身很有乐趣!这是一个非常有价值的思维训练过程，不断对系统设计思想、业务设计思想、做事情的工作方式，追寻背后的原理，并找到他们之间的共性，在我看来非常有乐趣，一段时间训练以后，你会发现

    你看透本质的能力越来越强!

    好，那么我们程序员的工作中，究竟有哪些与原理性知识是需要我们掌握的呢？

    按我们团队的实战经验来看：

    1. java，linux，数据结构和算法，数据库，网络通信与分布式计算的原理，这

    几类是比较重要的基础知识，我们在做方案设计、编码、问题排查中会运用

    得很多；

    2. 设计模式，UML这个是对系统架构设计必要要掌握的知识，当你经历了很多

    大规模的软件系统设计，回到根本上，你会发现逃不出这一块的理论和工具；

    3. 领域性的基本原则，比如我们上面提到的“钱货平衡”，“财务平衡公式”，“线下收银让消费者最快速度走人”，这种逻辑需要大家get到这些领域性的

    设计原理，甚至自己去总结出这种原理；

    4. 关于管理学，人际沟通，心理学的一些基本原理，大家可以按照自己的实际

    需求去看一下。

    如何在工作中学习和运用这些原理，我觉得有一个最佳实践：

    1. 首先，对你可能用到的领域知识，建立一个基本的概念。看书，看文章，找

    行业资深的人去聊，都可以得到。注意，这里需要有一个基本的概念就可

    以，这样你在有可能touch到这些原理的时候，你会有意识，也不至于花很

    多时间；

    2. 在实践中，有个意识是“多问一下为什么” ，并一直“刨根问底” ，最终肯定阿里工程师的自我修养 < 25

    能够追查到背后的最终原理；这里面还要注意思考一下，为什么在这个地方会

    运用这个原理，也就是找到“场景”和“原理”的关联关系，这样你的理解

    会更加深刻；

    3. 了解了原理以后，在实践中运用一下，这样你对这个原理的理解就会非常深

    刻，并且你知道如何去运用这原理；

    4. 如果这是一个非常重要的原理，建议大家如有余力去结合经典的书籍系统化

    学习。

    结构化思维：构建自己的知识树

    知识树要解决的问题，我们看一些场景：

    1. 为什么我知道很多东西，但是当场景来的时候老是会记不起来使用；

    2. 完成一个方案你只能想到一些点状的手段，还有其他方案被漏掉了；

    3. 讲一件事情的时候逻辑非常混乱，前后没有逻辑性关联。

    但是很有可能你的知识都是知道的，为什么会出现这种悲剧？

    这个就跟大脑中的知识结构有关，这是知识学习中“索引”没有建立，也就是26 > 阿里工程师的自我修养

    说，你的知识只有点，没有线!大家想一想，把东西乱七八糟地丢在房间中，到用的

    时候没有查找的线索和路径，怎么找得到呢？

    来看一下我们工作场景的结构化的典型案例，大家体会一下：

    项目中测试 MM 提了一个 bug，我总结出来的比较标准的问题定位步骤：

    1. 确认刚才是否有过代码变更和部署，因为有比较高的概率是刚才变更的代码

    又搞坏了……

    2. 追踪链路日志看链路是否有异常；

    3. 通过 RPC的控制台调用看接口输入输出是否符合预期；

    4. 追踪关键方法的入参和出参，看是否有问题；

    5. 定位到方法细节后，推理逻辑是否有问题；

    6. 如果无法通过推理，那就最后一招，回放异常流量debug，这样肯定能够找

    到原因。

    某个链路耗时比较长，需要进行性能优化，我的分析步骤是：

    1. 通过实际流量制造一个耗时较高的 trace；

    2. 进行 trace 分析，看清楚耗时最多的原因，然后按优先级进行排序；

    3. 针对对原因找解决方案，可能的方案有：

    i. 减少数据访问次数或者计算量，常见手段是增加cache：线程内的

    invokeCache；分布式缓存 tair；页面缓存……

    ii. 增强处理速度，比如多线程加速；

    iii. 减少循环调用次数，比如请求合并后再分发；

    iv. 减少数据处理范围，比如减少查询内容，异步加载分页；

    v. 逻辑简化，比如逻辑进行优化，或者非核心逻辑异步化等；

    vi. ……

    4. 改掉以后，回放同样的case，看性能消耗是否满足预期，不满足预期继续

    优化；阿里工程师的自我修养 < 27

    如何熟悉一个新系统，我的步骤是：

    1. 要一个测试账号，把相关功能走一遍，这样能非常快地了解一个系统的功能；

    2. 看关键的核心表结构，这样可以快速了解系统的领域模型；

    3. 根据功能步骤找到系统对外的接口列表，了解系统的 L0 业务流程；

    4. 下载系统工程，熟悉整个工程结构和模块职责；

    5. 以一个最重要的流程为入手点，阅读代码，看清楚核心的执行逻辑，可以变

    看边画时序图；

    6. 制造一个debug场景，以debug方式走一遍流程，这样可以实际加深一下

    对系统的理解；

    7. 做一个小需求，掌握相关的流程和权限；

    下单这里来了一个新的需求，出一个技术方案的步骤：

    1. 看清楚之前的需求，把这个需求所在的场景和链路大致阅读一遍，搞懂；

    2. 找到需求的变化点；

    3. 分析变更的方案，涉及的内容可能会有：28 > 阿里工程师的自我修养

    i. 数据结构会不会变，如何变；

    ii. 交互协议会不会变，如何变，交互协议分为：端和组件要不要变；和下游

    接口要不要变；

    iii. 执行逻辑会不会变，如何变，执行逻辑变更的细化考虑点：是否变更域服

    务；是否变更流程编排；是否变更主干逻辑；是否变更扩展点是否变更扩

    展点的内部逻辑，变更内部逻辑的时候，又可以进一步拆解：

    a.重构原有的方法，覆盖之前的逻辑，那就需要进行回归；

    b.通过逻辑路由到新的方法，这里需要增加路由逻辑；

    4. 稳定性方案；

    5. 发布方案；

    可以看到，面对任何一个场景，不管多大多小，我们所需要掌握的知识或者技能

    都可以构建成一个树结构，同类之间是顺序关系，上下之间是父子关系(或者粗细颗

    粒 度 )。

    当这个树在大脑中构建起来以后，你会发现你做什么事情都是有一个明确的分析

    和执行逻辑，不太可能产生遗漏和混乱!

    那么如何训练出自己的知识树呢？我给一些比较有效的实践方案：

    1. 一定要总结出自己的知识树，而不要盲从书本上的或者别人的，为什么呢？

    一是因为人的思维速度和习惯、技能有一定差异，不一定每个人都是一样

    的；二是如果没有内化别人的知识成为自己的知识，这棵树不太能够很熟练

    地运用；

    2. 习惯性总结，做完任何一个事情，都习惯性地回顾一下，往自己的树上面挂

    新东西，这个是构建知识树的必备手段，这个总结不需要花很多时间，比如

    做完事情后花个几分钟回顾一下就可以，但是需要坚持；

    3. 推荐一个很常见的工具： xmind，把自己的树记录下来；

    4. 训练自己的思维习惯和做事方式变得结构化，当你做事情的时候，习惯性用

    树的方式推进，强迫自己按照这个方式来。阿里工程师的自我修养 < 29

    扩展性思维：举一反三，拓展思维

    扩展性思维的核心目标是提升我们思维的广度，也就是让我们的知识树变得更加

    开阔；

    我在工作中总结出来的扩展性思维的两个关键的扩展方向：

    (1)举一反三：解决同类型的N 个问题

    举一反三的好处是：“我们能否用同样的知识和手段去解决类似的相关联的几个

    类似问题”，先举一些案例：

    · 当发现某个系统的jvm参数配置存在一个错误配置，不是仅仅修复这个系统

    的 jvm配置，而是把负责的几个系统都检查一下是否需要统一修改；

    · 系统中存在某个bug导致产生了脏数据，不是直接订正已发现的脏数据，而

    是根据特征拉取出所有的脏数据，进行一次性处理；

    这种思维方式的特征是举一反三，触类旁通，相当于产生批处理的效果，可以大

    大提升解决问题的效率，避免重复处理。30 > 阿里工程师的自我修养

    (2)寻求更多的可能性：拓展解决问题的不同手段

    拓展思维常见的手段是：是否能够换更多的理解方式，或者更多的解法，举一些

    案例：

    · 产生故障的时候，快速止血除了回滚以外，还有哪些方案？如果故障处理经验

    丰富的人一定知道，除了回滚，其实还有系统降级，运营活动降级等多种方案；

    · 除了写更加健壮的代码，还有哪些手段都可以提升系统的容错性？还有数据监

    控，单据闭环等多种手段；

    当解决问题的手段更多了，思维就开阔了。

    抓重点思维：提升效率，方便记忆和传递

    当我们发现知识树构建起来以后，怎么样使得记忆和使用的效率变高？而且对外

    传递的时候更加容易让人理解？抓重点思维要解决的场景是：

    1. 如果每件事情都按照知识树方式做，效率可能不会特别高，有更快的办法么？

    2. 在对外沟通表达的时候，要表达核心思想，否则别人会很难理解你的表达内

    容；比如大家再晋升答辩、项目汇报的时候一定会有体会。

    解决这两类困惑，核心思路是要抓住重点和脉络。

    但是抓住重点和知识结构化之间并不矛盾，而且我认为是有先后次序的，一定要

    先建立知识结构化，然后才能从里面筛选出重点，否则知识的体系是不完整的。

    那么筛选重点的思路有哪些呢？

    (1)归纳法

    采用归纳法，把细节隐藏掉，呈现知识的脉络，这是一种非常好的思路；尤其是

    大家在准备晋升ppt时，ppt的每一页都需要归纳一个核心观点，不是全是细节，这

    个非常重要!并且训练归纳的能力，本身就是对知识理解深刻程度的一种反映；

    (2)优先级法

    优先级策略往往应用于在多项任务之间找到最最关键或者收益最大的那个任务

    项，比如完成一个事情可能有若干个步骤，其中哪个步骤是最有效的，大致可以做一阿里工程师的自我修养 < 31

    个排序。在实施的时候，你可以按照优先级去落实。

    但是找到效果最好的那个任务项，在不同场景下是不同的，跟我们的熟练程度和

    经验有关。就像老中医把脉，越有经验判断越准，这块没有什么捷径，只能不断练习

    自己找到哪些任务项在什么场景下更加重要。

    反思性思维：思考哪里可以做得更好

    反思性思维是提升知识质量和深度的一个关键能力。因为只有不断反思才能让下

    一次在上一次基础上升级，而不是重复循环。

    常见的反思案例：

    ·有个问题我查了2个小时，师兄只花了10分钟，这是为什么呢？是他的业务

    比我熟悉？思路比我清晰？还是知道某个我不知道的工具？一定要找到关键的差异

    点，然后弥补掉这个差距；

    ·一个项目项目做完了，从方案设计，研发过程，质量保障上面，哪些地方下次

    可以做得更好？找到不足，下次避免；

    对于我们技术团队，哪些内容值得反思，我们团队的经验是：32 > 阿里工程师的自我修养

    1. 这个项目商业价值 OK吗？是否取得了预期的效果？

    2. 项目中我的能力有哪些问题，有哪些做得好的和不好的？

    3. 系统设计的优势和不足？

    4. 项目质量保障是否可以做得更好一些？

    5. 研发过程和项目管理是否有不足？

    反思性思维的实践，注意有两个点比较关键：

    1. 反思性思维最重要的意识：做事情的过程总有优化的空间，每次都要有进步；

    如果没有这种心态，那么很难持续地进行反思；

    2. 反思是一种习惯和潜意识，可以在不经意之间经常进行，其实不需要很形式

    化地花很多时间，有时候做完一个事情，习惯性思考一下就可以。阿里工程师的自我修养 < 33

    锻炼思考力的有效实践

    1. 意识觉醒

    意识觉醒是提升思考力最重要的一个点，我认为。只要形成了这种意识，就已经

    成功了一半。

    很多同学思维能力没有上去，是没有意识到思考力这个概念，只是机械地做事

    情，做事情，做事情……每次都在同一个思维层次上面转悠，不可能有本质的提升。

    从初级工程师，高级工程师，技术专家，高级专家，资深专家……级别提升靠什

    么？多接了多少需求？多写了多少代码？这些因素会有，但是关键因素不是这些，而

    是思考力在不断提升，思维方式在不断进化，进而导致业绩产出必变得更加优秀，产

    生的是事半功倍的效果。

    能够坚持看到这里的同学，一定是能够知道思考力的重要性了。

    2. 保持信心

    现在知道思考力的重要性了，很多同学可能认为自己是一个不够聪明的人。为什

    么我努力了，还是不行？

    给大家一个信心：有位大师说过：在相同的文明程度和种族背景下，每一个正常

    人的潜意识与意识相加之和，在精神能量意义上基本上是相等的。

    我几乎接触到的很努力但是成长速度不快的同学都是因为没有没有掌握正确的

    方法；

    只要掌握了正确的方法并坚持训练，思考力绝对可以提升。

    3. 空杯心态

    思考的过程其实是对人的知识进行不断刷新和重构的过程，这里一定要保证空

    杯心态，对新的环境，新的理念，新的技术持开放态度，否则就是自己给自己制造

    阻力。

    4. 思考的时间从哪里来？

    常见的借口是“我连需求都做不完，哪来的时间思考”？

    训练思考力其实并不需要太完整的时间，我的口诀是：“1.利用碎片时间；2. 抓34 > 阿里工程师的自我修养

    住工作的过程” 。

    · 利用碎片时间，比如上下班路上的时间，吃饭的时候，可以把刚才或者今天的

    事情想一想，想通了，然后定期汇总一下就可以；

    · 抓住工作的过程，注意，每次每次出技术方案，优化代码，排查问题，处理故

    障，准备晋升……都是一次训练的机会，在做事情的过程中就可以思考并快速

    实践。

    5. 思考力提升有没有什么判断标准？

    有的，一般来说思考力有三个度：广度、深度、速度，这你自己就能够感觉出来的：

    · 广度：就是你自己的知识树能够长多大的范围，越广知识越渊博；比如从“如

    何写一个多线程程序”，提升到“如何做系统性能优化“，再到“如何做系统

    稳定性备战”，这就是一种广度的提升；

    · 深度：就是你自己的知识树的叶子节点有多深，越深对知识了解越透彻；比如

    从“分布式事务问题解决思路”，到“利用最终一致性解决分布式事务”，再到

    “利用 DTS解决分布式事务”，这就是一种深度的提升；阿里工程师的自我修养 < 35

    · 速度：就是建立和刷新知识树的速度了。比如原来你想清楚一个建模方案要一

    天，现在只需要半小时可以想清楚，那就是速度的提升了。

    6. 好的工具有推荐么？

    还是推荐一个工具：Xmind，这个最土的工具最有效。可以下载手机版和PC版

    本，随时进行记录。

    7. 一定要相互分享

    思考虽然主要是靠自己，但是一定要相互分享。因为思考是智力活动，相互分享

    完全能够取得 1+1>2 的效果；

    注意分享可以有很多形式，比如我们团队最经常的是：

    · 项目分享：重大项目是一定要分享的，包括架构设计经验，过程经验，质量提

    升经验，都需要分享出来；

    · 周会分享：团队周会重点过进度？那太浪费啦，了解进度和风险看周报就可以

    了。周会是学习分享的好时机重点就是一些关键的方案，架构设计理念，好的

    工具，甚至工作无关的内容；

    · 群内分享：当有个人踩坑以后，在群里面提醒一下大家，这是一个很及时的分

    享方案；

    · 年度 季度分享：这时候适合找个风景优美喝茶的地方，大家讲一讲自己的成

    长和思考，非常有帮助；

    · 小圈子：大家形成自己的小圈子，随时都可以相互倾诉一下自己的心得体会，其实这种效果也很好；36 > 阿里工程师的自我修养

    8. 技术 Leader 在训练大家思考力中的职责

    在技术团队中，技术 Leader 的思考力意识、能力和实际行动，决定了一个团

    队的整体思考力水平和成长速度!

    一个团队要提高思考和学习的能力，首先得这个团队Leader的思考意识就要提

    上来，如果团队Leader没有思考意识，也没有把团队同学的成长放在心上，那么整

    个团队的思考力和成长速度绝对快不起来。

    在提升团队整体思考力的实践中，技术 Leader 的职责：

    ·先要把自己变成一个思考者，自己做表率，以身作则；

    · 意识心态上先变过来，要把团队同学的成长速度最为最重要的职责之一，没有

    这个意识都是空谈；

    · 多创造思考的条件和氛围，一定要抓住任何机会(代码reivew、方案评审、周会都可以)鼓励大家去思考和分享；

    ·控制团队节奏，给大家学习和思考留出一定的时间；

    · 及时的引导和示范，有的同学可能掌握会偏慢一些，这时候需要有耐心去引导

    同学找到思考的感觉；阿里工程师的自我修养 < 37

    · 不必过多干预细节，发挥大家的群体智慧，而不必做过多干预，更不能以个人

    的意志去强迫别人接受。

    重要观点小结

    好了，到这里可以给重要观点做个小结，时间紧的同学们可以直接读这一段：

    1. 思考力对程序员的成长至关重要，团队和个人都需要有意或者无意识地提升

    思考能力。

    2. 对程序员最重要的思考力有：原理性思维、结构化思维、反思性思维、扩展性

    思维、抓重点思维。

    ·原理性思维是根基，因为没有搞懂的情况下所有的知识建构都是空谈；

    ·结构化思维帮助我们建立了我们的知识树；

    ·反思性思维不断对知识进行重构，是实现认知升级的必备条件；

    ·扩展性思维可以提升知识的广度和深度；

    ·抓重点思维可以加快知识的使用效率和传递效率；38 > 阿里工程师的自我修养

    3. 在提升思考力的实践中：

    ·思考力提升最关键的是意识的转变；

    ·要对思考力的提升充满信心；

    ·多在工作中去锻炼思考力，不需要花太多额外的休息时间；

    ·多相互分享；

    · 团队Leader要团队同学的成长和把思考力提升作为最重要的内容，并拿出实

    际行动。阿里工程师的自我修养 < 39

    如何在工作中快速成长？

    致工程师的 10 个简单技巧

    作者：江建明 高级无线开发专家

    阿里妹导读：阿里有句非常经典的土话，“今天的最好表现，是明天的最低要

    求。”如何挖掘潜能、发现更好的自己？今天，阿里巴巴高级无线开发专家江建明将

    认知升级的方法总结出来，帮助你获得快速成长的秘诀(本文内容稍长但值得细细阅

    读 哦 )。

    一、如何阅读本文？

    1.找一个固定不被打扰时间仔细阅读。

    2.在碎片化的时间中，每次读完一段内容。

    最重要的是每次做到只字不差的阅读，然后停下，带着批判性思维从本文中提取

    出你觉得对的思考方式，并把思考方式关联和迁移到自己身上，经过实践内化成自己40 > 阿里工程师的自我修养

    的认知，就是非常成功的一次阅读。

    二、开始认识“认知升级”

    第一次：从文章中看到认知升级，认为认知升级是洗脑，是鸡汤，我对此不屑一

    顾，道理谁都懂，大部分人还不是过得一样，没啥区别。

    第二次：从会场里听到认知升级，一个活人站在那里讲认知升级，觉得认知升级

    有点意思，开始慢慢去理解认知升级，但还是不懂认知升级的价值。

    第三次：从实践中觉知认知升级，发现“鸡汤谁都懂，但依然过不好这一生”，还有另外一个版本“用好喝鸡汤的工具：汤勺，可以把这一生过得很好”，最简单的

    开始就是从时间管理认知升级开始，感受到认知升级的强大力量。自从换了一种时间

    管理思考方式之后，自己逐渐变得自律，变得有思考，成长复利慢慢变厚，感受到认

    知升级的价值，但还是没能力定义认知升级。

    第四次：从利TA中定义认知升级，开始做认知升级的PPT给团队，给他人分

    享认知升级，发现一部分人的行为、工作、思考等在慢慢发生变化，这些发生变化的

    同学，未来肯定会超出自己的期望，变得更加优秀，此时我想我能够比较清晰地定义

    认知升级。

    我对认知升级的定义：认知升级是连接，连接优秀的思维方式，连接解决问题的

    最短路径，连接一切优秀的方法。比如：说到时间管理立马连接到“找到不被打扰的

    时间用于投资自己”、说到执行力立马连接到“先想明白，然后一步步做下去”、说到

    改变习惯立马连接到“在触发条件发生进入下一个行为时，做对选择题”。通过认知

    的改变，会激发自己做出思考，做出行为的改变，从而影响我们的判断，提升我们的

    能力，确切地说认知升级颠覆了自己的思考习惯，让我们超越本能思考，摆脱了旧有

    的直觉和经验，建立起了新的直觉和经验。阿里工程师的自我修养 < 41

    下面10个主题的认知分享是从我的认知升级库中挑出来的一部分我认为最重要

    的认知，对我的帮助和改变非常大，我相信对其他人同样有价值，大道至简，坚持

    这10个简单的认知就可以大大提升我们的成长速度，而且随着自我不断进化的同时，会不断升级和丰富自己的认知库，不断提升自己的认知升级能力。

    1. 思考脑与反射脑

    听精彩的演讲不止精神上会有即时的瞬间享受和满足感，更重要的是总会有那么

    几个关键词刺激我们的神经，让我们产生瞬间记忆，做出进一步的思考，这也是我为

    什么爱听牛人演讲，不是想听他创办企业的精彩故事，而是因为他演讲的内容中透露

    出的智慧，透露出的超时代的远见，透露出系统性的逻辑，听他的演讲总会给人一种

    醍醐灌顶的感觉，而所有这些演讲过程中透露出的智慧、远见，并不是在台上立马想

    到，是台下无数个思考最终抽象提炼出来的观点。台上演讲是反射，台下准备是逻辑

    是思考，所谓台上一分钟，台下10年功，反射和思考是什么关系呢？开始第一个认

    知：思考脑和反射脑。42 > 阿里工程师的自我修养

    欧洲工商管理学院教授特奥-康普诺利的《慢思考》这本书中把大脑分为反射

    脑、直觉脑、存储脑。简单来说：思考脑管理性，反射脑管直觉，存储脑管记忆，直

    觉依赖习惯，用直觉做出反应，快速，但未必正确；思考脑管理性，理性依赖逻辑，缓慢，但更加正确。

    有科学家通过研究，发现一个人一天的行为中，5%是非习惯性的，用思考脑的

    逻辑驱动，95%是习惯性的，用反射脑的直觉驱动，决定我们一生的，永远是95%

    的反射脑(习惯)，而不是5%的思考脑(逻辑)。回想自己的一天，大部分的判断和

    观点是不是都是靠直觉，靠习惯的，什么情况下才会用思考脑？是不是一个人的时候

    用思考脑比较多，而在多人对话场景中要快只能靠直觉和反射，而给别人好与不好的

    印象往往是在对话场景中建立起来的，可想而知，反射出来的观点或行为对我们而言

    是多么重要。

    以学游泳举例，当在水里的那一刻，进入正念(正念：有目的，有意识的，关注

    和觉察当下的一切)，将大脑的指令和手脚的动作关联上，大脑下达手脚标准化动作

    指令，手脚执行标准化动作指令，过程中大脑一直在关注和觉察手脚的动作，同时做

    出判断和调整，这是一个逻辑思考和强化训练的过程，把逻辑思考的过程强化成反射

    的过程，一旦学会，就无需进一步思考，游泳已成为自然。

    放在学习和成长上也是一样，借用正念的概念，有目的有意识地关注和觉察

    学习时的一切，特别是在输入和输出过程中的逻辑思考过程，我特别建议做好2

    件事：阿里工程师的自我修养 < 43

    ● 专注输入：做到只字不差地阅读，只字不差地听。

    只字不差地阅读、只字不差地听的过程中，我们会持续地深入理解作者文字和语

    言背后的逻辑，会产生自己的逻辑思考，会产生逻辑和观点的碰撞，自己的逻辑和作

    者的逻辑差异和共同之处在哪里，这是反复训练逻辑思考的必经之路，缺少这一步，导致的结果就是中国填鸭式教育的结果，大部分时候知道结果但是不知道原理。

    ● 专注输出：定期做 PPT进行分享。

    定期做PPT进行分享，这是读书学习过程中无法替代的高质量逻辑训练方式，是

    一种更高要求的逻辑抽象的训练，同时通过输出检测学习和成长质量，训练的次数多

    了，书上的逻辑就变成了自己直觉反射，丰富了自己 95%区域里有效的结构化知识。

    所以对我们来说，想要没有焦虑，想要人生变得踏实，把泛读变成精细化的逻辑

    训练，把95%中的低质量习惯反射，训练成逻辑后的高质量习惯反射，训练过程会

    痛苦，但是一旦训练成直觉，会变得非常自然。

    划重点：所谓直觉反射就是通过大量的逻辑反复训练，提升自己的直觉准确性，从狭窄的 5% 进入广阔的 95%；

    2. 习以为常

    把95%中的低质量习惯反射，训练成逻辑后的高质量习惯反射需要有很多的时

    间保障。但是对处于移动互联网时代的我们，电子设备对人类生活出行带来了很好的

    便利性，与此同时人类对其依赖程度已经到了寸步不离的地步，甚至上厕所短短几分

    钟，手机也是寸步不离。44 > 阿里工程师的自我修养

    手机已经成为一种生活方式，一种习惯方式，眼不离机是我们的习惯，因为手

    机产生了非常大的变化并固定了下来，空了玩手机、陪家人时玩手机、忍住不睡玩手

    机，我们的生活因此少了学习，少了阅读，少了交流，少了陪伴。

    曾经，我也一直被困在电子设备这个囚笼里，好长时间无法改变这个习惯模式，难改变是因为一旦进入习惯模式，大脑的活跃程度急剧下降，不再参与决策，进入休

    眠状态，此时我们的行为由习惯支配。我对这种现代化的生活方式最大的感受：浏览

    信息的时间多了，自己思考和琢磨的时间少了，专注在无效事情上的时间多了，专注

    在自我成长上的时间少了。

    当自己觉知到重度使用手机进行浏览和娱乐的不好习惯后，自然就产生了想改变

    的想法，也就是说，如果能够有一种改变习惯的有效方法，帮助自己改变重度使用手

    机的习惯后，意味着每天可以节省很多的时间，节省很多的注意力，节省下来的时间

    和注意力可以放在更重要的成长能力的迭代上。幸运的是，习以为常的认知进入到我

    的认知系统中，成为我的第二个认知升级。

    我对习惯的认知，关键在于换种说法：“把改变玩手机的习惯，用另外一句话来

    替代，把学习变成习以为常的生活方式”。要解决的对象变了，前面聚焦于改变习惯，后面聚焦于把学习变成习以为常，当我们要求别人或自己改变习惯，会有压力，关键

    在于“改变”这个词，命令式，给人一种不自觉反抗的心里暗示；但若把学习变成习

    以为常，心里负担会少很多，似乎是很自然的事情。阿里工程师的自我修养 < 45

    认知变化后，能否把学习，阅读变成习以为常的事情，关键在于能否意识到突发

    状况，并在这些突发状况下调整自己的行为。无效的社交等突发状况出现的时候，如

    果能够置之不理，或者稍后再处理，那自然能够把学习和阅读变得成习以为常。注

    意，这是改变习惯最关键的意识切入点，一边是对无效行为的置之不理，一边是启动

    学习和阅读，只要做个行为替换就可以改变习惯。

    谁都知道替换可以改变，但为什么这么难？其实关键在于这个意识点能不能变成触

    发性响应，也就是说当某个触发条件产生的时候，改变的意识能不能弹出来警告自己。

    先对习惯的产生机制要有所了解，习惯并非凭空产生，他有前因后果，前因是前

    一件事情结束(触发条件)，后果是前一件事情结束后的行为带来的一些额外奖励。比

    如晚上下班回家洗完澡这件事情结束后，肯定会开始下一件我们最习惯的事情，比如

    盯手机看剧或者刷八卦，当这件最习惯的事情结束后，大脑会产生精神上的及时享

    受，内容很丰富、很精彩。短期看是享受，长期看是灾难，因为对未来帮助意义不

    大，但是却消耗了我们大把时间。而且看剧或者刷八卦带来的信息积累只能称的上是

    饭后谈资，或者有些根本没机会谈。

    了解习惯产生的机制后，改变习惯就变得很简单，每次在触发条件发生时，弹

    出一道选择题，选择做无效事情，还是学习？多次以这种方式不断强化自己做对选择

    题。久而久之，正确的行为被训练得多了，就成为顺其自然的习惯了。所以改变习

    惯，就是在触发条件发生时，让自己做对选择题，打破旧有习惯回路，建立新的习惯

    回路。相信这句话“精英之所以精英，是不间断的正向行为习惯的驱使”。46 > 阿里工程师的自我修养

    划重点：所谓改变习惯就是在触发条件发生进入下一个行为时，让自己做对选

    择题。

    3. 时间管理：三八理论

    在我的第2个认知《习以为常》中，提到养成习惯的方法就是在触发条件发生

    时，让自己做一道正确的选择题，打破旧有习惯回路，建立新的习惯回路。也就是说

    当做对选择题的时候，也就得到了用于学习和思考的时间，这是时间管理的一部分，从现有的事务中挤出时间。但是用于学习的时间不应该只有这部分，我们需要系统性

    认知时间管理。

    世界上有2种人不做时间管理，一种是有时间不管理，另外一种是没时间不管

    理，既有主观原因，又有客观原因。客观原因是工作太忙，确实很难有时间用于学

    习；主观原因是做其他事情有时间，学习和思考没时间。不管哪种人，他们内心深处

    对于时间管理的需求一直存在，只是一直没找到好用的时间管理方法，最后放弃了。

    有需求必有供给，市面上可以找到有很多时间管理的书，时间管理方法，时间

    管理软件。但是你有没有过这种经历，我是有过，很多方法用了，比如时间管理四象

    限、番茄钟、时间计划等，在坚持一段时间之后，还是回到原来的状态，原因是什

    么？我认为最根本的原因是太复杂了，没法用一句话改变我们的共识并建立时间管理

    意识。

    比如很多时候我们会采用计划的方式做时间管理，什么时间做什么事，但是人毕

    竟不是机器，总会有意外，无法按照流程一步步执行下去，计划总会被打乱，一旦打

    乱可能全乱。若为了保持计划如期运作，会给自己带来非常大的负担，负担来自于为

    了管理该计划消耗了很多精力，而且每项计划不一定能够按预期完成，时间久了，放

    弃是最好的选择。

    当然这些时间管理方法或番茄钟肯定有用，只是复杂的东西不适合我，可能也不

    适合很多人，不然不会有这么多人明知有很多时间管理方法，但还是对时间管理很焦

    虑，因为难执行啊。我必须找出简单的方法让我自己能够很快适应，同时不会成为负

    担，对时间管理的认知是我的第三个认知升级，也就是时间管理三八理论。阿里工程师的自我修养 < 47

    时间管理三八理论：每个人每天有公平的24个小时，第1个八小时用于睡觉、第2个八小时用于工作、第3个八小时用于自由支配，但人与人的差距主要是由第3

    个八小时决定的，第3个8小时用于消费、交易还是投资有着非常大的人生差别。以

    下班空闲时间为例解释消费、交易、投资从而理解人生差异的不同：

    下班空闲时间，用于消费，比如刷新闻，刷抖音，刷朋友圈，产生及时享受，没

    产生成长，钱还是那些钱，职位还是原来职位；

    下班空闲时间，用于交易，接个外快，赚点辛苦钱，产生金钱，没产生成长，钱

    没多多少，职位却还是原来职位；

    下班空闲时间，用于投资，以终为始，相信“慢慢来，成长最快”的认知，持续

    不断投入多维领域的学习，沉淀能力，获得成长，从成长中获得金钱，名誉的升级；

    看完时间的消费、交易、投资的解释，在看《习以为常》中做选择题的重要性，做对选择题其实就是投资，投资自己的成长，投资自己的学习，人生的不同不就是因

    为投资自己而变得不一样吗？但是投资需要时间，时间怎么来？

    “找到不被打扰的时间”。只有找到了不被打扰的时间用于投资自己的成长才能发

    生复利效应。如果想从工作中省点时间，想从周末挤点时间用于学习，这叫成长的断

    崖，我相信不能持续，学习必须是每日的必修课，必须是日拱一卒，持之以恒，有不

    断的输入，也有不断的输出，持续地沉淀，在关键时刻输出解决问题能力，从而获得

    能力认可。

    分享下我如何找到不被打扰的时间用于投资自己的成长，因为每个人的工作性质48 > 阿里工程师的自我修养

    不同，找到不被打扰的时间长度不一样，比如程序员这个行业，加班很多，比如我在

    公司时间平均有11-12小时，即便在这种情况下，还是能够在工作以外找到不被打

    扰的时间，更何况工作时间没有 12 小时的朋友呢!我的不被打扰时间：

    ● 睡前：晚上回家到睡觉前，这段时间每个人都有，这里至少可以抽出40分钟

    学习，建议 11 点半之前必须睡觉，为了早起做准备；

    ● 早起：这里需要重点说下，如果按照我之前8点起床的睡眠习惯，这个时间估

    计用不上，所以有魄力的人可以做些改变，就是缩短睡眠时间，比如原先8点

    起床改成 6 点，相信自己，年轻人睡 6-7 个小时是够的；这样就会产生 1~1.5

    个小时学习时间，平时哪有这么长的时间用于学习啊；

    ● 晨会前：这条适合离公司近的人，在晨会开始前，早点到公司，找到30分钟

    用于学习，这类短时间的学习主要是用于学习快餐知识，找知识服务平台花钱

    买知识，学习人家总结好的知识。

    以上的作息计划会让自己产生一定的疲劳，但是中午放弃刷新闻，刷抖音，在工

    位补个觉，不会影响每日的精力，而且随着自己的成长，会越来越有成就感，成就感

    带来的精神状态反而比之前更好。

    划重点：所谓时间管理就是找到不被打扰的时间用于投资自己的成长。

    4. 最重要的财富：注意力

    对我们来说，有3样非常非常重要的财富，分别是金钱、时间和注意力，其中金阿里工程师的自我修养 < 49

    钱在3者之中我认为最不重要，反而非实物的注意力和时间更重要，金钱没了可以通

    过提升能力赚回来，而且是 100%可以赚回来的，时间和注意力是一次性消费，用了

    就没了，虽然第二天有新的时间和注意力补充进来，但是要知道生命在流逝，过去消

    耗的时间和注意力属于一次性消费。

    在时间管理的认知升级中，我们已经具备了认知：“找到不被打扰的时间用于投

    资自己”。本节以我们的第2大宝贵财富注意力进行认知升级，让自己的注意力在不

    被打扰的时间里用在投资自己的成长道路上，时间是容器，注意力是武器，搭配得

    好，成长可期待。

    先问自己 2个问题：

    ● 昨天、上周、上月看过的内容还记得吗？

    ● 进一步区分看过的内容：哪些是成长？哪些是谈资或甚至都没有机会谈？

    好的问题本身就是好的答案，回想自己过去在第3个八小时的自由支配时间里，注意力用在什么地方，是用于投资还是用于消费，如果意识到过去注意力用在了消费

    上，那么赶快把注意力用到投资自己成长上，如果还没意识到，建议只字不差阅读

    《时间管理》认知，进而搞清楚时间用于投资，还是消费，有着巨大的人生意义。

    从问自己的2个问题看现在的生活方式，生活中有很多看似合理的生活现象，其

    实是一个巨坑，是别人在收割我们注意力变成流量产生了商业价值，但是我们竟然乐

    在其中，因为我们喜欢莫名其妙凑热闹，喜欢随大流，喜欢做大家正在做的事情，我

    们每天花了大把时间在上面，但是收获的成长却很少，因为我们都是在消费时间，消

    费注意力，而不是用时间投资自己成长。

    我们以为做大家正在做的事，就找到了归属感，找到了安全感，但实际上真正

    的安全感、成就感，归属感来自自我成长，自我沉淀。对生活在信息量爆炸时代里的

    我们，用好自己的注意力非常难，处处都是陷阱，处处都是诱惑，处处降低我们的思

    考，让我们轻易获得成品，带来的结果是表面上我们懂的很多，但其实理解非常浅。

    对于这些巨坑，不建议大家100%放弃，对于群居物种的人类来说，还是要

    和外面世界建立连接，和身边人有话题交流，但是我们要调整注意力，把原先可能50 > 阿里工程师的自我修养

    100%的注意力变成28分配，还是37分配，根据自己对自己的掌控力度，让大部

    分注意力投资在自己的成长上，减少朋友圈，减少新闻娱乐投入。

    再来解一个疑惑：“为什么看电影注意力特别好，做正事注意力集中不了”。

    首先接受这个现实，医学上把这叫作注意力缺失症，基本所有人都有这种毛病，因为做正事比较枯燥、困难，让人不舒服，集中不了注意力，逃避很正常!

    其次找到改善方法，我通常这么做，给自己准备一个笔记本或Evernote，边读

    边思考，顺带把重要的观点记录下来，开始会觉得很困难，但是慢慢坚持下来你会发

    现，思考会越来越深入，注意力集中时间越来越长。或者练习只字不差的阅读，在练

    习过程中因为只字不差会让自己更认真地去理解内容的逻辑关系，从而达到提升注意

    力的目的。阿里工程师的自我修养 < 51

    注意力和时间管理的认知一旦结合，我们可以兴奋地这么说：“在不被打扰的

    时间里，用好注意力投资在自己成长上，我们的人生会不一样，在未来会遇到更好的

    自己”。

    划重点：所谓提升注意力就是专注在目标事务上，直到产出预期的结果。

    5. 拿结果手段：执行力

    执行力和自律在我们的工作和生活中出现的频率非常高，因为这是我们成长或做

    成事时必须要有的2个关键词，但是很长一段时间里，对于提升执行力，疑惑很大。

    同时在工作场景中可能会被老板多次要求提升执行力，抽象又具体，但往往只有提升

    执行力的要求没有如何提升的方法和认知，这是普遍点到即止的现象，普遍提升不了

    执行力的现象。

    造成这种现象的原因，是因为我们的认知很容易接受前人总结的观点，因为太有

    道理，所以欣然接受，然后会像传球一样，把观点再次传给其他人，但是整个传播链

    路上缺少形成观点的方法传播，也就是大家听到看到，很多时候只是结果，缺乏了过

    程的输入，看到的是别人的成功，但是看不到别人是如何成功的。

    我也经常要求自己提升执行力，但一段时间后就主动放弃，后来我想通了一件

    事：每个人身体内至少有多个角色，从认知的角度来看，有两个角色，一个是投资

    者，投资自己的成长；另外一个是消费者，消费自己的时间和注意力，很少关注自己

    成长。我们一生一直在扮演这两个角色，互相博弈，成长者获胜持续成长，消费者获

    胜原地踏步。但是，往往消费者获胜，因为消费者在消费时间和注意力去刷朋友圈、52 > 阿里工程师的自我修养

    看新闻娱乐，做大家正在做的事情，感觉找到了归属感，安全感，大脑能立马获得及

    时的奖励，而大脑又是控制我们思考和行为，一旦消费者占领了大脑，也就控制了我

    们日常的思考和行为。

    提升执行力，首先让自己成为投资者，投资自己的成长，投资在正确的事情上，此时去认知执行力才有意义，我对执行力的认知：“想明白，然后一步一步做下去”，如果想不明白，根本谈不上执行力。同时提升执行力的时候，还需要自律，通过自律

    让执行力得到持续，要相信持续投资自己的成长，可以实现“慢慢来，成长最快”的

    复利效果。比如：

    很多时候我们知道，或被提醒过，或被要求过，需要提升执行力和自律，却不知

    道执行力的行为指导方法，现在有了执行力背后的行为指导方法：“想明白，然后一步阿里工程师的自我修养 < 53

    一步做下去”，此时的我们需要有思辨思维，通过实践“想明白，然后一步一步做下

    去”，内化成自己的认知和方法，指导自己的一生。

    划重点：执行力就是想明白，然后一步一步做下去。

    6. 贵人

    阿里文化环境，技术环境，成长环境对个人成长非常有帮助，所以在阿里常说要

    学会感恩，感恩自己处在了最好的时代，最好的环境里、感恩身边的人、感恩帮助和

    改变自己的人。

    这几年经历的事，遇到的人对自己的帮助和改变非常大，很多时候像是命中注

    定，在挑战、迷茫、委屈的事情出现时，恰好有个人在你身边，和你一起理清思路，调整思考方式，避免处在自己封闭式的思维里越思考越极端。我确实非常幸运，身边

    有这样的贵人，能够帮助我以终为始看问题，看自己。慢慢地，我相信一切问题源于

    自己，让自己变好是解决一切问题的根源。所以我把贵人作为一项认知升级，放在自

    己的认知库中，有机会让更多的人或自己的家人也建立贵人的思维方式。

    但是很多时候我们会觉得身边缺少贵人，或者有贵人但离自己太远。产生这种认

    知离不开 4 个方面：

    一是，自己不自信，不相信自己能够影响他人，导致缺乏主动沟通，长期沟通，沟通的延续性和习惯没有建立。

    二是，自己心态问题，自己的心态若是不够积极正向，没有贵人敢进入你的思维

    空间，因为价值观不匹配，很难形成认知共识。

    三是，职场原因，很多时候可能你的老板就是你的贵人，但是因为职场，因为上

    下级，碍于面子，碍于工作，不敢多交流，多请教。

    四是，贵人来了又走了，有贵人帮你改变，帮你进步，但是自己不努力，抱着过去

    做事的心态和方法在职场上浪迹天涯，进步不明显，否定了他作为贵人的价值和意义。

    如果恰好有这么一位贵人，应该懂得珍惜，珍惜的主要方式是用成长回报他，因

    为你的成长在未来可以帮助他。同时在平时需要建立有效沟通，首先让贵人真正地了

    解你，在确定贵人能够帮助你，影响你时，你应该大胆去承担一些有挑战的事情，哪

    怕遇到委屈，遇到压力，遇到失败，要相信此时的你才是真实的你，你的天花板，你54 > 阿里工程师的自我修养

    的瓶颈就在于此，借助贵人助你提升能力，下次同样的事情来临时，自己就能够得心

    应手，这种能力的锻炼机会非常少，和阿里经常说的借事修人非常匹配，事情失败了

    没关系，但人要成，人的能力要提升。

    说一个我自己从小的经历，我从小独立性很强，干过很多农活，小学开始住校，16岁做了2个月童工盖楼房，高中月末回家坚持地里务农，大学勤工俭学，正因为

    独立性很强，很少主动向人求助，加上从小接受的父母教育：向人求助等于麻烦别

    人。有事没事别老是麻烦别人，欠人恩情要还的，这不是我父母的错，而是中国的报

    答文化，因为获得帮助需要报答别人导致心里负担太重，从而教育子女不要随便麻烦

    别人。长期以往性格受此影响较大，越不向人求助，性格越内向，越内向越不向人求

    助，与他人间的交流少了，输入少了，观点碰撞少了，思考也就少了，内敛的性格也

    就这样逐步养成了。

    但是这几年的经历和变化，突然意识到向人求助≠麻烦别人。如果把求助当成低

    声下气的行为，那么跟乞丐没啥区别，把求助看成一种交易，一种有着“巨大意义”

    的交易，你求助时，别人之所以愿意帮助你，是因为他已经看到你的价值，这种价值

    帮助他确定了自己的价值(他有能力帮助你)，或者未来你可以帮助他。每个人应该

    都经历过，在你出手相助他人的那一瞬间，你得到了最重要的回报：你有能力帮助别

    人，同时，在帮助他人的过程中发现了自己未来可能需要更加努力的方向。帮助别人

    不是你赢我输，而是一个共同进步的过程，在帮助别人的过程中，巩固自己知识的同

    时可以发现自己理解上的偏差。阿里工程师的自我修养 < 55

    贵人就应该紧紧抱住，通过和贵人建立关系，贵人的观察，反馈，双向沟通，对

    话，辅导等，可以帮助自己从互动的信息中生成自己的思考，行为和观点，这些思

    考，行为和观点会影响自我，完善自我。

    自我稳定性：让自我的容器变得强大，在受到挑战，职责，委屈时候能够容纳对

    方的批判，情绪。

    自我灵活度：容忍对方的情绪后，可以及时调整自我状态，因为相信一切问题源

    于自己，让自己变好是解决一切问题的根源。

    自我疆界：当做出自我状态调整后，看事物的角度变了，能力提升了，自我的疆

    界在逐渐扩张。

    自我力量：自我疆界扩张后，形成的成就感，会让自我的力量变得更强大。

    自我组织力：当一个人在高压下感觉要散架的时候，或者被击溃而瓦解的时候能

    够自我重组。

    划重点：贵人就是可以持续陪你输出高质量的人。

    7. 会议

    “输出倒逼输入”很多人都听过，但是有哪些输入方式，而且效果比较好，很多

    时候我们真的没认真想过。这种现象的原因是我们潜意识里常用的输入就应该是看

    书、思考，反馈这3类，所以很多时候我们会对其他高质量的输入方式不重视，甚至

    忽略。此时，自己安静细想讨论过程中的输入效果？肯定会有自己的答案。而我认知

    “讨论过程中的输入效果最好”，是因为讨论过程能够刺激自己大脑快速做出反应，好

    像CPU被超频，同时也能够从对方的问答中获得更好的输入，这就好比2个人在模

    拟机器学习，通过正反馈的方式不断优化讨论结果，算出最优解。

    实际工作中，大家对会议的看法普遍不太好，大家眼中的会议是这样的：会太了

    多，会议很低效，同样的内容反复开了几遍，自己是很小的配合者却要参加2个小时

    的会议。

    而且我观察过很多会议，很多人，绝大部分人都是开着电脑开会，忙着自己的键

    盘，特别是我们程序员，虽然会议上编写代码有可能提升项目开发进度，但是在有讨

    论，有分享的环境里让自己非常专注写代码还是非常困难的，同时我在团队中做过一56 > 阿里工程师的自我修养

    个统计，统计了一个月大家的会议情况，大概每双周会议投入时间平均在10%~15%，也就是说双周1天到1.5天的会议时间，从会议消耗来看，会中处理事务并不一定有

    非常大的效率提升，倒不如每时每刻集中注意力专注于一件事，效率也许更高。

    所以在参会时，有些会议我尽量不带电脑，让自己的大脑处于思考状态，随时接

    收会议中的信息进行思考，训练自己的观点产出能力，训练自己的总结归纳能力，同

    时也要求团队同学在没有紧急事情的情况下，尽量合上电脑，让自己专注投入到听别

    人讨论，听别人分享，然后自己思考，总结，提炼观点，当然也可以自己参与到讨论

    中，成为主角。

    会多不一定是坏事，反而可能成为你训练思考，训练总结归纳，训练逻辑表达的

    地方。好比机器学习，喂给机器大量的数据进行模型训练，对训练的结果进行应用、验证，如果效果不好再次训练调优，整个过程是一次正反馈不断强化训练的过程。回

    到参与会议也是一样，通过聆听，讨论不断验证自己的观点正确与否，再次聆听，讨

    论，通过一次次的正反馈验证自己的逻辑和观点是否正确。

    而且用什么样的身份参与会议，或者在过程中角色如何切换，也是非常重要。我

    一般用 3种角色参加：

    ● 作为参与者，认真聆听，快速提炼自己想表达的逻辑，然后参与讨论。

    ● 作为聆听者，仔细聆听，认真输入，在脑中组织思路，组织逻辑。

    ● 作为中断者，发现有些会议真的没有继续的必要了，出于好意，提示会议的重

    心或者结束会议。阿里工程师的自我修养 < 57

    划重点：参与会议讨论就是在模拟机器学习，通过正反馈来优化自己的逻辑和观点。

    8. 跳出舒适区

    为什么感觉看了那么多的书，工作了那么多年，写了那么多代码，自己在一开

    始的进步明显后，到现在基本停止进步？我想是因为在舒适区呆的太久了，看再多的

    书，写再多的代码，可能只是以一种舒适的方式进行工作和生活而已，这种舒适方式

    一直没有被很多人认识到，等回头反思的时候发现做了很多事，看了很多书，但成长

    的预期和现实不符。

    于是，我们开始想，究竟哪里出问题了？避难就易是人的本性，困难和容易之

    间，我们总是习惯选择容易，但若选择困难，导致无法接受困难下的挑战我们还是会

    回到舒适区中。回想过去，自己好像也是这样的，心血来潮时突然感觉能量爆棚要学

    很多东西，一段时间后又回到原位。

    抛开自身看身边认识的人，几年不见，成长非常明显。就好比我们人类快速的

    进化和进步，是因为我们掌握了智慧，而这些智慧来源于前辈们的发现和经验的总

    结。比如舒适区，心理学家把我们可能面对的学习内容分成了三个区，分别是舒适

    区、学习区和恐慌区。舒适区太容易，待太久了，总想跳出去看看。恐慌区太难，太

    难带来恐惧，就像梁宁在产品思维中讲同理心时，恐惧会产生束缚也会产生动力，就

    看安全边界有没有被侵犯，如果无法战胜挑战，恐惧就产生了束缚，退回到舒适区。

    所以跳出舒适区，不是说跳到恐慌区，而是跳到两者之间的学习区，在学习区中

    达到困难和能力的平衡状态，引用米哈里 .契克森米哈赖在《心流：最优体验心里学》58 > 阿里工程师的自我修养

    这本书提到的：要想在工作中达到心流状态，这项工作的挑战和你的技能必须形成平

    衡，如果工作的挑战大大低于你的技能，你会觉得工作很无聊。如果工作的挑战大大

    超出你的技能，你会感到焦虑。

    需要让难度和技能正好匹配，在你接受挑战时你还不知道该怎么做，但是调动

    自己最高水平的技能，再稍微努力突破一点，你正好能解决这个问题，就是心流的体

    验，这是一个奇妙的感觉，你沉浸在工作之中忘记了时间的流动，甚至可能忘记自身

    的存在。

    跳出舒适区，进入学习区，进入困难和能力相对平衡的学习区，才能让我们快速

    成长起来，但是进入学习区后，还需要配套的学习方法才能逐渐锻炼自己，很多人有

    自己的学习方法。

    划重点：跳出舒适区就是进入学习区，平衡挑战和技能从而达到心流体验

    9. 职业规划

    我对职业规划有个人不同的理解，我认为大部分人其实不需要做职业规划，只有

    那些有梦想，个人基础素质非常好的人才需要职业规划，他们会为一个目标持续不断

    努力多年，直到目标实现。而大部分人不需要职业规划，是因为很多时候，我们做的

    职业规划只是个梦想，虽然梦想还是要有的，但很多时候只是被别人实现了而已，若

    是恰巧因为幸运被自己实现了，可能是个误会，因为能力没到，在新的岗位和角色上

    会比那些早已准备好的人要付出更多的努力和汗水。

    过去被一些非阿里系的人问过，应该怎么做职业规划？展开交流后，发现很多人阿里工程师的自我修养 < 59

    在做职业规划的时候，更倾向于把职业规划放在某个岗位，某个角色上。比如会把目

    光聚焦于经理岗位、经理能力，或者架构师角色，但是他们怎么走上该岗位，获得该

    角色，背后做了哪些努力，用了哪些方法，沉淀了哪些能力，一脸茫然。确实，职业

    规划非常难，难在他是未来的一个想象空间，这个想象空间能否实现，和当下做的事

    情，努力的程度分不开。

    在聊完后，我一直在反思，如果自己做职业规划应该怎么做？经过不断抽丝剥

    茧，我找到了自己的答案，我认为职业规划不是某个岗位，某个角色，而是工作能力

    的提升。针对自己岗位需要的能力，职场需要的能力，然后用专家思维，多维视角重

    点突破3-4项能力，抱着120%的努力拿到结果，甚至是超出期望的结果，事情成

    了，能力也就被认可了，所谓的角色，岗位只是顺其自然的结果。但是真能这样做的

    人少之又少，既然是少之又少，成为少之又少的人才是你的机会。

    划重点：所谓职业规划，就是工作能力提升。60 > 阿里工程师的自我修养

    10. 时间换空间

    时间换空间，还有另外一种认知的说法：“慢慢来，持之以恒，成长最快”。不管

    哪种说法，其实是在告诉我们，成长无法急于求成，无法急功近利，唯有每日在不被

    打扰的时间中不断投资自己，通过不断输出确认自己成长上的不足，循环弥补不足之

    处。通过把自己逼近成长临界点，然后跨过临界点的那一刻，自己立马可以体会到自

    己的变化，自己的成长。

    而自己一旦体会到成长，我们会把前一段时间的成长过程进行总结，抽象总结

    出自己的成长最佳实践，再次践行，把自己逼向下一个成长临界点，然后再次跨过

    去，以此反复循环，慢慢提升自己的多元能力，跨界能力。所有这些能力的提升，在未来某个机会来临的时候，因为具备足够的能力去驾驭他，此时我们要做的是，抱着 120% 的努力把事做成功，事情成功了，能力也有了，空间自然会有，也就被

    认可了。

    所谓时间换空间，就是让我们无法看清未来是什么样子的时候，把注意力聚焦在

    当下，做成长该做的事。

    划重点：所谓时间换空间，就是慢慢来，持之以恒，成长最快。

    三、总结

    认知升级很鸡汤，虽然好喝但不易消化，在通过学习提升自己认知的同时，自

    己需要有批判性的思维，把自己认可的认知，通过自己的践行，沉淀出自己的最佳实

    践，让自己具备自我进化能力，形成自己的认知系统，这是成长根本。以上10个认阿里工程师的自我修养 < 61

    知升级，分别用一句话进行总结，完成自我认知升级：

    所谓直觉反射，就是通过大量的逻辑反复训练，提升自己的直觉准确性，从狭窄

    的 5%进入广阔的 95%；

    所谓以习为常，就是在触发条件发生进入下一个行为前，做对选择题；

    所谓时间管理，就是找到不被打扰的时间用于投资自己；

    所谓注意力，就是专注在目标事务上，直到产生期望结果；

    所谓执行力，就是让自己先想明白，然后一步一步走下去；

    所谓贵人，就是能够持续陪你一起输出高质量内容的人；

    所谓会议，就是模拟机器学习思路，通过参与讨论获得正反馈来验证自己的观点；

    所谓跳出舒适区，就是先跳出，然后进入学习区，平衡挑战和能力达到心流的

    体验；

    所谓职业规划，就是提升工作需要的能力；

    所谓时间换空间，就是慢慢来，持之以恒，成长最快；

    参考资料：

    李笑来：《通往财富自由之路》

    武志红：《武志红的心理学课》

    刘润：《5分钟商学院》

    特奥·康普诺利：《慢思考》

    米哈里 .契克森米哈赖：《心流：最优体验心里学》62 > 阿里工程师的自我修养

    技术三板斧：关于技术规划、管理、架构的思考

    作者： 毕啸 高级技术专家

    阿里妹导读：实践需要理论的指导，理论从实践中来。作为技术工程师，要不断

    地从事件中反思经验、总结规律，才能避免踏入同一个坑，才能更高效地完成 KPI ，甚至是晋升。今天的文章来自阿里巴巴高级技术专家毕啸，从五个方面总结工程技术

    的核心要点，相信对你能有所启发。

    大约半年前，开始总结自己关于工程技术的一些核心要点，关于规划、技术管理

    以及架构，三个方面的一些心得。结合自己团队的现状、自己对于周边做得比较好的

    同学的观察，于是有了文中的这几张图。

    一、关于技术规划三板斧

    技术规划规划做得好，能起到比较好的正向引导作用，个人及团队的整体目标感

    会好很多，分为三个部分的内容：

    第一部分是全局分析，这需要溯源历史，思考未来，要对未来有一定的预判。能阿里工程师的自我修养 < 63

    够基于数据，基于专业，基于客户价值，同时结合顶层的战略、公司的战役情况和组

    织的现状做分析。

    第二部分是定目标。这一部分非常关键，定义好目标以及非目标，哪些事情是不

    要做的也要讲明白，并且确认目标的实现路径，做好拆解。

    最后一部分是以终为始，从最终结果的角度，来溯源开始。从技术支撑业务发

    展、平台能力输出或者赋能、平台研发效能以及技术数据驱动业务等不同的角度审视

    结果。

    另外，关于创新，可以有几个不同维度的方法，例如通过上下左右的比较，用比

    较思维法来获取信息；例如移花接木，通过不同行业的分析来完成方案的嫁接；例如

    第一性思考，深度分析业务以及技术的场景，产出最后的方案。

    二、关于技术管理三板斧

    这里的管理，不是团队管理，是指技术本身的管理。其实最近一年多，一直在

    倡导一件事情，就是技术的微观化管理，技术和其他的事务不太一样，一旦宏观化管

    理，不能 Deep Dive 细节，就非常容易引发各种各样的问题。例如，在研发质量中

    体现为研发效率降低，架构孵化。总体提供三个方面的建议：

    首先，把控核心细节。软件工程这些年，本质是没变的。不管是偏互联网的部分64 > 阿里工程师的自我修养

    还是偏企业级的部分，关键细节是需要严格把关的。

    另外，就是数据化度量。通过数据驱动研发体系的重建，通过质量风险文化的宣

    导以及核心指标的跟进，起到督导的作用。

    最后，就是清单革命。清单革命是一本书的名字，这里借用过来，合适是

    checklist，不管是代码规约、应用规范还是稳定性治理等，都容易由于不重视或者不

    check 而逐渐孵化。这时候，一个好的 checklist 非常关键重要。

    三、关于技术架构三板斧

    关于架构，其实讲架构模式、TOGAF 架构、互联网架构等的书不少。架构本身

    有一些通用的方法的，但是方法一旦通用，就会偏虚无缥缈。这里总结了三个部分：

    第一，是多元多维。这个概念来自穷查理宝典，因为架构需要良好的上下文输

    入，需要思考时间和空间维度，需要思考组织人才和 KPI ，需要思考目标过程和结

    果，这些和架构本身关系不大，但是关联到架构是否能够良好地落地。

    第二和第三是相辅相成的，核心是分而治之，各个击破。架构本身是解决问题阿里工程师的自我修养 < 65

    的过程，问题太复杂了，只能采用分而治之的办法。怎么分？利用金字塔原理，不遗

    漏、不重复，重点在业务架构和技术架构，同时在数据化上做思考，之后按照架构主

    题做拆分。怎么击破？分层架构和模块化架构，是比较通用的两个方法，业界有架构

    模式的参照，也可以用一些移花接木的方法。另外，关键架构主题和架构模式，也可

    以有 checklist，方便在做架构的时候，通过清单对照不会漏掉重要内容。

    四、关于赛车、赛道、赛手三段论

    去年六七月份，针对市面上已有的物流机器人公司，做了一个全局的分析。在

    分析公司上，是有一些方法论的，正当尝试总结的时候，正好看到“得到”的一个

    专栏，一名证券公司的分析师分析如何快速搞懂一家公司。于是，做了总结：一个前

    提，就是分析宏观背景，例如经济形势。接下来是三部分：赛道很容易理解，就是

    这个行业发展的情况，赛道够不够宽，赛道够不够长；第二个就是赛车，公司有没

    有核心的商业模式以及核心竞争力；第三个就是赛手，公司的人和文化，这个也非

    常重要。66 > 阿里工程师的自我修养

    五、关于点线面体的思考

    曾鸣老师的智能商业，是比较有深度的讲解互联网的一本书，中间有一篇文章是

    讲点线面体的，内容很不错。公司战略和个人发展战略，都可以从点、线、面、体的

    角度来思考。这里做一个引用：

    点线面体，是一种全新的战略定位思考方法。这些年，很多人来找我讨论，公司

    的下一步应该怎么做。讨论多了我慢慢发现，传统的战略理论框架很多已经不适

    应现在新的环境了。战略的最核心是定位，很多人都耳熟能详。定位最传统的理

    论框架是波特提出来的成本领先、差异化和利基市场的竞争战略。虽然在未来这

    种定位还是大家需要去思考的，但实际上在网络时代有更重要的问题要先回答。

    曾鸣《智能商业》阿里工程师的自我修养 < 67

    程序员如何自我学习？阿里资深技术专家这样做

    作者： 雷卷 资深技术专家

    阿里妹导读：互联网信息技术的迭代周期快是有目共睹的，因此，学习、更新知

    识这件事就变得相当重要。今天，阿里资深技术专家雷卷，将分享自己平时学习的方

    法和心得，希望能够带给大家一些启发(本文推荐养家糊口之外有点小追求的同学阅

    读，Ph.D、paper秒懂的学霸同学可自动忽略～)。

    阿里妹注：作者长居在美国，故学习渠道有些许不同。我们可以举一反三，领会

    即可～

    为何要持续学习，靠经验积累不行吗？

    很多人都说程序员的薪资水平不错，可以媲美医生和律师。而程序员和医生、律

    师的不同点在于持续学习上。不是说医生和律师不需要学习，医生、律师能够凭之前

    的case积累非常多的经验(这也是大家看病喜欢找年纪大的医生的原因之一)，而且68 > 阿里工程师的自我修养

    这些经验很大程度上可以被复用(很多病因和判罚案例带有相似性)。

    程序员这个职业则不同，主要是因为行业更新得太快，积累的经验很快就不适

    用了。

    举几个例子：

    如果你是 Java 程序员，且非常擅长 Struts + JSP 开发，解决了很多 Struts 框

    架的问题。但今天，这部分知识已经过时，需要重新学习。如果仍坚持使用之前的技

    术，会给同事和公司带来很大的技术负担。大家回顾一下自己从毕业到现在有多少技

    术都已经看不到踪影了。就阿里巴巴内部来说，很多技术也都已经被淘汰不用了。

    就编程来说，有很多编程语言和门第之争。你在这个语言积累的经验到另外一个

    语言就未必行得通。我很少听说 Java 组招一个 .Net的资深工程师，即便有，那也是

    给产品做 .Net SDK client的。

    软件的经验积累还会体现在一个架构设计上。很多同学会说经验积累得多，架构

    就设计得好，这在今天来说也未必。大家都在云上啦，云上提供的服务基本都是类似

    的，架构思路和使用的云上服务基本一致。

    Amazon的售前人员个个都是行业架构师，给你很好的架构和解决方案，包

    括迁移方案，所以你就知道架构的门槛了。非资深程序员可以花半天时间看一下

    Learn how to design large-scale systems (https:github.comdonnemartin

    system-design-primer)，虽然说是primer，但是还是非常实用的，配合一下

    Awesome list (https:github.comtopicsawesome) 架构思路和模式都有了。框

    架和开发包的具体特性和对比了解了，一天就能够成为架构师。

    有个笑话：一个产品经理找一个有个性的设计师去设计原型和交互稿。该设计师

    头都没有抬说道：“你抄的是哪个网站或App? 告诉我，我下午给你做。”如果你看了

    system design primer，当有架构师找你，你就可以说你参考的是哪个网站的架构。

    我们回头理解一下然后按照这个设计编写代码就可以了。在云上，架构设计基本都是

    pattern的，再花很多时间讨论架构设计，就有点想不通了。但对云上的产品做彻底

    的理解，这个还是需要的。 行业发展得太快，你必须学习，纯靠经验积累行不通，技

    术淘汰的速度远大于你经验积累的速度。 阿里工程师的自我修养 < 69

    非鸡汤：不要和程序员谈自己的编程历史，很多的经验在今天已经不适用了。只

    要 2-3年不关注技术，就基本快和程序员和编程绝缘啦，不是绝对，但是通常不会错。

    工具要非常熟练

    有人跟我说：“不要吹啦，你就是IDEA使用得再熟练，也没有必要将学习和使

    用工具挂上钩吧。” 说句实在话，看到一些硅谷工程师的培训教程中他们对工具的熟练

    使用程度，我只能说我还是小白。

    有一次和几个google的工程师吃饭聊天，问了一下他们遇到的哪些人比较牛？

    一个工程师说他的leader太牛了，在帮助他找bug的时候，工具和debug使用的

    熟练程度让人眼花缭乱。很多工具都是他听都没有听过的，而且Python脚本编写几

    乎如行云流水般。究其原因并非是这个leader一眼就能看出问题所在，有些问题他

    也是第一次遇到，但他在单位时间内尝试的次数特别多，就很快把问题给逼出来了。

    非鸡汤：在排查问题和写代码上，如果你1个小时只能尝试一种方法，别人却能

    够尝试10次，那么别人就是比你牛。天下武功唯快不破，你后续写demo、查问题、工具的熟练程度都会决定你学习和尝试新事物的速度。70 > 阿里工程师的自我修养

    读书 看文档

    学习还需要系统化。并非单靠看一篇文章就能明白原理。

    个人强烈推荐：

    https:www.safaribooksonline.com

    Safari应该是出版社联盟，IT类图书基本都能找到。两个小问题是：需要收费，一年大概 400 刀；图书都是英文的。 Safari Books Online 的图书非常全，几乎涵盖

    绝大多数出版社，我们熟知 oreilly, apress, manning, packtpub，addison wiley，而且更新速度非常快。另外Sarafi提供的Learn path也非常有用，能帮助你系统地

    了解一些技术，如 blockchain，ai，machine learnging 等等。现在视频资料也非

    常多，包括专家知识培训和一些技术大会的视频。

    除了图书，我们还需要关注文档(reference)。现在很多框架和技术的参考文档

    已经非常好了。首先是文档的质量越来越高，现在技术都是协作的。Java程序员可

    以看看 Spring Framework，Hibernate，Kotlin，Groovy 的文档，质量都非常高。

    如果你还停留在文档就是几页介绍和demo，那你的观点可能要改一下了。你看

    CNCF 上的项目，几乎每个项目的文档质量都是非常高的。现在很多项目不是一两个

    程序员单打独斗，而是一个团队加上像github那种协作非常好的平台，所以文档和

    代码、新特性不匹配已经非常少了，很多 issue都是关于文档的。

    另外一些新的技术，刚开始只有文档，在图书还没有来得及出版的情况下，你

    只能阅读文档。个人在做Service Mesh的时候，对应的图书比较少，只能阅读

    Envoy + Istio的官方文档，但这没有关系，会稍微难阅读点，但多读两遍就可以啦，毕竟我们不是天才，也不是这个领域的专家。

    非鸡汤： 如果 money 允许的话，Safari Books Online 的服务还是值得个人或

    者团队订阅的。另外时不时重新阅读一下官方文档，毕竟官方文档还是最权威的，也

    是最新的。阿里工程师的自我修养 < 71

    视频学习

    之前个人是看书比较多，视频学习方面最多是在youtube上看一下大会的视

    频。 近一年比较关注视频教学。

    视频和图书有什么区别？

    首先图书编写比较费时(packtpub的快餐书除外)，图书作者要有一定的写作水

    平，这点对技术牛但写作不在行的人或者没有充裕时间的人就比较麻烦了。Java程

    序员可能比较了解 Josh Long 这个人，他的《Cloud Native Java》花了一年多的

    时间才出版，而期间他已经发了非常多的视频。

    视频还有一些文字表达不了的功能：图书中只会贴一段代码，而视频中这些代

    码是需要输入的，这时你会发现作者很多的黑科技或者黑技巧，你也能学习到。如

    React入门书籍中，一般只会说明或者引用Redux，而教学视频中，会打开对应的

    网站，给你列举一些重点特性。另外图书中一些比较容易忽略的东西，在视频中可能

    会被很好地补充。而且很多的视频制作者，本身是来自框架和技术的开发团队，而不

    是第三方的图书作者，所以新鲜度和技巧性都非常明显。

    不少人对大段文字，尤其是理论和学术很强的图书比较过敏。比如很多人问如何72 > 阿里工程师的自我修养

    学习 domain driven design，但是能将 DDD 图书看完 2-3 章不犯困的就很难得。

    主要是因为文字太多，没有什么代码，又不像小说有情节，不犯困反而很难的。反

    之，DDD培训视频就不一样，PPT制作得非常好，而且有动画，相关的说明贴切，更容易学习。

    这里列举一下比较有名气的视频培训网站，有 Pluralsight, Lynda 和 Udemy 等。

    Udemy的视频是需要单个购买的，一个3-4个小时的视频需要10刀。如果你

    的阅读量比较大，花费会比较多，而且Udemy不是只关注IT，专业度方面会不够。

    Lynda 和 Pluralsign 都是会员制的，你交会费后，可以看所有的视频教学。 Lynda

    内容非常多，很多人反映内容过时，我个人没有订阅过，搜索一下确实有这个感觉。

    个人推荐Pluralsight，这个也是我订阅的服务。内容非常多也比较新，而且有

    一些是系列的，对跨界学习帮助特别大。 如在做Service Mesh的时候，可能涉及

    到 SDN，让我在Safari上阅读一本SDN的图书，我只能说臣妾做不到，尤其跨界学

    习的同学，难读啊。但是Pluralsight上一个2个小时的视频教学，我马上就看懂啦。

    Java 程序员要学 ES 6 + React 开发，如果找 JavaScript 图书先看，然后再 React

    图书，周期太长，而 Pluralsight 上一个 ES 6 + React Learning Path 视频教学，马上让你快速入门、投入开发。回头把图书和文档补充一下，知识也一起巩固了。

    非鸡汤： 还是 money 问题。条件允许的话，购买一个 pluralsight 会员，每月

    29刀，绝对非常值得。Pluralsight的视频基本都有英文字幕，配合作者的ppt，英

    语不好的同学学习也没有问题。下班没事的时候，找个会议室，几个志同道合的同

    学，搞点饮料，播放一个跨界或者新技术的视频，看完20分钟，大家讨论一下。英

    文好的、有技术功底的同学多发表一些观点，其他的同学都也都能了解。阿里工程师的自我修养 < 73

    技术新闻，twitter上技术大牛 参加技术大会

    前面介绍的图书、文档和视频教学，让我们可以了解和深入某一项技术，对付

    工作应该没有问题。但如果要紧跟潮流，获取灵感，可能还需要关注一些技术新闻，follow twitter上的技术大牛。

    每个人都有惰性，大牛也不例外。有时候他们可能不会写文章、文档或者拍视

    频，只会随意说一下。比如，我第一次了解Spring Fu这个技术时，是在Twitter

    上。项目还没有启动，Kotlin + Spring的核心团队就开始不经意流露一些消息，你可

    能由此获得不错的想法，而且大牛会转发技术新闻，这些新闻都经过他们过滤的，你

    挑选的成本也就低很多啦。

    技术新闻没有很好的地方平台统一管理，相对凌乱一些，你需要有自己的方

    法，不然找寻成本比较高。 很多人喜欢 Hacker News (https:news.ycombinator.

    com)，但是没有归类，这个有点麻烦。https:thenewstack.io 的归类好很多。

    Google Reader 关闭后，个人转投 Feedly，还是有订阅blog的习惯。

    Medium (https:medium.com)非 常 不 错， a place to read and write big 74 > 阿里工程师的自我修养

    ideas and important stories，这里推荐一下，很多技术牛人在 Medium 上，不少

    技术公司的blog也都在medium上有文章。据说还有付费的会员，个人没有尝试

    过，强烈推荐。 reddit可以归类一些topic，关注一下。 如果你持续关注某一技术，最好加入该技术的Slack或者gitter讨论群，大家都会在群里将相关的好新闻、技术

    文章进行分享，我在的Kotlin Slack中就了解非常多新的框架和关联技术，大家毕竟

    还是乐意分享的。

    如果时间和金钱都允许的话，个人建议可以参加技术大会，毕竟现场氛围是不一

    样的。2-3天内，不用工作，不想其他事情，围绕这个话题，而且keynote，和众多

    同行在一起，这种感觉是不同的。你需要坚信你找对了一个方向，让你更有动力深入

    了解下去。技术大会有很多的展台，将这个行业非常优秀的企业和技术聚集起来，也

    是非常不容易的。

    非鸡汤： Twitter上技术大牛follow一下，关注对应的技术新闻和blog，平时逛

    逛slack和gitter，还是有一定的收获的。技术大会一般是美国较多，这对英文和独

    立出行有些挑战。大家可以结伴或找当地的同学接待，成本会低不少。但是目前技术

    大会的门票都非常高，基本上都是1500-2000刀，早点订可能在1000刀左右。虽

    然时间成本稍微高一些，但 95%到 99% 的提升就是要花更多时间、精力和金钱。

    做项目，写 Demo，看源码

    前面说了学习，但是程序猿不写Demo是不行的。项目中可以考虑尝试新的阿里工程师的自我修养 < 75

    技术。我们现在推行微服务，所以技术栈还是有自由度的，就看你能否hold住啦。

    不一定所有的技术都能用到项目中，有些是启发性的或者触类旁通的，你需要写

    Demo，磨磨刀没有错的。文章前面说过，工具要非常熟练，不然一个demo花掉一

    个小时不值得。读了很多，看了很多，如果再用代码辅助一下，就更好啦。我不是说

    这些知识都是为了代码，不少是为了架构的。比如，学习ES 6 + React，如果没有

    代码，很难想象要如何掌握这个知识。

    看源码是非常重要的一个技能。至少你code review技能提升，但成本确实高。

    个人是对 Kubernetes 还算比较了解，但是让我看 Kubernetes 源码，压力很大，尤

    其是不擅长的领域。看Spring Fu的源码没有问题，但是要看Istio和Envoy源码，压力太大。但是你如果决定投入，看源码帮助还是很大的。

    非鸡汤： 项目中多尝试一下你学到的新知识，不能惯性使用你熟悉的技术，要知

    道你熟悉的东西很快会被淘汰，被淘汰后再调整就来不及了。多写一些demo，多磨

    磨刀。对你本行业的技术，一些源码还是要能看懂的。跨界技术，阅读源码量力而

    为，让 Java 程序去看 JS框架源码或者 C++ 源码，是需要心理准备的。

    如今阅读的人少了

    看到youtube上一个技术人员讲述阅读的观点，还是比较独特的。 其实现代人

    阅读量是比以前多，每天打开手机，各种新闻、文章、视频和朋友圈，阅读量相较以

    前变大了。对比图书等，这些知识只是生命周期太短，而且营养不高，这也是为何大

    家觉得阅读少的原因，没有帮助你增长知识。

    如果你不是产品经理或者需要对行业进行分析，就技术人员来说，新闻类app

    对你来说可能用处不大。 这些新闻都是帮助你找找聊天话题，做为饭后谈资，没有什

    么大用，反而浪费你不少时间，你可能半个小时都在刷新闻，而且现在新闻都有智能

    算法，保证能黏住你。大家都在抢用户时间，他们可不会在乎你的知识进步，就是让

    你停留时间长点，多看一些广告。

    非鸡汤：音乐是不错的，好像有针对程序员编码的音乐，个人不是发烧友，但是

    还是推荐一下。76 > 阿里工程师的自我修养

    适当的硬件支持

    进办公室看一下同事的电脑，你就大概能区分一些职业。用13寸的MacBook

    Pro 或者 Air，绝对不是 Java 程序员。如果是 Golang 或者 C++ 程序员，一定不会

    用 JetBrains 的 IDE 工具，基本都是 Editor 类等。对硬件建议仅仅适合 Java 类的

    程序员，硬件好点是让你速度更快。苹果最新的 MacBook Pro 2018 确实非常不错，终于有 32G内存，大家可以考虑入手。阿里工程师的自我修养 < 77

    从计算机知识到落地能力，你欠缺了什么？

    作者： 蛰剑 技术专家

    阿里妹导读：本文是一个理论过度到实践的典型案例，借助程序员经常遇到的一

    个问题——网络为什么不通，来具体说明怎么将书本上的死知识真正变成我们解决问

    题的能力。

    大学学到的基本概念

    我相信你脑子里关于网络基础知识的概念都在下面这张图中。知识内容有点乱，感觉都认识，又都模模糊糊，更谈不上将内容转化成生产力或是用来解决实际问题

    了。这是因为知识没有贯通、没有实践、没有组织。78 > 阿里工程师的自我修养

    上图中知识点的作用在RFC1180[1]

    中讲得无比通俗易懂了。看第一遍的时候也

    许你就看懂了，但是一个月后又忘记了。其实这些东西我们在大学也学过，但还是

    忘了(能够理解，缺少实操环境和条件)，或者碰到问题才发现之前看懂了的东西其

    实没懂。

    所以接下来我们将示范书本知识到实践的贯通过程，希望把网络概念之间的联系

    通过实践来组织起来。

    还是从一个问题入手

    最近的环境碰到一个网络ping不通的问题，当时的网络链路是(大概是这样，略有简化)：阿里工程师的自我修养 < 79

    现象

    ● 从容器 1 ping 物理机 2 不通；

    ● 从物理机 1 上的容器 2 ping物理机 2 通；

    ● 同时发现即使是通的，有的容器 ping物理机1只需要0.1ms，有的容器需要

    200ms 以上(都在同一个物理机上)，不合理；

    ● 所有容器 ping 其它外网 IP(比如百度)反而是通的。

    这个问题扯了一周才解决是因为容器的网络是我们自己配置的，交换机我们没有

    权限接触，由客户配置。出问题的时候都会觉得自己没问题对方有问题，另外就是对

    网络基本知识认识不够，所以都觉得自己没问题而不去找证据。

    这个问题的答案在大家看完本文的基础知识后会总结出来。

    解决这个问题前大家先想想，假如有个面试题是：输入 ping IP 后敲回车，然后

    发生了什么？

    复习一下大学课本中的知识点

    要解决一个问题你首先要有基础知识，在知识欠缺的情况下就算逻辑再好、思路

    再清晰、智商再高，也不一定有效。

    route 路由表80 > 阿里工程师的自我修养

    假如你在这台机器上 ping 172.17.0.2 ，根据上面的 route 表得出 172.17.0.2

    这个 IP符合下面这条路由：

    这条路由规则，那么 ping 包会从 docker0 这张网卡发出去。

    但是如果是 ping 1.1.4.4 根据路由规则就应该走 eth0 这张网卡而不是 docker0

    了。接下来就要判断目标 IP是否在同一个子网了。

    ifconfig

    首先来看看这台机器的网卡情况：

    这里有三个网卡和三个IP，三个子网掩码(netmask)。根据目标路由走哪张网

    卡，得到这个网卡的子网掩码，来计算目标 IP是否在这个子网内。

    arp 协议

    网络包在物理层传输的时候依赖的mac 地址而不是上面的IP地址，也就是根据阿里工程师的自我修养 < 81

    mac 地址来决定把包发到哪里去。

    arp协议就是查询某个IP地址的mac地址是多少，由于这种对应关系一般不太

    变化，所以每个os都有一份arp缓存(一般15分钟过期)，也可以手工清理，下面

    是 arp缓存的内容：

    进入正题，回车后发生什么？

    有了上面的基础知识打底，我们来思考一下 ping IP 到底发生了什么。

    首先 OS 的协议栈需要把ping命令封成一个icmp包，要填上包头(包括

    src-IP、mac地址)，那么OS先根据目标IP和本机的route规则计算使用哪个

    interface( 网卡)，确定了路由也就基本上知道发送包的 src-ip 和 src-mac 了。每

    条路由规则基本都包含目标 IP范围、网关、MAC 地址、网卡这样几个基本元素。

    如果目标 IP 和本机使用的 IP 在同一子网

    如果目标IP和本机IP是同一个子网(根据本机ifconfig上的每个网卡的

    netmask来判断是否是同一个子网——知识点：子网掩码的作用)，并且本机arp缓

    存没有这条IP对应的mac记录，那么给整个子网的所有机器广播发送一个 arp查

    询，比如我 ping 1.1.3.42，然后tcpdump抓包首先看到的是一个 arp请求：82 > 阿里工程师的自我修养

    上面就是本机发送广播消息，1.1.3.42 的 mac 地址是多少？很快 1.1.3.42 回

    复了自己的mac地址。 收到这个回复后，先缓存起来，下个ping包就不需要再次

    发arp广播了。 然后将这个mac地址填写到ping包的包头的目标Mac(icmp包)，然后发出这个 icmp request包，按照 mac 地址，正确到达目标机器，然后对方正确

    回复icmp reply(对方回复也要查路由规则，arp查发送方的mac，这样回包才能正

    确路由回来，略过)。

    来看一次完整的 ping 1.1.3.43，tcpdump抓包结果：

    我换了个IP地址，接着再ping同一个IP地址，arp有缓存了就看不到arp广

    播查询过程了。

    如果目标 IP 不是同一个子网

    arp只是同一子网广播查询，如果目标IP不是同一子网的话就要经过本IP网关

    进行转发(知识点：网关的作用)。如果本机没有缓存网关mac(一般肯定缓存了)，那么先发送一次arp查询网关的mac，然后流程跟上面一样，只是这个icmp包发到

    网关上去了(mac 地址填写的是网关的 mac)。

    从本机 1.1.3.33 ping 11.239.161.60 的过程，因为不是同一子网按照路由规则

    匹配，根据 route 表应该走 1.1.15.254这个网关，如下截图：阿里工程师的自我修养 < 83

    首先是目标IP 11.239.161.60 符合最上面红框中的路由规则，又不是同一子

    网，所以查找路由规则中的网关 1.1.15.254的 Mac 地址，arp cache中有，于是将

    0c:da:41:6e:23:00 填入包头，那么这个 icmp request 包就发到 1.1.15.254 上了，虽然包头的 mac 是 0c:da:41:6e:23:00，但是 IP还是 11.239.161.60。

    看看目标IP 11.239.161.60 真正的mac信息(跟ping包包头的Mac是不同的)：

    这个包根据 Mac 地址路由到了网关上。

    网关接下来怎么办？

    为了简化问题，假设两个网关直连

    网关收到这个包后(因为mac地址是它的)，打开一看IP地址是

    11.239.161.60，不是自己的，于是继续查自己的 route 和 arp 缓存，发现

    11.239.161.60 这个 IP 的网关是 11.239.163.247，于是把包的目的 mac 地址改成84 > 阿里工程师的自我修养

    11.239.163.247的 mac 继续发出去。

    11.239.163.247 这个网关收到包后，一看 11.239.161.60 是自己同一子网的

    IP，于是该arp广播找mac就广播，cache有就拿cache的，然后这个包才最终到

    达目的 11.239.161.60 上。

    整个过程中目标mac地址每一跳都在变，IP地址不变，每经过一次MAC变化

    可以简单理解成一跳。

    实际上可能要经过多个网关多次跳跃才能真正到达目标机器。

    目标机器收到这个 icmp包后的回复过程一样，略过。

    arp 广播风暴和 arp 欺骗

    广播风暴：如果一个子网非常大，机器非常多，每次arp查询都是广播的话，也

    容易因为 NN的问题导致广播风暴。

    arp欺骗：同样如果一个子网中的某台机器冒充网关或者其他机器，当收到arp

    广播查询的时候总是把自己的mac冒充目标机器的mac发给你，然后你的包先走到

    他，再转发给真正的网关或者目标机器，所以在里面动点什么手脚，看看你发送的内

    容都还是很容易的。

    讲完基础知识再来看开篇问题的答案

    读完上面的基础知识相信现在我们已经能够回答 ping IP 后发生了什么。这些已

    经足够解决99%的程序员日常网络中网络为什么不通的问题了。但是前面的问题比

    这个要稍微复杂一点，还是依靠这些基础知识就能解决——这是基础知识的威力。

    现场网络同学所做的一些其它测试：

    怀疑不通的IP所使用的mac地址冲突，在交换机上清理了交换机的arp缓存，没有帮助，还是不通；

    新拿出一台物理机配置上不通的容器的IP，这是通的，所以负责网络的同学坚

    持是容器网络的配置导致了问题。

    对于1能通，我认为这个测试不严格，新物理机所用的mac不一样，并且所接

    的交换机口也不一样，影响了测试结果。阿里工程师的自我修养 < 85

    祭出万能手段——抓包

    抓包在网络问题中是万能的，但是第一次容易被tcpdump抓包命令的众多参数

    吓晕，不去操作你永远上不了手，差距也就拉开了，你看差距有时候只是你对一条命

    令的执行。

    在物理机 2上抓包：

    这个抓包能看到核心证据，ping包有到达物理机2，同时物理机2也正确回复

    了(mac、ip都对)。

    同时在物理机1上抓包(抓包截图略掉)只能看到ping包出去，回包没有到物理

    机 1(所以回包肯定不会回到容器里了)。

    到这里问题的核心在交换机没有正确地把物理机 2的回包送到物理机 1 上面，同

    时观察到的不正常延时都在网关那一跳：86 > 阿里工程师的自我修养

    最终的原因

    最后在交换机上分析包没正确发到物理机1上的原因跟客户交换机使用了HSRP

    (热备份路由器协议，就是多个交换机HA高可用，也就是同一子网可以有多个网关的

    IP)，停掉 HSRP后所有 IP容器都能通了，并且前面的某些容器延时也恢复正常了。

    通俗点说就是HSRP把回包拐跑了，有些回包拐跑了又送回来了(延时

    200ms 那些)

    至于HSRP为什么会这么做，要厂家出来解释了。这里关键在于能让客户认同

    问题出现在交换机上还是前面的抓包证据充分，无可辩驳。实际中我们都习惯不给证

    据就说：我的程序没问题，就是你的问题。这样表述没有一点意义，我们是要拿着证

    据这么说，对方也好就着证据来反驳，这叫优雅地甩锅。

    网络到底通不通是个复杂的问题吗？

    讲这个过程的核心目的是除了真正的网络不通，有些是服务不可用了也怪网络。

    很多现场的同学根本讲不清自己的服务(比如80端口上的tomcat服务)还在不在，网络通不通，是网络不通呢还是服务出了问题。一看到 SocketTimeoutException

    就想把网络同学抓过来羞辱两句：网络不通了，网络抖动导致我的程序异常了(网络

    抖动是个万能的扛包侠)。

    实际这里涉及到四个节点(以两个网关直连为例)，srcIP -> src网关 -> dest

    网关 -> destIP。如果 ping不通 ( 也有特殊的防火墙限制 ping 包不让过的)，那么在

    这四段中分段ping(二分查找程序员应该最熟悉了)。 比如前面的例子就是网关没有

    把包转发回来。

    抓包看 ping包有没有出去，对方抓包看有没有收到，收到后有没有回复。

    ping自己网关能不能通，ping对方网关能不能通。

    接下来说点跟程序员日常相关的

    如果网络能 ping 通，服务无法访问

    那么尝试telnet IP port 看看你的服务是否还在监听端口，在的话再看看服务进阿里工程师的自我修养 < 87

    程是否能正常响应新的请求。有时候是进程死掉了，端口也没人监听了；有时候是进

    程还在但是假死了，所以端口也不响应新的请求了，还有的是TCP连接队列满了不

    能响应新的连接。

    如果端口还在也是正常的话，telnet 应该是好的：

    假如我故意换成一个不存在的端口，目标机器上的 OS直接就拒绝了这个

    连接(抓包的话一般是看到 reset标识)：

    一个 SocketTimeoutException，程序员首先怀疑网络丢包的 Case

    当时的反馈应用代码抛 SocketTimeoutException，怀疑网络问题：

    1. 业务应用连接 Server 偶尔会出现超时异常；

    2. 业务很多这样的异常日志：[Server SocketTimeoutException]

    检查一下当时的网络状态非常好，出问题时间段的网卡的量信息也非常正常：

    上图是通过 sar监控到的 9 号 v24d9e0f23d40 这个网卡的流量，看起来也是正

    常，流量没有出现明显的波动。

    为了监控网络到底有没有问题，接着在出问题的两个容器上各启动一个http 88 > 阿里工程师的自我修养

    server，然后在对方每 1 秒钟互相发一次发 http get 请求访问这个 http server，基

    本认识告诉我们如果网络丢包、卡顿严重，那么我这个http server的监控日志时间

    戳也会跳跃，如果应用是因为网络出现异常那么我启动的 http服务也会出现异常——

    宁愿写个工具都不背锅(主要是背了锅也不一定能解决掉问题)。

    从实际监控来看，应用出现异常的时候我的http服务是正常的(写了脚本判断日

    志的连续性)：

    这也强有力地证明了网络没问题，所以写业务代码的同学一门心思集中火力查看

    应用的问题。后来的实际调查发现是应用假死掉了(内部线程太多，卡死了)，服务端

    口不响应请求了。

    如果基础知识缺乏一点那么甩过来的这个锅网络是扛不动的，同时也阻碍了问题

    的真正发现。

    TCP协议通讯过程跟前面ping一样，只是把ping的icmp协议换成TCP协

    议，也是要先根据 route，然后arp。阿里工程师的自我修养 < 89

    总结

    网络丢包、卡顿、抖动很容易做扛包侠，只有找到真正的原因解决问题才会更

    快，否则在错误的方向上怎么发力都不对。准确的方向要靠好的基础知识和正确的逻

    辑以及证据来支撑，而不是猜测。

    ● 基础知识是决定你能否干到退休的关键因素；

    ● 有了基础知识不代表你能真正转化成生产力；

    ● 越是基础，越是几十年不变的基础越是重要；

    ● 知识到灵活运用要靠实践，同时才能把知识之间的联系建立起来；

    ● 简而言之缺的是融会贯通和运用；

    ● 做一个有礼有节的甩包侠；

    ● 在别人不给证据愚昧甩包的情况下你的机会就来了。

    留几个小问题：

    1. server 回复 client 的时候是如何确定回复包中的 src-ip 和 dest-mac 的？

    一定是请求包中的 dest-ip当成 src-ip吗？

    2. 上面问题中如果是 TCP 或者 UDP 协议，他们回复包中的 src-ip 和 dest-

    mac 获取会不一样吗？

    3. 既然局域网中都是依赖 Mac 地址来定位，那么 IP的作用又是什么呢？

    参考资料：

    [1] https:tools.ietf.orghtmlrfc1180

    [2] https:tools.ietf.orghtmlrfc1180

    《计算机基础》90 > 阿里工程师的自我修养

    阿里资深技术专家的 10 年感悟

    作者：无相 资深技术专家

    阿里妹导读：阿里有许多土话，比如“方法总比困难多”、“不淘汰自己就会被别

    人淘汰”、“你感觉不舒服的时候，就是成长的时候”。每一句都在激励我们向前。生

    活总不缺困难和磨练，痛苦的时候，只有转变思维，才能蜕变。今天，阿里巴巴资深

    技术专家无相分享他在阿里这10年来的几点感悟。今天很残酷，明天更残酷，后天

    很美好，熬过明天晚上，才能看到后天的太阳。

    插件版本更新阿里工程师的自我修养 < 91

    2019 年的上半年，我密集地写了 tbbpm idea 插件，终于比较圆满地解决 idea

    插件的开发问题。经过这件事，内心有股强烈的冲动，促使我写下这些年面对痛苦

    时，我的一些解决问题的方法和感悟。

    1. 一个人走得快，一群人走得远

    “一个人走得快，一群人走得远”，这句话是阿里的土话。没有这些年的编程经

    历，不会深刻地感受这句话背后逻辑与力量。一个人持续做一件工作量较大且较长期

    的事情时，对心力的考验是很大的。当多人协同时，心力压力能够得到很大的缓解。

    Knowledge is commonly socially constructed, through collaborative

    efforts toward shared objectives or by dialogues and challenges brought

    about by differences in persons’ perspectives.

    Salomon

    《The Costs and Benefits of Pair Programming》这篇论文的研究表明：结对

    编程能够改进设计质量，减少代码缺陷(代码行数减少，测试通过率更高)，减少员工

    离职风险，提升软件技能。团队解决问题的速度变快，同时更加愿意坐到一起工作。92 > 阿里工程师的自我修养

    2. 当你不舒服，难受或陷于困境时，应该停下来思考

    在写 tbbpm idea 插件时，我花了三年(准确来说是 3 个春节)才写成，idea 的

    设计插件在业界无参考标准，不能很好地快速进行。记得在 eclipse tbbpm 插件时，因有业界源码参考，用了两个通宵原型就做出来了。Tbbpm 是一个闲暇时间的产物，只能利用春节这样的大长假才能开发。我希望自己能够在极短的时间内完成，然而，第一个春节与第二个春节都没有成功。在第三个春节时，关键的拖拽依然没有很好的

    搞定，心力已经接近憔悴。屡次失败之后，我不得不开始反思，是不是我做这件事的

    方式错了？是不是我的欲望已经超越了我当前的能力。

    于是，那时候我停下手头的工作，冷静的地思考了 2天。

    这里举个当时的例子，idea 插件绘制表单的困境：因为用 swing 的方式来构

    建流程时，使用很多原生的库、GUI、JformBuilder，觉得画一个表单很困难， 尽

    管有些产品商已经用了，依然非常难用。静下来思考后，通过 google，找到了

    miglayout 这个库，问题才得以解决。

    困境是个人成长的最好机会，放弃、逃避、拒绝思考，就意味着放弃成长。如果

    遇到困境不自知，不解决，则会出现昨日所不知不能者，今日仍是不知不能；去年所

    不知不能者，今年仍是不知不能。

    同时，最近有很多同学向我反馈，遇到困境时，通过个人的努力依然不能突破。

    这种情况下，可以尝试另外一条路，像《能力陷阱》这本书所说的一样，可以引入外

    部的力量。

    3. 学习能力与思维模式是一个人的核心竞争力

    没有自学能力的人没有未来。 李笑来

    3.1 首先承认自己的不足

    Stay foolish, stay hungry.

    我们要承认一个基本的逻辑事实是: 任何事情不是天生就能精通，要通过训练才

    能达到优秀的程度。很多事物的判断能力，要是逐步建立的。只有意识到自己的不阿里工程师的自我修养 < 93

    足，才能觉悟，去学习进步。

    网上看到一张图《how to draw a horse》深有感触：

    图片来源：https:oktop.tumblr.compost1535278084694 > 阿里工程师的自我修养

    这个漫画显示的哲理：有时最后一步，你要付出非常多的努力。任何高水平的技

    术或思维模式，都需要付出努力，并非生而得来。

    3.2 掌握优秀的学习方法：

    如何证明一个人有比较优秀的学习能力？学习做到目到，口到，心到。

    读书要目到，口到，心到。尔读书不看清这画偏旁，不辩明句读，不记清首尾，是目不到也。喉，舌，唇，牙，齿五间音并不清晰伶俐，蒙笼含糊，听不明白，或多几字，或少几字，只图混过就是，是口不到也。经传精义奥皆初学固不能

    通，至于大略粗解原易明白，稍肯用心体会，一字求一字下落，一句求一句道

    理，一事求一事原委，虚字审其神气，实字测其义理，自然渐有所悟。一时思索

    不得，即请先生解说，一时尚未融稀，即将上下文或别章别部义理相近者反复推

    寻，务期了然于心，了解于口，始可放手。总要将此心运在字里行间，时复思

    绎，乃为心到。

    左宗棠 《与孝威孝宽》

    当你能完全能用自己的语言准确讲述你所学的知识，知其然，并知其所以然，你

    才是真正完全的掌握。对于工程师来说，学习要做到目到、口到、心到、手到。

    3.3 掌握搜索信息的有效方式

    现代是一个信息非常充分乃至爆炸的信息社会。如何高效获取信息，分析信息是

    非常重要的能力。相对常规的模式是：当你发现问题，定义出问题，就去搜索业界最

    优秀的解决方案，并且花时间研究方案，了解原理，最后不断地学习实践。这种方式

    能够有效保证你对问题的解决方案是相对优秀的解决方案。公司对高层级的同学，必

    须有业界全局的视眼与思考。

    如何提升获取的信息质量，这里有一些建议：

    ● 精确定位问题

    ● 梳理出关键字与概念

    ●“全网”搜索阿里工程师的自我修养 < 95

    ● 分析研究

    ● 实践结论假设

    3.4 具备优秀的批判性思维模型

    在《批判性思维工具》一书中，对思维的水平分了三个层次：较差、中等、最佳

    水平的思考(如下图1)。当前很多同学可能在多数问题上都处于较差水平层次，很多

    认知来自直觉或者自我视角。最佳水平的思考要做到三点：全局、公正、客观。

    图片来源：《批判性思维工具》

    另外，多数人终生停留在鲁莽的思考阶段。鲁莽的思考者，不知道如何确定自己

    的目的是否清晰，不知道自己的假设是否公正，不知道自己的结论是否符合逻辑。如

    果没有思考的概念，也就从不会对自己的思维进行反思。96 > 阿里工程师的自我修养

    图片来源：《批判性思维工具》

    左宗棠的学习方法与国外的《批判性思维工具》，都在要求我们把自身脑海中不

    清晰的概念与逻辑梳理清楚，建立满足第一性原理的认知体系与评判标准。幸好在当

    今互联的信息社会，很多人已经开始这样做了，所以从小就受“填鸭”式教育的我

    们，更需要奋力精进。阿里工程师的自我修养 < 97

    参考资料：

    1.结对编程

    2.李笑来的自学

    3.怎么变成一个更好的程序员

    4.找到高质量信息指引98 > 阿里工程师的自我修养

    如何量化考核技术人的 KPI？

    作者： 张建飞 高级技术专家

    阿里妹导读：对技术人来说，技术是成长的“核心”。然而，在实际工作协作中，技术的重要性常常被业务所掩盖，造成先业务后技术的现象。

    针对这个痛点，阿里高级技术专家张建飞提出了自己的解决思路，希望能与大家

    一起探讨、交流。

    为什么需要技术 KPI？

    在业务技术团队，有一个不好的趋势就是团队越来越业务，越来越没有技术味

    道。每个人都在谈业务，技术大会上在谈业务，周会上在聊业务，周报里写的是业务

    项目……

    唯独少被谈及的是技术本身。此处并不是说业务不重要，而是说理解业务和把控

    业务需求是技术人员的 base，而不是全部。阿里工程师的自我修养 < 99

    将就的代价

    这种技术味道的缺失对技术团队来说是非常可惜的，也不利于技术人员的成长和

    发展。因为很难想象一个没有技术追求的团队能开发出一个健壮的、可维护性好、可

    扩展性好的系统。相反，这种业务代码的堆砌，从短期看也许是“较快”实现了业务

    需求，但是从长远来看，这种烂系统的增加会极大的阻碍业务的发展，形成一个个的

    黑洞应用，而工程师被裹挟在业务需求和烂系统之间，疲于应对，心力交瘁。

    这种将就将导致系统腐化，技术债越垒越高，像肿瘤一样消耗你所有的能量。

    我不是药神，只能尝试开出一方——那就是在不影响业务的情况下(特别是相对

    稳定的业务，请拒绝业务方的时间倒排)，Tech Story应该和User Story有同等的

    重要性，要把重构优化提到和业务需求相等的优先级去处理。我们不仅要对业务需求

    负责，我们更要对应用的质量，系统的可维护性负责。

    因为我们技术人员是应用的父母(有些是亲生父母，有些是养父母)，你不照顾它

    们，不治理它们，它们就会生病，你忍心看到这样的局面吗？

    技术管理者者(TL)的失职

    造成这种局面，我们的技术管理者，我们的TL要负有主要责任。如果一个TL

    从来不关注系统架构和设计，从来不写code，对技术没有热情也不学习，甚至其本100 > 阿里工程师的自我修养

    身技术就很烂，那么在这个TL领导下的技术团队，又怎么会有技术味道，团队成员

    又怎么能进步和成长？

    现在很多的TL每天都混迹在各种会议上，很忙，做着各种沟通协调的事情，可

    是我们真的需要这么多的会议、这么多的沟通吗？

    如果沟通的结果只是做业务和PD对团队的传话筒，没有业务创新，没有用技术

    和数据系统化的解决业务问题，没有在技术方向和架构上给团队指引，没能切实的帮

    助系统优化、团队提效，请问这样的沟通给业务带来了什么价值，给团队带来了什么

    价值？还是沉下心来，多看看书，哪怕非技术的书也好。多写写代码，哪怕跟业务无

    关的代码也好。

    所以，我们要回归技术本身。我们不需要这么多“高高在上”、“指点江山”的技

    术Manager，而是需要能真正深入到系统里面，深入到代码细节，给团队带来实实

    在在改变的技术 Leader。阿里工程师的自我修养 < 101

    技术 KPI的量化

    提升技术氛围，打造工程师文化不能仅停留在口头上，可搭配一定的强制手段，比如和技术人员的利益绑定。这种绑定就需要我们能对技术贡献进行一个相对公平的

    分解和量化。

    技术 KPI

    基于此，我将技术人员的KPI分解为业务贡献、技术贡献和团队贡献三个大的

    部分，其详细内容如下。

    ● 业务贡献：包括需求把控，业务项目和业务创新。

    ● 技术贡献：包括设计重构、技术影响力、Code Review、创新提效和代码质量。

    ● 团队贡献：包括招聘、新人培养和团队氛围。

    那么技术贡献中的这几个维度要怎么理解呢，解释的话我就不多说了，用我们工

    作中的一些案例来描述一下吧。

    应用质量：

    1. 你负责或者共同负责的应用质量分(可以从代码重复率，圈复杂度，分层合理

    性等维度考察)。

    2. 你做了哪些提升应用质量分的工作。

    设计重构：

    1. 我在客户通项目中，对 CRM 销售域进行了领域建模和设计，并且抽象合理。

    2. 我发现 Infrastructure 中 package 分类不合理，进行了重新设计并重构完成。

    3. 我发现现在系统中错误码比较混乱，我梳理制定了新的错误码规范，并完成

    了代码重构。

    技术影响力：

    1. 在团队内分享 10 篇干货，点赞数 1000。102 > 阿里工程师的自我修养

    2. 团队分享策略模式，得到同学好评 。

    3. 我接受邀请，在行业会议上分享了 SOFA架构。

    Code Review：

    1. 我在 review 某某代码的时候发现，可能存在线程不安全的隐患。

    2. 我在review某某代码的时候发现，存在设计不合理的现象，此处使用责任链

    可以很优雅的解决问题，并具备一定的扩展性。

    创新提效：

    1. 我发现本地测试启动 PandoraBoot 比较浪费时间，所以写了一个 TestCon-

    tainer 大大提升了自测效率。

    2. 我发现有一些boilerplate代码不需要写，所以对乐观锁、分页进行了

    annotation 支持，简化了代码。

    3. 在某个项目或者技术点上面，我产出了一篇专利：基于领域模型的业务配置化。

    代码质量：

    1. 提测后的 Bug 数，线上故障数(系统可以提取，不用自己填写)

    2. 我完善了某某模块的单元测试，并多次在自动化回归中发现问题。

    KPI答疑

    对于上面的KPI大部分的技术同学是表示认可的，当然质疑的声音也很多，我

    这里挑一些典型的回答一下。

    Q： 技术 KPI的提出，会不会导致技术同学只关注技术不做业务项目了？

    A： 关于绩效，肯定是综合看业务贡献，技术贡献和团队贡献。但是作为一个重

    要参考和风向标，技术 KPI是有积极意义的。

    Q： 你这个设计重构怎么量化？

    A： 这个很难用系统标准化，更多的还是要依赖TL的专业能力进行评分，但即阿里工程师的自我修养 < 103

    使是这样，也比以前什么都没有完全黑盒要强。至少在传达一个信息，我们

    鼓励好的设计，鼓励不断地重构优化。

    Q：我们现在的业务需求已经在堆积，一线同学根本没有时间去做重构优化。

    A： 这个问题开篇其实已经说过了，你是要不断地裹挟在业务需求和烂代码里面

    呢，还是花时间improve，然后更快地支持业务。这个权衡应该不难做，关

    键是要看决心和能力。对于很多业务，我没有看到推迟几天上线就会影响业

    务格局的业务场景，所以作为技术团队，我们就应该在User Story之外，加上我们的Technical Story，把完成业务需求和系统重构都当成我们的核

    心任务。104 > 阿里工程师的自我修养

    如何成为优秀的技术主管？你要做到这三点

    作者：云狄 高级技术专家

    阿里妹导读：技术主管，又叫「技术经理」，英文一般是 Tech Leader ，简

    称 TL。随着工作经验的不断积累，能力的不断提升，每个人都有机会成为Team

    Leader。然而在机会到来前，我们必须提前做好准备，对TL的工作职责有一定了

    解。当然，这也会为当下更好地配合 TL 工作打下基础。

    阿里巴巴高级技术专家云狄将结合自己多年的经验，从开发规范、开发流程、技

    术规划与管理三个角度出发，分享对技术 TL 这一角色的理解与思考。

    「技术主管」是开发团队中的某位程序员需要对一起创建系统的整个开发团队负

    责时所承担的角色。通常他既要对最终交付的软件系统负责，另外也会像一个程序员

    一样去开发实现系统。

    一个技术主管的 60% ～ 70% 的时间可能花在了开发任务分解分配、开发实践、技术架构评审、代码审核和风险识别上，而余下的 30% ～ 40% 的时间则花在为了阿里工程师的自我修养 < 105

    保障系统按时交付所需的各种计划、协作、沟通、管理上。和团队管理者不同的是，技术主管的大部分管理工作都是针对具体研发任务和技术事务的。

    接下来基于我在技术TL这个角色上，在开发规范、开发流程、技术管理与规划

    等方面我的一些心路历程，和大家共勉。

    开发规范

    我当时负责的业务是集团收购一家子公司的业务，在整体技术标规范上与集团的

    技术标准存在很大的差异。开发规范可以说是我来到这个团队干的第一件事，我当时

    面对的问题是API接口格式混乱，没有标准的RPC服务化，代码没有统一标准的开

    发规范，技术框架组件非标准化等一系列问题，作为一名业务上的新人，我第一时间

    制定了一套相对标准、全面的技术开发规范，边写代码边梳理开发规范，引领团队走

    向统一标准化开发道路。

    针对团队研发规范暴露的上述问题，主要制定了如下规范：

    命名规范

    我自己非常注重搭建项目结构的起步过程，应用命名规范、模块的划分、目录

    (包)的命名，我觉得非常重要，如果做的足够好，别人导入项目后可能只需要10分

    钟就可以大概了解系统结构。

    具体规范包括包命名、类的命名、接口命名、方法命名、变量命名、常量命名。

    统一 IDE 代码模板

    约定了IDEAEclipse IDE代码的统一模板，代码风格一定要统一，避免不同开

    发人员使用不同模板带来的差异化以及代码merge成本。使用IDEA的同学可以安

    装 Eclipse Code Formatter插件，和 Eclipse统一代码模板。

    Maven 使用规范

    所有二方库、三方库的版本统一定义到parent pom里，这样来所有业务应用工

    程统一继承parent pom里所指定的二方库、三方库的版本，统一框架与工具的版本

    (Spring、Apache commons 工具类、日志组件、JSON 处理、数据库连接池等 )，同时要求生产环境禁用SNAPSHOT版本。这样以来升级通用框架与工具的版本，106 > 阿里工程师的自我修养

    只需要应用工程升级 parent pom 即可。

    代码 Commit规范

    基于 Angular Commit Message 规范生成统一的 ChangeLog，这样一来对于

    每次发布release tag非常清晰，Mac下都需要安装对应的插件，IDEA也有对应的

    插件，具体可以参考阮一峰老师的《Commit message 和 Change log 编写指南》。

    此刻忽然想起 Linus面对 pull request里的骚操作所发的飚：

    Get rid of it. And I don’t ever want to see that shit again. ——Linus

    代码的 commit 的规范对团队非常重要，清晰的 commit 信息生成的 release

    tag，对于生产环境的故障回滚业非常关键，能够提供一些有价值的信息。

    统一 API 规范

    统一 Rpc服务接口的返回值 ResultDTO,具体代码如下：阿里工程师的自我修养 < 107

    success 代表接口处理响应结果成功还是失败，errorCode、errorMsg 表

    示返回错误码和错误消息，module表示返回结果集，把ResultDTO定义到

    common-api 顶层二方库，这样以来各个应用不需要来回转换返回结果。

    Http Rest接口规范约定同ResultDTO相差无几，需要额外关注一下加解密规

    范和签名规范、版本管理规范。

    异常处理规范

    异常处理不仅仅是狭义上遇到了Exception怎么去处理，还有各种业务逻辑遇

    到错误的时候我们怎么去处理。service服务层捕获的异常主要包括BusinessEx-

    ception( 业务异常 )、RetriableException ( 可重试异常 ) 到 common-api，定义一

    个公共异常拦截器，对业务异常、重试异常进行统一处理，对于可重试的异常调用的

    服务接口需要保证其幂等性。

    另外其他业务层有些特殊异常不需要拦截器统一处理，内部可以进行自我消化处

    理掉，根据场景对应的处理原则主要包括：

    ● 直接返回

    ● 抛出异常

    ● 重试处理

    ● 熔断处理

    ● 降级处理108 > 阿里工程师的自我修养

    这又涉及到了弹力设计的话题，我们的系统往往会对接各种依赖外部服务、Api，大部分服务都不会有SLA，即使有在大并发下我们也需要考虑外部服务不可用对自

    己的影响，会不会把自己拖死。我们总是希望：

    ● 尽可能以小的代价通过尝试让业务可以完成；

    ● 如果外部服务基本不可用，而我们又同步调用外部服务的话，我们需要进行自

    我保护直接熔断，否则在持续的并发的情况下自己就会垮了；

    ● 如果外部服务特别重要，我们往往会考虑引入多个同类型的服务，根据价格、服务标准做路由，在出现问题的时候自动降级。

    推荐使用Netflix开源的hystrix容灾框架，主要解决当外部依赖出现故障时拖垮

    业务系统、甚至引起雪崩的问题。目前我团队也在使用，能够很好的解决异常熔断、超时熔断、基于并发数限流熔断的降级处理。

    分支开发规范

    早期的时候源码的版本管理基于 svn，后来逐步切换到 git，分支如何管理每一

    个公司(在 Gitflow的基础上)都会略有不同。

    针对分支开发规范，指定如下标准：

    ● 分支的定义(master、develop、release、hotfix、feature)

    ● 分支命名规范

    ● checkout、merge request 流程

    ● 提测流程

    ● 上线流程

    ● Hotfix流程

    虽然这个和代码质量和架构无关，按照这一套标准执行下来，能够给整个研发团

    队带领很大的便利：

    ● 减少甚至杜绝代码管理导致的线上事故；阿里工程师的自我修养 < 109

    ● 提高开发和测试的工作效率，人多也乱；

    ● 减少甚至杜绝代码管理导致的线上事故；

    ● 方便运维处理发布和回滚；

    ● 让项目的开发可以灵活适应多变的需求，多人协同开发。

    统一日志规范

    日志是产品必不可少的一个功能，具备可回溯性、能够抓取问题现场信息是其独

    一无二的优点，尤其在生产系统上问题定位等方面具有不可替代的作用。

    这里着重强调一下针对异常的日志规范：

    ● WARN和ERROR的选择需要好好考虑，WARN一般我倾向于记录可自恢

    复但值得关注的错误，ERROR代表了不能自己恢复的错误。对于业务处理遇

    到问题用 ERROR不合理，对于 catch到了异常也不是全用 ERROR。

    ● 记录哪些信息，最好打印一定的上下文(链路TraceId、用户Id、订单Id、外

    部传来的关键数据)而不仅仅是打印线程栈。

    ● 记录了上下问信息，是否要考虑日志脱敏问题？可以在框架层面实现，比如自

    定义实现 logback 的 ClassicConverter。

    正确合理的使用日志，能够指引开发人员快速查找错误、定位问题，因此约定了

    一套日志使用标准规范，现在可以更多的参考《阿里经济体开发规约——日志规约》。

    统一 MYSQL 开发规范

    表的设计和 Api 的定义类似，属于那种开头没有开好，以后改变需要花10x代

    价的，我知道，一开始在业务不明确的情况下，设计出良好的一步到位的表结构很困

    难，但是至少我们可以做的是有一个好的标准。

    统一工具与框架

    对开发过程中所用到的公共组件进行了统一抽象与封装，包括 dao 层框架

    mybatis、cache 组件 jetcache、httpclien t 组件、common-tools ( 公共工具 )，同时抽取出全局唯一 ID、分布式锁、幂等等公共组件，把以上公共组件进行集成到各110 > 阿里工程师的自我修养

    个应用，进行统一升级、维护，这样以来方便大家将更多的精力集中到业务开发上。

    开发流程

    目前团队的开发模式还是基于传统的瀑布开发模式，整体开发流程涉及需求评

    审、测试用例评审、技术架构评审、开发与测试、验收与上线，这里主要基于TL的

    角度从需求管理、技术架构评审、代码评审、发布计划评审几个关键重点环节进行探

    讨，欢迎拍砖。

    需求管理

    美国专门从事跟踪 IT 项目成功或失败的权威机构 Standish Group 的 CHAOS

    Reports 报导了该公司的一项研究，该公司对多个项目作调查后发现，百分之七十四

    的项目是失败的，既这些项目不能按时按预算完成。其中提到最多的导致项目失败的

    原因就是”变更用户需求”。另外从历年的 Standish Group 报告分析看，导致项目

    失败的最重要原因与需求有关。Standish Group 的 CHAOS 报告进一步证实了与成

    功项目最密切的因素是良好的需求管理，也就是项目的范围管理，特别是管理好项目

    的变更。

    产品因需求而生，在产品的整个生命周期中，产品经理会收到来自各个方面的阿里工程师的自我修养 < 111

    需求，但是每一个需求的必要性、重要性和实现成本都需要经过深思熟虑的分析和计

    划，避免盲目的决定需求或者变更需求，这样很容易导致工作混乱，技术TL如果不

    能正确的对需求进行把控，会导致整个项目偏离正确的轨道。

    需求管理的第一步就是要梳理不同来源的需求，主要包括从产品定位出发、外

    部用户反馈、竞争对手情况、市场变化以及内部运营人员、客服人员、开发人员的反

    馈。首先技术TL对产品有足够认知和把控，简单来说就是我的产品是为了满足哪些

    人的哪些需求而做，产品需求一定要根植于客户的需求、根植于客户的环境。每款产

    品必定有其核心价值，能够为客户创造更多的价值，基于此考 ......