常用的思维方法技术思维方法技术思维的本质还是结构化思维，所以通用的结构化思维方法也是适用的。这就是为什么你会看到很多技术架构师使用一些方法论来分析问题的原因。但这里我不打算对这些常用技巧进行重新讨论，而是分享一些从技术实战中得到的思维方法。为此，我把它们分为两种：技术架构设计的方法和技术领导者的思维方法。技术架构思维方法0--->1这种思维方法的含义是：当我们在一堆乱七八糟的事情中不知如何开口时，首先应该贴近问题本身，还原客观事实，快速形成认知并快速讨论迭代优化的版本。大家围绕着这样一个初始版本去叠加和丰富其他维度的内容，直到达成方案的共识。我给你一个真实的案例。人们在谈论平台能力升级计划时，往往喜欢用PPT画一些模块图，试图通过一些抽象的词汇来界定清晰的边界和核心概念。大家都以为是在讲本质和原理，其实大家都一头雾水，不知道该说什么。因为通过概念推导出概念并不能真正回答问题。而一个更好的应对方法我总结为以下三个步骤：【从用户的角度还原客观世界】用户故事系列，基于交互过程和真实数据，从用户的角度描述这个事件是如何在客观中发生的的世界。这就是为什么我们要找一个大家都能认同的角度，让大家很快的摸清客观事实，把这个1画出来，而这个1就是后续讨论的对象。我觉得这个1的形式往往很简单，要么是交互式时序图，要么是Excel表格，而不是复杂的模块概念图。【客观信息的结构化整合与提炼】仅仅建立1的初始版本是远远不够的。因为第一步只是将模糊、混乱的东西用信息化的方式表达出来，远远没有被使用。因此，需要对以上信息进行结构化的整合提炼，因为只有信息结构化后，才能成为有意义的知识，才能与之前的经验进行交互，才能进行初版的设计和加工。例如，通过处理数据流，你会发现哪些相同类型的项目可以合并，哪些余额检查逻辑到位等等。【通过添加多个视角进行检查和抽象】通过第二步的处理，版本1得到了丰富，但还远远不足以形成一个完整的可实施方案。我们还需要加入更多维度的验证和抽象，比如进一步抽象，看透它的本质，比如加入重要的异常、ROI、合理性等视角进行验证。所以以后遇到很多规划不清楚的时候，不要听别人讲原则、概念、价值观等等，把大家拉回来，关注最简单最简单的东西，那就是交互时序图或者是桌子。你越快从一堆混乱中快速提取出这个1，就越容易快速得到结果。这种思路的意思是：当我们在做计划的时候，面对无数的因素，抓不住重点的时候，就要考虑删减法（去掉这个1，不行），找到决定性的因素，保证我们真正抓住了关键点。举个实际案例吧，我每年都会做技术规划，相信这对很多架构师/Leader来说是一件很痛苦的事情。痛苦的根源在于脑海中有无数的需求，有无数的优化点，有无数的念头挥之不去。看到每一点，都觉得在新的一年值得有所突破。最后多半是形成了一个表格，把今年要做的事情罗列出来，顶多排个优先顺序。好点的可以换成xmind或者PPT，好点的可能和业务目标和策略相匹配。法律。但是通过这些表面现象，其实质就是一张表，一张没有抓住重点的表。相信大家应该见多了。如何处理这类问题我总结为以下几个技巧：【因果判断】很多时候我们讲的是把握事物的本质，具备把事物简单化的能力。事实上，我们正在谈论通过表面结果。探索真正的原因。所以在看哪些是决定性因素的时候，不妨用因果法来检验这个因素是深层次的原因还是诱发的结果。【树干树枝法】有时候各种因素之间并不是简单的因果关系，而是依附关系，就像树枝依附在树干上一样。而如果我们要找到决定性的因素，我们可以试试这个方法来测试：如果去掉这个因素，会不会影响全局，会不会得出无效的结论。通过这样多轮的分析，可以得出主干和分支的关系，而这个主干是找到的决定性因素。【支点杠杆法】有时各种因素之间可能没有直接或间接的关系，或者关系太弱，无法通过以上两种方法确定关键点。可以试试旋转的方法，也就是找到能够刺激这堆元素的关键元素。我之前给团队举过例子。国家抓经济绝不能是抓米面粮油的小事。它必须找到几个关键点来发挥关键作用，比如房地产行业。抓住这一点，就能带动上下游产业，进而带动各行各业。以上是目前实践中的一些抓取关键点的方法。但是这里也要注意一个粒度问题，不要走极端。比如一提到重点就想本质，一提到本质就找根源，一找到根源就把人性挖出来，然后来到人性的原罪。这是没有任何营养的做法，也不利于推动事情的解决。这种思维方式的含义是：当我们思考一些抽象的问题/方案时，需要将问题拆分（一分为二），通过分而治之的方法确定每个小问题的边界，通过分而治之的方法来解决问题解决小问题。降低全局思维难度，尽快形成解决方案。应该没有必要举个例子。每个人都应该每天接触它。这里仅举几个典型的技术架构动作：【深度拆解】拆解是一个很好的分治问题的方法，但要注意是做有机拆解，而不是物理分解。一个典型的案例是故障指标问题的处理。我见过团队层层分解，把失败指标分解到每个学生。这是一种极其错误的做法，是不可能得到想要的结果的。我们应该做拆解，就是把保持失败指标的结果拆解成几个关键动作，然后要求团队把关键动作做到位，而不是强行拆解指标。【横向解剖】做过实际研发的同学肯定遇到过一些业务需求的讨论。很多时候，来回说不清楚，经常产品说这是技术架构问题，技术架构说这是业务需求问题。方先生说这是产品设计问题的现象。要打破这个僵局，需要层层剖析这个问题，把业务需求描述清楚，产品设计清晰，技术方案清晰。每一层都面向上游，屏蔽下游的细节，这样才可以把问题定义的很清楚。一般来说，解剖这件事情涉及的人物，会更容易看得全面、透彻。以上是我实践过的一些拆分问题的方法和技巧。毕竟凡事多看几层，能帮助你更有条理地理解事物，更有利于解决问题。这种思维方式的含义是：我们在思考一些技术方案时，不能只局限于当下的约束，还要适当考虑系统架构在改变容量的过程中带来的挑战。系统从1到N，做技术架构师的都知道架构需要前瞻性，不能被业务拖走。但很多时候，我们并没有仔细思考如何做到前瞻性。我的结论是，最关键的考虑因素是时间。延长时间考虑关键生产材料可能会发生什么变化，并通过对这种变化进行去架构化来获得。该计划具有前瞻性。一般来说，我们平台进化的生产资料可以抽象为三类：业务场景：这是最原始的生存手段，也是平台进化的动力源泉。典型的例子包括市场份额的变化、用户体验价值的变化、竞争动态等。团队组织：是人创造了平台，也引领了平台的演进。如果生产资料不能得到有效利用，平台就无法支撑业务的快速发展，人也会被平台牵扯进来。技术架构：技术架构本身也是一种非常重要的生产手段，这是很多人忽略的。让我们想想最简单的例子。同一个变量分散在多个地方，导致语义不明确，维护成本巨大。对于这些制作资料，我提炼出几个技巧来思考如何从1扩展到N：【架构考虑了所有的可能性，但做了有限而清晰的实现】从业务场景的变化来看，确实充满了很多不确定性。我也遇到过典型的业务和架构死循环的情况：前端业务面临太多不确定性，需要技术架构的专业建议和评估，但技术架构认为业务想不清楚，所以我需要评估这个评估然后，双方开始僵持。更好的做法是，架构可以根据自己的经验和对业务变化的理解，列出并考虑各种可能性，然后基于XX业务假设给它系统架构需要XX级别的工作负载做XX类的迭代升级的能力，可以实现XX业务效果和价值，但还需要进一步的XX业务投入。这就是架构中考虑所有可能性的意思，是需要交给业务的选择。但是，技术架构的实现并不一定要留太多的空白。架构应该很大，但实现应该很小。对值得留白的地方做好延展设计，对真正不清楚的地方明确截取（宁愿不做也好），留下足够的可能性但不盲目埋坑。【没有靠谱的人，只有靠谱的机器】我经常去参加一些故障检讨会。在谈及以后如何提高时，不少同学都充满了价值观。他们说以后所有的XX改动都要签字，我来审核。确认没有问题再回去。这种精神虽然值得鼓励，但这种做法实在不值得提倡。这样沉淀下来的平台，其实是很脆弱的。在做技术方案的时候，一定要想好什么可以交给系统。不要依赖旁路系统的侧验证来进行模型验证（比如在不必要场景下的验证）。【提前想想“幸福”的烦恼】很多技术同学都希望搭建一个高并发大流量的系统，但是很多时候写代码的时候很老实，怎么写越简单越好。实际做的时候，既没有考虑大流量，也没有考虑高并发，很少考虑资金流失的风险，基本合理：目前业务量没那么大，没必要考虑那么多，而且这种事情发生的概率是极高的，先从第一阶段开始吧。。。提前思考技术架构，必须从每一行代码开始，提前考虑高并发、大流量和严谨性.一般来说，大家其实更喜欢从0到1的过程，按照网上的迭代打法，后面从1到N的过程也会被不断压缩。所以提前在0到1的过程中加入一个1到N的架构预测是非常重要的，因为很多架构问题都是一开始就决定的，只有一次机会。-1<--->1这种思维方式的意思是：我们在思考一些技术方案的时候，不应该一路黑到黑，而是应该前后、上下、左右思考对、正、反，让技术方案更具多维视角。我把常用的技巧总结如下：【正反思维法】我也是每天复习很多同学出的架构方案，系科成绩，考试成绩。讨论正常的业务需求和功能基本没有什么大问题。写吧。但共同的问题是，对这个问题的负面讨论并不多。比如正常的支付流程是丰富多彩的，而退款/拒收等逆向流程则没有那么详细。业务功能的正常流转充满了讨论，但只有少数异常场景。但正反结合是一个完整的整体，反面思考其实是对正面的有益补充。而且一般来说，我们出现在前面的概率比出现在尾部的概率要大，但是尾部的一个错误影响所需要的能量远比前面多。【极限思维法】在回顾技术架构方案的风险相关内容时，我会专门问如果出现XX问题，对业务影响最大的是什么。之所以问最坏的业务影响，是因为如果讲风险，肯定有一点点，不利于大家去深究最关键的问题。通过极限提问，其实是在激励大家做最坏的打算。只有有了最终的底线，我们才能更加乐观地进行技术变革。【对称思维法】在review代码或者逻辑结构的时候，在深入到细节和关键点之后，经常会拉出来看整体的逻辑结构是否完整、对称、美观。最简单的例子就是写一个if，我必须有一个else，否则没有对称的结构让我很不舒服。因为我认为对称美是一种生产力，因为美的东西一定要简洁直达本质。我们要写的程序是直达业务本质的清晰简单的逻辑。如果逻辑结构清晰，基本没有大问题。如果不明确（比如没有语义的盲目命名变量和方法），大部分大问题都可以在深入挖掘后发现。根本原因是逻辑清晰了代码就清晰了，代码不清晰基本上就是逻辑乱了，逻辑乱了就会导致BUG。M*N--->M+N的思维方式的意思是：我们在思考技术问题的时候，可以尝试从系统耦合的角度去思考，尝试寻找一些突破口。我举个真实案例吧。高速公路网的衔接不是在所有目的地之间建设一条高速公路，而是通过建设复用的高速公路主干道+支路来组织网络。一个接一个串联耦合在一起，这就是M*N。主路+支路的方式是解耦，M+N就可以组成这个高速网络。在技??术架构上如何使用解耦的技巧，我有以下细化。【解耦上下游关联】在业务和技术架构开发的初期，将很多东西混合在一起是解决问题最快的方法。但是随着业务和平台架构的进一步演进，做解耦是必然的。目的是重新定义各个模块的边界，在新的业务发展需求下平衡各方开发速度的差异，通过解耦快速发展。.这种技术在面向服务的分布式架构中非常普遍。跨领域的平台架构升级基本上都有解耦的影子。【解耦各个角色的依赖关系】解耦上下游关联其实更多的是技术模型的抽象，但是在落入技术模型的范畴之前，还有一点我们在讨论更抽象的解决方案时需要注意解耦角色之间的依赖关系。上面提到了最好的情况[架构考虑了所有的可能性，但做了有限而明确的实现]。其实这里的本质表达就是技术架构的设计要和业务选择、产品设计解耦。通过这一层解耦，多个角色实际上可以基于SLA进行交互，可以根据自己的专业思维给予彼此更多的选择和可能性。在很多情况下，前瞻性和竞争力可能是一种比其他选择更多的选择。解耦的思维方式其实很有意思。几乎所有的大型平台架构升级都有这种思维方式的影子，所以下次没有想法的时候，可以从这个角度做一个回顾和思考，说不定会有新的收获。总结以上是我在做技术架构方案时积累和总结的一些思维方法。这些思维方法并不能解决所有遇到的实际问题。看看你是否受到启发。基于方法论而不局限于方法论是方法论最大的意义和价值。
