上周写了一篇文章《关于技术能力的思考和总结》，引起了大家的关注。很多读者评价“以文代思，以思促真，以言验真”，深有感触。基于上一篇文章，我其实想和大家谈谈一些常见的思维方法。正确的思考问题的方式往往能帮你少走弯路。
常用思考方法
技术的一般思维方法
技术思维的本质是结构化思维，所以常见的结构化思维方法也适用。这也是为什么很多技术架构师会使用一些方法论来分析问题的原因。但在这里我不打算再讨论这些常用技巧，而是分享一些从实际技术战斗中获得的思维方法。为此我把他们分为两类：技术架构设计的方法和技术负责人的思维方法。
技术架构思考方法
0---1
这种思维方法的含义是：
当我们在一堆迷茫和困惑中不知如何从口中走出来的时候，首先要走近问题本身，还原客观事实，快速形成一个能拉起认知，快速讨论迭代优化的版本。大家围绕这样一个初始版本来叠加和丰富其他维度的内容，直到达成方案的共识。
让我给你一个真实的案例。当人们谈论一个平台能力升级的方案时，他们往往喜欢用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的视角谈谈我在实践中的一些思考。
509006974