当我谈架构时,我谈些什么

村上春树在《当我谈跑步时,我谈些什么》的开篇提到毛姆说的一句名言:

任何一把剃刀都自有其哲学。

意思是说:再微小的事物,都自有其规律。

随着在互联网领域工作越做越久,对产品和技术的思考愈加深入,我越来越能体会到思维方式和学习方法的重要之处。就像底层操作系统或CPU,这些能力越发达,越能处理复杂任务,速度也更快。

世面上撰写架构师技能和架构技术的书有很多,但很少有人去讲架构师的底层思维能力——这和很多关于产品经理的书不太一样,众所周知,我是一名想做产品经理的程序员,所以有事没事也看了不少产品经理的书。有了一定阅读量之后,发现讲产品的书都在强调“思维能力”,有时也叫“产品思维”。从产品思维延伸出来的还有:思考技能,认知方法,科学观念等。具体点的就是“如何认知用户”、“如何认知需求”等,然后才是各种具体的方法和技能。

而反观技术开发这块,我们似乎不太会关心这种“技能”,也很少听说或见到直接声明对程序员需要“认知能力”的要求。我们可能更关心类似“数据库的实现原理、异步的设计模式以及消息中间件的原理与应用”等更实际的问题。更务实的人可能更关心学习一门技术是否能找更好的工作,成为架构师是否意味着升职加薪。这里不是要批判“务实精神”,相反,实事求是是我特别认可的原则之一。

这里我想强调的是,技术人员在往更高层面发展时,是需要能够做到深度思考的。比如成为架构师,除了需要掌握必备的技术栈之外,同时也要培养洞察能力和架构能力。好的思维方式,可以帮我们快速抓住重点,抓住问题的本质,找到更好的解决思路。技术可以不断学习积累,但思维方式只能自己领悟,有时还要靠“顿悟”——需要修炼。

不同的人在面对同一问题,同一件事情时,会有不同的看法。比如对“架构师”这三个字来说,有的人认为它是一个职业,而事实上架构师代表的是一种能力。架构师更像专家,和经济学家,心理学家,社会学家类似,意味着掌握的是一种研究,思考,分析,解决问题的能力。

关于洞察力来看一个具体的例子:销售团队面临一个业绩下滑的问题。有A、B、C三名销售针对这个问题,分别有自己的看法:

A说:这个月团队走了几个得力干将,并且市场上出现了一个竞争对手。

B说:我觉得还是我们的产品设计太丑了,功能满足不了客户需求。

C说:咱们能不能先不聊业绩?能不能先明确一下怎么算下滑?目标业绩是多少?现在业绩是多少?激励机制能否激励到所有人?是资源分配不公平?

有没有发现这三个人观点的不同之处?或者说是什么让他们看待问题的角度有所不同?我们能感觉到C的回答明显不太一样:

    A和B都是在纠缠问题本身,像是在找借口。而C不仅没有回答问题,反而提出了新的问题。

不难想象,以A的观点,可能给出的解决方案是“再招几个销售”。而B给出的方案则可能是“需要重新设计UI”。而C虽然没有给出解决方案,但他的观点会引导大家开始着手分析问题并找到真正的原因。

正如爱因斯坦所说:“不能在制造问题的层次来解决问题”。在我看来,回答how的最佳方式,永远都是都是追问what和why。所谓洞察力就是追究“问题的本质”。具体到这个的例子里,不同的方案之间基本不存在信息差,只存在对本质问题的不同理解。

在工作中还会遇到另一种场景:有一个待解决的问题,有几个想要解决问题的人,经过几轮讨论拉锯之后,其中有一个人提出了明显更靠谱的解决方案。这个方案并不复杂,也不是什么新技术,但其他人的第一反应是:我怎么没有想到?

这个「我怎么没想到」究竟是如何发生的?或许这个人只是阐明了一些概念,也可能是他提出一个新的切入方向。但他为什么能精准的洞察问题?

这个答案并不高深,原因在于他的思维模型。不同的思维模型会有不同的看法,所以理解不同,然后行为和结果自然也不同。比如他是这样看待“问题”本身的。

「问题」就是:期望与现状的落差部分。

假设某件事的期望值是(B),现状是(B’),那么(B’→ B)这个落差部分,就是问题。

拥有这种看待问题的思维模型,就会有一个清晰的分析问题的思路,所谓的解决问题的办法,就是围绕(B’→ B)的这个部分来展开思考就可以了。具体的一些方法论如SMART原则,三棱镜分析法就是针对“如何定义问题”,“如何解决问题”的,这里就不展开了。

