一线技术人应该关注的四种思维能力

作者： 择琨

引言

作为长期奋战在一线的技术人，我深刻体会到如下几个思维能力对技术人成长的重要性，熟练运用这几种思维可以帮助我们快速的进入到新的领域，在分析、定位和解决问题上有很大帮助。

• 抽象思维：帮助我们快速抽取面对问题的关键要素和本质，可以是其他能力的“元能力”

• 分层思维：帮助我们拆解问题，分而治之，划清问题和职责边界

• 归纳思维：帮助我们从个性问题中抽象出问题的一般规律和得出共同结论

• 结构化思维：帮助我们沉淀自己的知识树，逐步系统性的思考问题

抽象能力

什么是抽象能力

提到抽象，程序员第一反应可能是 abstract，抽象能力的官方解释是这样的“抽象是从众多的事物中抽取出共同的、本质性的特征，而舍弃其非本质的特征的过程。抽象表达的是一种思维方式，用来反映事物的本质和规律的方法，抽象强调的是关注要素，隐藏额外细节”。

抽象能力是每个人自有的一种天生能力，可以让我们把一些相似的东西集中概括起来，暂时忽略他们之间的差异。当我们遇到从未见过的事物时，如果能够运用“抽象能力”去寻找记忆中的知识与现有的事物之间的联系，作为解决问题的关键要素，那么我们解决问题的效率将会大大上升，比如当我们碰到下图中左侧这个动物的时候，我们不知道它具体是什么动物，但是因为我们脑海里有一个猫科动物的抽象(如右侧)，所以通过寻找记忆中的知识，我们可以知道它是猫科动物的一种，而不会直观的把它当成一匹马。

​抽象能力的重要性

抽象能力在我们的工作中非常重要，甚至能决定一个人能力水平的上限，一个抽象能力强的人，往往能从复杂的现象中直击事物的本质。这也就是我们生活中常见到的一些人总是能抓住事情的重点、总能看到别人看不到的，或者碰到问题能够快速给出有效解决方案或思路。

抽象能力决定你是否能比别人快速掌握技能

作为一线程序员的核心本职工作是编程，编程的本质也是为了解决生活中的实际问题而存在的，通过抽象能力把现实中的内容的本质和特性抽象出来，然后抽象到系统模型上应用于工作中，通过编程的方式来解决一类问题，这也就是“设计源于生活、扎根生活，最终为生活服务”。

举一个例子，阿里西溪园区有一个做麻辣香锅的档口，比较好奇麻辣香锅是怎么做的，正好档口的加工过程是开放式的，所以我就站在那边等餐边观察他们的加工过程，下面是一个完整的流程：

麻辣香锅有 4 个工人，每个工人负责固定的实操，整个麻辣香锅的加工过程按照一个固定的流程扭转，各个工人之间交接的内容标准固定，比如上图：

工人 1: 负责的实操：称重、收银(刷工卡)、摆放(有序摆放) ，工人 1 完成摆放最后一个操作后，会把商品放到一个筐中交给工人 2；

工人 2: 负责的实操：取件(有序取件)、分类(蔬菜和肉类分开)、煮熟、装碗，工人 2 按照上述流程完成自己的工作后，将加工好的商品放到一个碗中交给工人 3；

工人 3: 负责的实操：取件、加料、炒熟、换碗，工人 3 将工人 2 加工后的商品按照上述流程完成炒熟的加工，炒熟后给到工人 4；

工人 4: 负责的实操：取件、加配料、妥投(叫号)，工人 4 负责对最后的商家做锦上添花的配料加工。

完成所有的实操之后，工人 4 通过叫号的方式客户上门自取的方式完成妥投.，整个工作流程中不需要单独有个工人来指挥调度（无状态，不需要记录当前的调度节点及进度），他们会按照既定流程完成本职工作。

在回到我的工作中，我的工作内容有一部分跟协同关系比较大，协同这部分的本质和一个麻辣烫的加工过程非常相似，区别在于一个是人之间的协同，一个是作业节点之间的协同，下面给一个协同调度流程示例：

共性抽象：

