共计 5665 个字符，预计需要花费 15 分钟才能阅读完成。
简介：上周我写的一篇文章《对于技术能力的思考和总结》引起了大家的关注，好多读者的评论“以写代想、以想促真、以讲验真”，大家的感触很粗浅，基于上次的文章，这篇文章我其实更想跟大家聊聊一些罕用的思考办法，思考问题的形式对了，往往能够帮忙大家少走弯路。
作者 | 朱春茂（知明）
起源 | 阿里开发者公众号
上周我写的一篇文章《对于技术能力的思考和总结》引起了大家的关注，好多读者的评论“以写代想、以想促真、以讲验真”，大家的感触很粗浅，基于上次的文章，这篇文章我其实更想跟大家聊聊一些罕用的思考办法，思考问题的形式对了，往往能够帮忙大家少走弯路。
罕用思考办法
技术罕用思考办法
技术思考实质还是结构化思考，所以常见的结构化思考办法也是实用的。这也是大家会看到很多技术架构师都会用一些方法论去剖析问题的起因。但这里我不是从新去阐述这些常见的技巧，而是分享从技术实战中失去的一些思考办法，为此我分为了技术架构设计的办法和技术 Leader 的思考办法两类。
技术架构思考办法
0—>1
这个思考办法的含意是：
当咱们在一堆迷茫和凌乱中不晓得如何下口时，应该先贴近问题自身，还原客观事实，并疾速造成 1 个可能拉起认知并疾速探讨迭代优化的版本。大家围绕着这样的一个初始版本去叠加和丰盛其余维度的内容，直到计划的共识。
我举一个理论的 CASE，大家在谈某平台能力降级的计划时候会常常喜爱用 PPT 画一些模块图，试图通过一些形象的词汇来厘定分明边界，外围概念。大家认为是在讲实质讲准则但理论所有人听了都是云里雾里，不知所云。因为通过概念去推导概念是无奈真正答复问题的。
而比拟好的应答办法我总结为以下三个步骤：
- 【用户视角的主观世界还原】
用户故事的串联，基于交互流程和实在的数据来描述这件事在主观世界中用户视角看来是怎么产生的。这就是咱们找准一个大家都可能共识的视角，让所有人疾速把客观事实搞清楚画进去这个 1，而这个 1 就是后续探讨的靶子。这个 1 的表现形式我认为往往都是很简略的，要么是交互时序图，要么是 Excel 表格，而不是简单的模块概念图。
- 【主观信息的结构化整合与提炼】
只是建立起来 1 这个初始版本，还远远不够。因为第一个步骤只是将含糊、凌乱的货色通过一种办法信息化表达出来，这还远远达不到应用的水平。所以还须要将上述信息进行结构化的整合与提炼，因为信息只有通过结构化才可能变成有意义的常识，才可能与之前的教训造成互动，也才可能进行初版的设计加工。比方对数据流的解决，就会发现有哪些是能够合并的同类项，有哪些均衡校验逻辑等。
- 【退出多元视角的测验与形象】
通过第二步的解决把 1 这个版本变得更加饱满，然而要造成残缺的可实施方案还远远不够。咱们还须要退出更多维度的校验和形象，比方进一步形象以看透其本质，比方退出重要异样，ROI，合理性等扩展性等多方的视角去做校验。
所以大家当前在遇到很多计划谈不分明的时候，不要去听他人讲什么准则，概念，价值等等虚头巴脑的货色。把大家拉回来，回到最简略的最奢侈的货色来对焦，那就是 一张交互序列图 或者 一张表格。越疾速从一堆迷茫中疾速提炼出这个 1，就越容易疾速拿到后果。
1—>0
这个思考办法的含意是：
当咱们在做一个计划时面对有数因素无奈抓住关键点时，咱们应该思考删除法（把这个 1 拿掉不要行不行）去寻找决定性因素，以确保咱们是真正的抓到了关键点。
我举一个理论的 CASE，每年都会做技术布局，置信这是很多架构师 /Leader 很苦楚的事。苦楚的本源就是在脑子外面有有数需要，有有数的待优化点，也有有数的想法在萦绕，看到每个点感觉值得在新一年做攻坚。最终多半造成的就是一个表格，把往年要做的事列举下，最多还排个优先级，好一点的换个模式变成 xmind 或者 PPT，再略微好一点的可能会搭配上业务的指标和策略打法。但透过这些表面现象，其本质就是一个表格，没有抓住重点的表格。置信大家应该都看得蛮多的了。
如何应答这类问题我总结为以下几个技巧：
- 【因果判断法】
很多时候咱们都在谈，要抓住事件的实质，要具备化繁为简的能力，其实就是在谈通过外表的后果去探索实在的起因。所以在看哪些是决定性因素时，大家无妨用因果法去测验：这个因素到底是深层次起因还是诱导的后果。
- 【树干树枝法】
有时候各个因素之间并不是单纯的因果关系，而是附丽关系，就像是树枝附丽在树干上一样。而咱们要找到决定性因素，能够尝试这个办法去测验：如果把这个因素去掉会不会影响全局，是不是导致论断不成立。通过这样多轮的剖析，是能够绘制进去树干的与树枝的关系，这个树干就是要找的决定性因素。
- 【支点撬动法】
有时候各个因素之间可能没有间接或者间接关系，或者这个关联关系太弱很难通过以上两个伎俩去确定关键点。能够尝试支点撬动的方法，即寻找能够激发这一堆因素的要害因素。我之前给团队举一个例子，国家抓经济必定不可能是米面粮油各种琐碎地抓，必定是找到几个关键点起到支点撬动的作用，如房地产行业。抓住这个就可能带动上下游产业，进而激发各行各业。
以上是目前实际下来的抓取关键点的一些办法。但这里肯定也要留神一个粒度问题，千万不要走极端。比方一提关键点，就去思考实质，一提到实质就去找根因，一找根因就挖到兽性，而后得进去就是兽性的原罪问题。这种都是没有任何养分的做法，也不利于事件的推动解决。
1—>2
这个思考办法的含意是：
当咱们思考一些形象问题 / 计划时候，须要对问题进行拆分（一分为二），通过分而治之的办法来确定每个小问题的边界，通过对小问题的解决来升高全局的思考难度，以尽快造成解决方案。
这个应该不须要举例子了，大家日常都应该有所接触，这里只是列举几个比拟典型的技术架构动作：
- 【纵深拆解】
拆解是十分好的一个将问题分而治之的方法，但要留神的是要做有机的拆解而不是物理的合成。比拟典型的案例就是对于故障指标这个课题的解决，我是见过有团队层层合成，把故障指标合成到每个同学身上，这是极其谬误的做法，也不可能失去想要的后果。咱们应该是要做拆解，就是把要守住故障指标这个后果拆解成哪几类要害动作，进而要求团队要害动作做到位，而不是强行合成指标。
- 【横向解剖】
做过理论研发的同学肯定遇到一些业务需要的探讨，很多时候来来回回扯不分明，而且常常会呈现产品说这是技术架构问题，技术架构说这是业务需要问题，业务方说这是产品设计问题的景象。要破解这个僵局就须要把这个问题进行解剖，一层一层解剖分明，把业务需要问题形容分明，把产品设计搞清楚，把技术计划搞清楚。每一层都面向上游屏蔽上游的细节，才有可能把问题定义得分明。一般来说，将这件事参加的角色进行解剖会更容易看得全面，更透彻。
以上是我实际对问题拆分的一些办法技巧，凡事多看几层终归是可能更加有结构性地认知事件本事，也越有利于问题的解决。
1—>N
这个思考办法的含意是：
当咱们思考一些技术计划时候，不要仅局限在过后当刻的条件束缚，要适当思考零碎的承载从 1 变到 N 的过程中的对系统架构带来的挑战。
做技术架构师的都晓得做架构要求有前瞻性，不能被业务拖着走。但很多时候咱们其实没有认真思考如何才可能做到前瞻性，我总结为最要害的思考的因素就是工夫，把工夫拉长来思考要害生产资料可能产生什么变动，通过去架构这种变动所得进去的计划就具备了前瞻性。个别意义上来说，咱们平台演进的生产资料抽象地演绎为三类：
- 业务场景：这是最原始的生存材料，更是平台演进的源能源。典型的如市场份额变动，用户体价值的变动，竞对动静等。
- 团队组织：是人发明了平台，也是主导平台的演进倒退，这个生产资料如果不能失去无效利用，充沛开释能动性就会呈现平台无奈反对业务疾速倒退，同时人也在平台中内卷。
- 技术架构：技术架构其实自身也是十分重要的生产资料，这是很多人会疏忽的中央。大家想一个最简略的例子，同一个变量扩散在多个中央导致语义不清，保护老本微小就明确了。
针对这几个生产资料我抽取了几个技巧去思考如何从 1 扩张到 N：
- 【架构思考所有可能性但做无限明确施行】
从业务场景的变动状况来看，确实充斥很多不确定性。也遇到过一种典型的业务与架构的死循环的状况：前端业务面临太多不确定性须要技术架构给予业余意见和评估，然而技术架构认为业务啥都想不分明还要我评估这评估那，两边就开始相互死锁。
而比拟好的做法就是架构可能基于本人的教训和业务变动的了解，将可能性进行列举思考，而后给进去基于 XX 业务假如下，零碎架构须要 XX 量级的工作量做 XX 样的能力迭代降级，能够做到 XX 的业务成果和价值，但须要进一步 XX 的业务输出。这就是架构思考所有的可能性的含意，是须要给予业务的抉择。
但技术架构施行却未必是要留有太多的空白，架构要大然而施行要小，对于值得留白的中央做好扩大设计，对于切实看不清楚的中央就要明确拦挡（宁愿不做也不错做），将可能性留足但也不瞎埋坑。
- 【没有靠谱的人只有靠谱的机器】
我经常去听一些故障复盘会议，在谈当前如何改良的时候很多同学都价值观爆棚，说当前 XX 类变更都加签上我来审核一道，我确认没问题再往后走。尽管这种精力值得激励然而这种做法切实是很不值得举荐，这样积淀进去的平台其实是十分软弱的，在做技术计划时肯定要思考可能交给零碎的相对不能用流程，可能做到畛域模型校验的千万不要靠旁路零碎的侧面印证（如不必要场景下的核查）。
- 【提前思考“幸福”的懊恼】
很多技术同学都心愿做高并发大流量的零碎，但很多时候在写代码的时候身材很诚恳，怎么简略怎么来。理论做的时候既不思考大流量也不思考高并发，对于资损危险思考也极其少，而且基本上都很有情理：当初的业务量没到不须要思考那么多，这种事产生概率极其小一期先这样 …… 要对技术架构做提前思考就必须从每行代码做起，提前思考高并发大流量和严谨性。
通常来说大家其实都比拟喜爱从 0 到 1 的过程，依照互联网的迭代式打法，前面的 1 到 N 的过程也会被一直压缩。所以提前在 0 到 1 的过程退出 1 到 N 的架构预判十分重要，因为很多时候结构性的问题在最开始就决定了，而且只有一次机会。
-1<—>1
这个思考办法的含意是：当咱们思考一些技术计划时候，不要一条道走到黑，要前后、高低、左右、正反多个方面去思考，让技术计划具备更多维的视角。
我把罕用的技巧总结如下：
- 【正反思考法】
日常也 review 了很多同学产出的架构计划和系分以及测分，大家对于失常业务需要性能的阐述基本上都没有啥大问题，循序渐进去写就能够。但广泛的问题都是对对问题的背面阐述不多，如领取失常流程浓墨重彩，退款 / 拒付等逆向流程就没那么粗疏，业务性能失常流转阐述很丰满然而异样场景就寥寥几笔。但侧面与背面联合起来才是残缺的一体，而且对背面的思考其实是对侧面的无益补充。而且通常来说，咱们在侧面呈现的概率大于背面，然而背面呈现过错的影响所须要付出的精力却远远大于侧面。
- 【极限思考法】
在 review 技术架构计划危险相干的内容时，我都会特意问一下，如果呈现 XX 问题最坏的业务影响是什么。为什么是问最坏的业务影响，是因为如果谈危险那必定都是有一点点的，不利于大家去深究最要害的问题。通过极限设问，其实是激发大家去做最坏的打算，有了最终极的兜底伎俩才可能更乐观去做技术变更。
- 【对称思考法】
在 review 代码或者逻辑构造时，在深挖细节和关键点后，我时常会拔出来看看整体的逻辑构造是不是丰满，是不是对称，是不是美。最简略的例子就是写了 if 我肯定要有 else，不然没对称构造就让我很不难受。因为我置信对称的美就是一种生产力，因为美的货色肯定是简洁且中转实质的。而咱们写程序要的就是逻辑清晰简略中转业务实质，逻辑构造清晰的基本上没大问题，不清晰（如变量瞎命名，办法无语义）的深挖上来多半都能发现大问题。本源就是逻辑清晰代码才清晰，代码不清晰基本上就是逻辑凌乱，逻辑凌乱就会产生 BUG。
M*N—>M+N
这个思考办法的含意是：当咱们思考技术问题时，能够尝试从零碎耦合的角度去思考，尝试找一些突破口。
我举一个理论的 CASE，高速公路网的连贯不是把所有目的地之间都修一条高速公路，而是会抉择建筑复用的高速公路主干道 + 分支路线的形式来组织这个网络。一条一条串联的形式就是耦合在一起的，这就是 M * N。通过主干道 + 分支路线的形式 就是解耦的，M + N 就可能组建这个高速网络。
在技术架构上如何使用解耦这个技法，我有如下几个提炼。
- 【解耦上下游关联性】
在业务和技术架构倒退的后期，把很多货色糅杂在一起是最快解决问题的办法。但随着业务和平台架构的进一步演进，势必是要做解耦，目标就是从新去界定各个模块的边界，均衡新的业务倒退要求下各方倒退快慢的诉求差别，通过解耦相互松绑疾速倒退。
这种技法在服务化的分布式架构中十分常见，基本上跨域的平台架构降级都有解耦的影子。
- 【解耦各个角色的依赖】
解耦上下游关联性其实更多是在技术模型的形象上，但在落入到技术模型领域之前，还有就是咱们在做更加形象的解决方案探讨时要留神解耦各个角色之间的依赖。上述【架构思考所有可能性但做无限明确施行】中提及的就是最好的案例。其实这里的实质表白就是，技术架构的设计应该要与商业抉择，产品设计等解耦开来。
通过这一层的解耦其实可能多个角色之间基于 SLA 去交互，并且可能基于本身的业余思考给予对方更多的选项和可能性。很多时候的前瞻性和竞争力可能就是比他人多一个抉择。
解耦思考法其实很有意思，简直所有的大型平台架构降级都有这个思考法的影子，所以下次没啥思路的时候能够从这个角度做一个扫视思考，说不定是有新的播种。
总结
以上是我在做技术架构计划时积淀总结的一些思考办法，这些思考办法不可能解决遇到的所有理论问题，只能算是一个思考提醒，在遇到问题能够尝试从这几个办法去看看是否有灵感。基于方法论然而不局限于方法论才是方法论最大的意义和价值。接下来一篇文章，我会从技术 Leader 的视角谈谈我在实践中的一些思考。
作者：知明，蚂蚁金服国内事业群资深技术专家，寰球资金平台技术负责人，负责了蚂蚁全球化过程中底层资金清结算、外汇等平台能力的搭建和迭代演进。
原文链接
本文为阿里云原创内容，未经容许不得转载。