回到架构问题上来:架构师和程序员最大的差别是什么?是谁掌握的技术种类更多,还是看谁的工作经验更丰富?或者是系统架构设计能力更强,还是更会写 PPT, 忽悠老板?

很多牛逼的架构师并没有精通所有技术(技术是基础,是充要条件),由于技术一直迭代更新,很多架构师的技术不再与时俱进,在技术精通上更比不了一线的程序员。但这并不妨碍他依然是一名优秀的架构师。

这里先给出答案:

程序员——处理问题的能力 

架构师——发现问题的能力

我在当初学习架构时,和大部分同学一样,直接买本《分布式服务架构》、《人人都是架构师》一类的书来看,直接扑到技术细节上。一段时间学习之后,却产生了更多困惑:掌握了各种技术,为什么依然没有自信自称“架构师”。

后来,我发现我只是掌握了很多应用方法,学到的知识都是单独解决特定问题的。我所了解的架构知识点是零散的,没有形成网络,于是解决完一个问题后,很容易忘记,再碰到类似的问题,又得再翻一次书。我花费了太多时间在“技术效率”上。其结果就是——为什么看起来很努力,却始终收效甚微。

拓展一下:“技术效率”这词是在成甲的《好好学习》里提到的。与其对应的还有一个词叫“认知效率”,书中是这样解释的:

技术效率:不断掌握应对具体场景和问题的方法(遇到新问题就要学习新知识) 

认知效率:了解问题本质,了解解决方案的底层规律,认清楚问题表现背后的实质

在认识效率下,很多看似全新的问题,只不过是重新装扮再次出现而已。

这就是为什么有人总能透过现象看到事物的本质——解决问题必须站在更高一个思维层次上,回顾和思考问题是如何产生的,根源是什么,核心点在哪里,我应该如何根据问题产生的根源去解决问题。

比如天天都在说要有架构,但当我们思考“架构的目的”时,经常有这样一些错误的观点:

    [x] 因为架构很重要,所以要做架构设计

    [x] 不是每个系统都要做架构设计吗

    [x] 公司流程要求系统开发过程中必须有架构设计

    [x] 为了高性能、高可用、可扩展,所以要做架构设计

持有这类观点的架构师和设计师会给项目带来巨大的灾难。因为这类架构师或者设计师不管三七二十一,不管什么系统,也不管什么业务,上来就要求“高性能、高可用、高扩展”,结果就会出现架构设计复杂无比,项目落地遥遥无期,团队天天吵翻天……等各种让人抓狂的现象,费尽九牛二虎之力将系统整上线,却发现运行不够稳定,经常出问题,出了问题很难解决,加个功能要改 1 个月……等各种继续让人抓狂的事件(这段描述摘自《从零开始学架构——架构设计的目的》)

没有发现问题的本质,只能事倍功半,还有可能带来无法挽回的影响。

如果你先搞清楚了架构不过是为了解决某些(复杂度)问题时,而进行的技术选择”这一本质问题时,不管问题有多少,思路都是清晰的,不会迷失在架构迷宫里。

现在我们理解架构思路就不是各种技术名词,而是这个样子了:

架构是什么?——一种顶层设计

    目的是什么?——解决复杂性

        那么复杂性问题的来源有哪些?——高可用(还有高性能)

            哪些方面需要考虑高可用?——存储是一个方面(还有计算高可用)

                那有哪些解决方案或原理?——备份(本质上都是通过服务与数据“冗余”来实现高可用)

                    冗余又会带来哪些问题?——  数据不一致

                        如何解决?——CAP理论

                            有哪些技术方案, 方案的优缺点是否又引入新的问题?

                                新的问题又如何解决?

                                 ……

这个问题也可以反过来梳理。

这样分析问题,原来看似零散的的知识和道理,被统一安排,来去有据,形成“结构化”的知识。

关于如何学习,如何认识本质,这类问题研究越深,归根结底就是哲学领域的问题了。当然,在我们实际工作中,不需要研究的那么深奥。说了这么多就是在提醒自己,我们在最初面临问题时,通常会直接作出本能反应,可能会有不正确的认知,需要从自我的思维跳出来,旁观的思考问题、事物,分析本质,寻找规律。

最后总结一下吧,正如哲学上有句话:认识认识再认识,思考思考再思考,学习学习再学习。注意这三句话里的每句是“名词,动词,名词”的结构,即认识“认识”本身,思考“思考”本身,学习“学习”本身。  



推荐一些在思维,洞察力,理解,架构方面的好书:

《技术的本质》

《好好学习》

《系统之美》

《穷查理宝典》

《思考,快与慢》

 

分享到:

发表评论

昵称

难的是和自己保持联系~