这两个看似不相关的东西其实有相同的共性，麻辣烫的每个工人等同于我们的实操节点，他们的工作等同于生成仓作业单、下发仓作业单、仓出库等，仓出库-->创建配作业单等同于工人 2[装碗]之后交给工人 3，仓出库就触发了一个协同事件，触发了工人 3 的作业，仓出库的包裹就是交接的碗(交接物)，通过这个我们把现实中的事物本质抽象成了调度协同的基本模型，包含[协同模版]、[协同节点]、[协同事件]、[工序]、[交接物]，然后通过编程系统这个能力，借助于此解决了当时域内最大的痛点：协同调度模版的爆炸式膨胀和无法动态编排的问题。因为我们把“调度协同的本质”共性抽象实现了一下，所以天然收割了一波技术红利，第一次把正逆向调度协同业务都融合进来，同时也复用到了 2C 和 2B 的其他业务域中。

下面是我们的调度升级版后的配置化页面：

本次升级也支持了调度模版的多版本控制、生效规则、审批发布流程等，也从以前一个中心化的调度升级到无状态去中心化的服务协同，降低了系统依赖、提高健壮性。

抽象能力是将复杂问题简单化的重要方法

《史记》有云：“大乐必易，大礼必简。”意思是说．“大”的音乐一定是平易近人的；“大”的礼仪则一定是简朴的。世界的表现虽然复杂，但方法的本质却是简单。面对纷繁复杂的万事万物，迎接不断出现的新情况新问题，说难也难，说易也易，关键看你能否把握事情的本质，复杂问题简单化是提高我们生活工作效率的正要途径，通过抽象思维把复杂问题简单化的例子有很多，比如：

曹冲称象

孙权送来了一头大象，曹操想要知道大象的重量，询问他的属下这件事，但他的手下都不能说出称象的办法。曹冲说：“先把象放到大船上，在水面所达到的地方做上记号，然后将大象牵下来，再让船装载其它东西，称一下这些东西，那么比较下就能知道了。

地铁线路图

即使不标出各个站点之间相隔的具体距离，也没有标出它们的具体位置，仅仅只是提取了必需的信息，就能将整个复杂的地铁体系简单地表现出来。我们只要有地铁路线图，就可以知道要怎样去各个站。

系统交接

再举一个最近发生在身边的例子，前​几天的一个系统交接会上，交接过程中总感觉有些遗漏，基于我自己记忆中的知识，我判断交接清单至少包含如下几个内容：

1. 1. 系统架构图、核心领域模型
   2. 核心业务流程、时序
   3. 上下游系统依赖、核心联系人、协议方式
   4. 中间件基础资源依赖、基本账号
   5. 系统操作页面、入口
   6. 以往大促保障手册、应急预案、资损盘点
   7. 系统基础监控、业务监控地址
   8. 遗留线上 Bug 清单和 Owner 分配
   9. 代码权限以及核心 L0 入口

其实上面都是基于对一个系统本来该有的内容的一个抽象，所有的业务系统都具有相同的特征，日常的抽象积累可以让工作更轻松更简单，不至于束手无策、手忙脚乱，抽象思维让我们只关注了要素隐藏了很多细节，按照上面这 9 个大类要素深入进去，我们面对的就是无穷的细节，细节是决定成败的关键。

分层思维

除了抽象，分层也是我们应对和管理复杂性的基本思维武器。日常生活中的一些分层的例子，比如我们经常所去的大商超，店铺的分布也是有分层的思维，比如负一层一般是小吃档口/停车场，一层一般是化妆品/香水/黄金首饰店铺，二楼是女装、三楼是男装、四楼是儿童/母婴用品，在往上就是餐厅和电影院、健身房等，通过分层思维，商超将一些共性的东西划分到一起，让管理和客户消费更轻松（如一般晚上只有电影院的那层关门最晚，其他楼层相对较早，管理上可以重点保障该楼层的用电和安保。)，类似用到分层思想的东西非常多，比如新华字典收录了 8000 字，通过按照汉语拼音的顺序完成所有汉字的分层，同时提供一个目录用于快速检索。这样一个复杂的问题就简单化了。在系统架构和设计中，分层思维也是常用的一个思维方式，比如：

