文章转自：https://7player.cn/2020/07/27/20200727/
村上春树在《当我谈跑步时，我谈些什么》的开篇提到毛姆说的一句名言：
任何一把剃刀都自有其哲学。
意思是说：再微小的事物，都自有其规律。
随着在互联网领域工作越做越久，对产品和技术的思考愈加深入，我越来越能体会到思维方式和学习方法的重要之处。就像底层操作系统或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理论
有哪些技术方案， 方案的优缺点是否又引入新的问题？
新的问题又如何解决？
……
这个问题也可以反过来梳理。
这样分析问题，原来看似零散的的知识和道理，被统一安排，来去有据，形成“结构化”的知识。
关于如何学习，如何认识本质，这类问题研究越深，归根结底就是哲学领域的问题了。当然，在我们实际工作中，不需要研究的那么深奥。说了这么多就是在提醒自己，我们在最初面临问题时，通常会直接作出本能反应，可能会有不正确的认知，需要从自我的思维跳出来，旁观的思考问题、事物，分析本质，寻找规律。
最后总结一下吧，正如哲学上有句话：认识认识再认识，思考思考再思考，学习学习再学习。注意这三句话里的每句是“名词，动词，名词”的结构，即认识“认识”本身，思考“思考”本身，学习“学习”本身。
推荐一些在思维，洞察力，理解，架构方面的好书：
《技术的本质》
《好好学习》
《系统之美》
《穷查理宝典》
《思考，快与慢》