• 自动秒收录
  • 软件:1973
  • 资讯:56932|
  • 收录网站:211312|

IT精英团

大厂中的技术专家:建筑设计中的常见思维模式

大厂中的技术专家:建筑设计中的常见思维模式

浏览次数:
评论次数:
编辑: 泽洋
信息来源: ITPUB
更新日期: 2022-06-23 20:55:40
摘要

上周我写的一篇文章《关于技术能力的思考和总结》引起了大家的关注,好多读者的评论“以写代想、以想促真、以讲验真”,大家的感受很深刻,基于上次的文章,这篇文章我其实更想跟大家聊聊一些常用的思考方法,思考问

  • 正文开始
  • 相关阅读
  • 推荐作品

上周写了一篇文章《关于技术能力的思考和总结》,引起了大家的关注。很多读者评价“以文代思,以思促真,以言验真”,深有感触。基于上一篇文章,我其实想和大家谈谈一些常见的思维方法。正确的思考问题的方式往往能帮你少走弯路。

常用思考方法

技术的一般思维方法

技术思维的本质是结构化思维,所以常见的结构化思维方法也适用。这也是为什么很多技术架构师会使用一些方法论来分析问题的原因。但在这里我不打算再讨论这些常用技巧,而是分享一些从实际技术战斗中获得的思维方法。为此我把他们分为两类:技术架构设计的方法和技术负责人的思维方法。

技术架构思考方法

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的视角谈谈我在实践中的一些思考。
标签:架构 技术 问题
在线K8s群集性能评估 基本服务部署调整
« 上一篇 2022-06-23
  • 在线K8s群集性能评估 基本服务部署调整
    0阅读 0条评论 个赞
    对于非结构化的数据存储系统来说,LIST操作通常都是非常重量级的,不仅占用大量的磁盘IO、网络带宽和CPU,而且会影响同时间段的其他请求(尤其是响应延迟要求极高的选主请求),是集群稳定性的一……
  • 当字节跳动向美国出口中国996.
    0阅读 0条评论 个赞
    作者|GeorgiaWells/YoreeKoh/SalvadorRodriguez来源|WSJ在荣克离职时发布的一份内部备忘录中,他说,“TikTok对待员工的方式与TikTok平台代表的……
  • 在Kotlin开发者眼中 Java缺少哪些特性?
    2阅读 0条评论 个赞
    出品|OSC开源社区(ID:oschina2013)NicolasFränkel是一名资深程序员,拥有近二十年的Java开发经历。他在几年前开始学习Kotlin,在此之后,每当他再使用……
  • 老工程师总结的10条经验 太有益了~
    1阅读 0条评论 个赞
    正文到现在,我已经做了超过21年开发,可以说,我生命中超过一半的时间都在编程,那既是我的职业,也成了我的习惯。下面是我在开发过程中学到的10条最有价值的经验。1你永远不可能什么都知道尤其是在开……
  • Git指令的本质真的很好理解
    0阅读 0条评论 个赞
    前言作为当前世界上最强大的代码管理工具Git相信大家都很熟悉,但据我所知有很大一批人停留在clone、commit、pull、push...的阶段,是不是对rebase心里没底只敢用merge?碰见版……