（TCP/IP协议栈的分层架构) （操作系统分层架构）

在我负责的系统架构设计上，分层思维也是比较常用的一个思维方式，比如：

业务能力管理[业务逻辑的分层管理]

如上图，业务需求管理上我们采用三层架构的方式来进行业务管理，其本质是采用分层的思想，划分成三层，基础层、行业层、商家层，每一次有不同的定位和职责。

a. 基础层

主要沉淀业务的共性和一些基础标准和规范定义，并提供一些默认实现。

b. 行业层

主要沉淀业务的特性的内容，在基础层的基础上叠加一些特性内容形成具体的行业，不同行业之间也是一个分层思维，通过不同的行业分层管理行业间的差异。

c. 商家层

主要沉淀业务的个性的内容，在行业层的基础上叠加一些个性内容形成具体的业务身份，不同业务身份之间也是一个分层思维，通过不同的业务身份来管理他们之间的差异。

系统架构设计[系统模块的分层设计]

比如在数据中心的系统架构设计上，划分不同层次、不同的层次职责边界清晰。

通过分层的思维设计，每一层有自己的基本定位和职责边界，逐级往上提供基础能力。

a. 数据基础层

主要解决多数据源快速接入，数据快速形成一个宽表，核心面临的挑战是数据的质量和稳定性这方面，因为数据实时性的提高必然带来一致性的挑战，对上层提供基础数据支撑。

b. 数据服务层

主要解决业务数据的快速服务化的问题，沉淀数据开发平台来支撑，配套的服务测试、发布审批流程以及支撑多数据源接入，对上层提供数据资产服务。

c. 数据视图层

主要解决数据资产服务的权限管理问题，控制了什么人能看到什么资源以及看到哪些数据范围，对上层开放，支持 appkey 的多资源订阅。

d. 数据 APP 层

主要解决数据开放管理的问题，通过 appkey 来订阅，目前已经支撑异常中心、小时达实时指挥中心、算法等众多消费场景。

通过这四层架构分层设计，实现了数据来源于业务又回归到业务这一过程。

我们在运用分层思维的时候也离不开抽象能力，利用抽象能力去提取他们的共性忽略差异细节。

归纳思维

很多时候，我们习惯了碰到问题，都希望能快速的解决，而快速解决的方法很多只能是做表面工作，从表面解决，从表面上下功夫，头痛医头脚痛医脚，不追究发病的病根，看似很快，实则隐患不少，待问题再出现的时候代价会更大，其实最快的解决问题是从根本上解决问题，虽然这样前期不能最快解决问题，投入的精力也会很多，但是投入的成本低，在没有形成顽疾的时候，提前介入，一劳永逸。

“物有本末，事有始终，知所先后，则近道矣。”，当我们了解了一件事情的来龙去脉，掌握了事情的本末结构 就基本探究到了事情的本来面貌，归纳思维让我们可以从一个个具体的事例中，推导出它们的一般规律和共通结论的思维。帮助我们寻找问题的根因，从而对症下药解决问题。归纳思维的方法有很多在此不做讨论，生活中运用到归纳思维的例子有很多。天空乌云密布，燕子低飞，蚂蚁搬家等现象时，我们会得推断说天要下雨了。还有很多比如立冬晴一冬凌，立冬阴一冬温等等。归纳思维应用于工作中，可以帮助我们通过个别问题归纳推演出一类问题的共性和规律，采取合理的方案解决问题，举几个身边的例子：

开发人员运维投入成本的问题

部门成立初期由于业务上的变化较大，为了支撑业务，底层数据模型的做了一次升级，新增了部分数据模型，兄弟团队或者业务运营同学经常会丢一个单子过来让开发同学人工帮忙查单据状态、物流进度、单据关系等，这个造成了值班的开发同学编码时间经常被打断，效率下降，所以我们归纳推演了下分析问题的本质是【运维工具上的缺失】，基于此问题根因孵化了<火尖枪>和<乾坤圈>，降低了开发同学的运维投入的问题。

火尖枪

