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

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

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

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

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

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

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

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

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

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

2）地铁线路图

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

3）系统交接

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

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

TCP/IP协议栈的分层架构

操作系统分层架构

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

1）业务能力管理（业务逻辑的分层管理）

• 基础层

• 行业层

• 商家层

• 数据基础层

• 数据服务层

• 数据视图层

• 数据APP层

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

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

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

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

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

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

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

先来看下下面这些数字，然后再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

是不是清晰了很多？

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

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

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

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