发表评论 共有条评论
用户名: 密码:
验证码: 匿名发表
  • 记得保命!捕捉Linux下的所有高危命令!
    1阅读 0条评论 个赞
    1、rm-rf命令该命令可能导致不可恢复的系统崩坏。>rm-rf/#强制删除根目录下所有东西。>rm-rf*#强制删除当前目录的所有文件。>rm-rf.#强制删除当前……
  • 谈谈MySQL的10大经典错误
    0阅读 0条评论 个赞
    今天就给大家列举MySQL数据库中,最经典的十大错误案例,并附有处理问题的解决思路和方法,希望能给刚入行,或数据库爱好者一些帮助,今后再遇到任何报错,我们都可以很淡定地去处理。学习任何一门技术的同……
  • 在学校教授Python编程的理想IDE
    0阅读 0条评论 个赞
    在Linux中运行Python程序就像在终端中执行Python文件一样简单。但这对大多数人来说都不是很方便,也无助于调试程序。有多种IDE和文本编辑器可用于Python开发。PyC……
  • 浅谈几种常见的分布式入侵检测系统
    0阅读 0条评论 个赞
    在分布式环境下,如何对某对象做唯一标识是个很常规的问题。本文讨论几种常见做法,供大家参考。1.UUIDUUID是可以生成时间、空间上都独一无二的值,其本质是随机+规则组合而成的。即使在两个独立的服务……
  • 整顿00后职场?成立了“00后部门”
    0阅读 0条评论 个赞
    整理|于轩出品|程序人生(ID:coder_life)据教育部统计,2022届高校应届毕业生人数高达1076万。同时,今年也是00后的第一个毕业季。随着大批00后涌入职场,作为职场新人的他们会有……
  • 嵌入式系统登录的简单方法
    3阅读 0条评论 个赞
    来源|我姓梁很多场景都需要记录日志,在嵌入式系统中,特别是单片机这种存储资源有限的环境下,就需要一种轻量级的存储方法。系统日志在嵌入式设备应用场景中,系统日志时常可以监控设备软件的运行状态,及时记录……
  • 运维入坑必看:Kubernetes平台架构解读
    1阅读 0条评论 个赞
    Kubernetes是一个开源容器编排平台,管理大规模分布式容器化软件应用,是云计算发展演进的一次彻底革命性的突破。Kubernetes是谷歌的第三代容器管理系统,是Borg独特的控制器和Omega灵……
  • 前端质量|基于业务驱动的前端绩效有效实践案例
    1阅读 0条评论 个赞
    一、背景1.1.前端性能优化的业务意义前端的本质价值是什么?我认为是给用户创造良好的交互体验。前端性能对用户体验、对业务跳失率的影响,在业界已有共识,不言而喻。根据Google的数据,如果移动站点……
  • Arch Linux超越Ubuntu成功登顶
    10阅读 0条评论 个赞
    Steam5月调查结果发布啦,本月Linux平台的用户百分比基础略有下降,而且最受欢迎的Linux发行版从UbuntuLTS转向了ArchLinux。Steam5月份的调查结……
  • 如何通过缓存提高系统性能
    1阅读 0条评论 个赞
    缓存在系统中最消耗性能的地方就是对数据库的访问了,一般来说,增、删、改操作不会出现什么性能问题,除非索引太多,并且数据量有十分庞大的情况下,这三个操作才会导致性能问题。一般可以限制单表索引的数量来提升……
  • 夯实基本功 深刻理解TLB原则
    0阅读 0条评论 个赞
    今天分享一篇TLB的好文章,希望大家夯实基本功,让我们一起深入理解计算机系统。TLB是translationlookasidebuffer的简称。首先,我们知道MMU的作用是把虚拟地址转换成物理地……
  • 高考AI专业择校指南:清北自由选择 浙大仿真强 哈工大自然语言也不错
    2阅读 0条评论 个赞
    本文转载自|AI科技评论作者|王玥2022年高考在今天拉开帷幕,想必很多学生想选择发展如火如荼的AI专业,但不知如何择校。出于八卦好奇心,小编扒了多个评价指标,最终找到了一份专门针对人工智能进……
  • vivo集装箱集群监控系统的架构与实践
    0阅读 0条评论 个赞
    vivo互联网服务器团队-YuanPeng一、概述从容器技术的推广以及Kubernetes成为容器调度管理领域的事实标准开始,云原生的理念和技术架构体系逐渐在生产环境中得到了越来越广泛的应用实践。……
  • 收藏!四种异常检测方法综述
    0阅读 0条评论 个赞
    作者丨Ai,来源丨宅码编辑丨极市平台本文收集整理了公开网络上一些常见的异常检测方法(附资料来源和代码)。不足之处,还望批评指正。一、基于分布的方法1.3sigma基于正态分布,3sigma准则认为超……
  • 数据库主键一定要自己增加吗?有哪些不推荐自我增加的场景?
    0阅读 0条评论 个赞
    我们平时建表的时候,一般会像下面这样。CREATETABLE`user`(`id`intNOTNULLAUTO_INCREMENTCOMMENT'主键',`name`char(10)NOTNULLDE……
  • Java代码技巧将效率提高一千倍
    0阅读 0条评论 个赞
    前言代码优化,一个很重要的课题。可能有些人觉得没用,一些细小的地方有什么好修改的,改与不改对于代码的运行效率有什么影响呢?这个问题我是这么考虑的,就像大海里面的鲸鱼一样,它吃一条小虾米有用吗?没用,……
  • 使用终结器删除无论如何都无法删除的K8s资源
    1阅读 0条评论 个赞
    ❝本文转自weiliang的工作笔记,原文:https://weiliang-ms.github.io/wl-awesome/2.%E5%AE%B9%E5%99%A8/k8s/base/final……
  • 数据湖VS数据仓库之争?万紫详解数据仓库与湖湖数据仓库的集成
    0阅读 0条评论 个赞
    随着近几年数据湖概念的兴起,业界对于数据仓库和数据湖的对比甚至争论就一直不断。有人说数据湖是下一代大数据平台,各大云厂商也在纷纷的提出自己的数据湖解决方案,一些云数仓产品也增加了和数据湖联动的特性。但……
  • 20个实用的以打字打的文件单行代码汇总
    0阅读 0条评论 个赞
    来源|https://blog.bitsrc.io/another-10-quick-typescript-one-liners-9f41713c158a在今天的文章中,我将与你分享20有用的T……
  • 老工程师总结的10条经验 太有益了~
    1阅读 0条评论 个赞
    正文到现在,我已经做了超过21年开发,可以说,我生命中超过一半的时间都在编程,那既是我的职业,也成了我的习惯。下面是我在开发过程中学到的10条最有价值的经验。1你永远不可能什么都知道尤其是在开……
最近发布资讯
更多