根据任意单号快速查询全链路数据的工具，实现从交易场到物流场全链路数据一键查询。

乾坤圈

通过单据的生命周期和单据之间的关系管理沉淀了"AAR"模型，实现任意单号/关键字全链路日志搜索并按照实际发生时间链式展示。

业务快速分析的问题

为了更好的支撑业务接得快、改的少、让系统更加高可用，FY22 财年针对目前系统架构做了一次升级，本次升级和以往不同的是：技术和业务支撑同步进行且有人员资源上的问题，抽调了一部分负责数据和异常较多的同学来参加架构升级，所以一个问题就出现了：对线上业务的了解和差异分析。这个了解不单独是知道业务是什么，要知道线上的业务所有细节，包括这个业务下的一个开关在做什么。这个对于当时参加的同学和架构来言都是一个很大的挑战。通过归纳总结，我们把一些好的案例规整以后产生出了一个业务梳理大纲，按照这个大纲去梳理业务，同时持续完善这个大纲。让所有同学都可以先有一个大的视角来看，忽略一些细枝末节。梳理的业务大纲如下：

1.通用资料库

2.作业模版分析

3.业务身份分析

4.实操节点(仓、运、配等)接入方式分析

5.调度协同分析

6.售中逆向分析

7.售后逆向分析

8.财务/库存分析

9.核心业务流程分析

10.数据库关键字段分析

11.广播消息汇总

12.业务分析汇总

13.线上示例单据&消息整理

14.关键报文

15.单据属性对比

16.领域消息对比

17.架构升级新增测试点

18.特别测试场景提醒

19.自测案例

持续的归纳总结，不仅是让工作做的更好更轻松，更多的是对自己不断产生出滚雪球的收益，所以从这个需求/这个问题排查开始，多问几个为什么。

结构化思维

先来看下下面这些数字，然后在 10 秒内说出所有数字和字母：

2, 4, f, 8, n, 4, 2, 3, 7, d, b, a, h, e, k, m, i, 3, g, j, 9, 6, 5, 1, 1, 0, c, l

面对这样一堆没有任何规律的数字，如果要记下来是不是有点难？如果我们把这些数字的内容调整下，变成下面这样：

0, 1, 1, 2, 2, 3, 3, 4, 4, 5, 6, 7, 8, 9, a, b, c, d, e, f, g, h, i, j, k, l, m, n

是不是清晰了很多？

其实这涉及到了结构化思维：当人接收到大量杂乱信息时，处理复杂信息的能力有限，但是更偏爱有规律的东西。我们每天工作生活中都会接收到大量信息，如何把这些信息吸收并结构化为我所用就需要构建自己的知识树。比如上面的业务梳理大纲的例子，其实我们就构建了一个自己的知识树，通过它我们可以检索我们需要的信息，好的知识树可以借鉴，但是每个人都有自己的一个思维方式，如果没有内化成自己的或者不是自己构建的知识树无法熟练的使用。

结构化思维指从整体思考到局部，是一种层级分明的思考模式。简单来说就是借用一些思维框架来辅助思考，将碎片化的信息进行系统化的思考和处理，从而扩大思维的层次，更全面地思考。没有结构化的思维是零散混乱无条理的想法集合，而结构化思维是一个有条理有层次，脉络清晰的思考路径，让这些点连成了线，举一个常用的问题解决方法思维框架：

按照这个思维框架，很多问题的解决都可以用的上，比如上面举过的一个数据中心的例子，应用这个思维框架后，基本思维路径如下：

总结

一线技术人每天面临的都是写需求、改缺陷、查工单，加班，长此以往。有时候不妨跳出来以一个旁观者的身份看一看自己，做一个需求前多问几个为什么？写一段代码前先理一下逻辑思路，需求发布以后想一下怎么运维(最好的是让没做过这个需求的人也知道怎么处理工单，打破知识壁垒和人员壁垒)，在这个域沉淀的东西如何复用到另外一个域。我们面临的业务是变化的但是做事的方法是有共性的，如何沉淀这些共性的做事方法才是做业务需求带来的最大成长。

低头走路，抬头看天，长路漫漫，不忘初心 -- 自勉