大家好，我是人月聊IT，我准备从三个方面来回答这个问题。分别是编程思维，架构思维，IT从业人员如何提升逻辑思维能力。
在前面的文章里面有不少谈到通用性思维，分析和解决问题思维，SOA思想，面向对象思维等方面的文章。今天在知乎看到一个问题，既编程思维的本质究竟是什么？当看到这个问题的时候才发现其实我们确实很少去谈论真正的编程思维。
谈编程不可避免的要谈到编程语言，而编程语言之所以出现，其最终的目的仍然是提供一种抽象方法来解决现实中的问题，问题本身的复杂程度往往取决于抽象的种 类和质量。从汇编语言的出现解决了最初的抽象，而类似c或fortran语言出现则可以看做是对汇编语言的进一步抽象。这一步抽象的完成其实是很重要的一 个进步，既我们在解决问题的时候不再需要关系复杂的机器模型或机器码，而是可以更多的关注问题和解决方案本身。
在这个阶段，从编程本身来说最核心的还是算法和数据结构。这也是任何程序最重要的两个基本要素。既把问题域本身涉及到的数据映射到合适的数据结构，把通过 程序解决问题的过程映射为具体的算法逻辑。那么编程实际的难点在哪？不是算法本身或数据结构本身，而是当你拿到问题域的时候知道如何理解和分解问题，并将 其映射到最适合的算法或数据结构上。这个映射其实本身不是程序解决的问题，还是人脑在思维，程序本身仅仅是在实现自动化的过程。
那么程序在算法实现过程中最基本的是什么？我们看不同的程序片段可以看到的还是if/else，或者for/while，然后才是数据或数据类型定义。而 前者即写任何一个程序中最重要的控制逻辑。那么编程里难的实际上不是控制语句本身，而是在把问题域分解后知道如何理解判断逻辑，如何将问题域中重复的东西 抽象为循环，如何从问题域中抽象出数据结构。一个人编程能力本身的好坏，或者说编程思维能力，重点其实是体现在这种映射能力，也可以称这种映射能力为数学 建模能力。举个例子来说，如果一个问题你已经知道了可以映射到构建二叉树，然后通过遍历的方式来解决了，那么可以说然后一个掌握了语言语法的人都可以写出 程序来。那么实际编程思维或能力的强弱则在于前面谈到的映射和建模。
面向对象思想和面向对象编程语言的出现，可以说也是编程思维本身的第二次重大提升。既原有的编程语言可以看到我们关注更多的已经是抽象后的解决方案，而面 向对象的编程语言则首先关注的是通过对象和类，通过继承，通过接口定义等首先对现实世界进行很好的抽象描述，其次才是如何去解决问题。现实世界中所有的一 切都是对象，而面向对象语言中的类本身就是对现实世界中对象的很好的抽象。
对于面向对象的核心特征谈的比较多的是封装，继承和多态。这些可能比较偏技术词汇，那么再简单点来说面向对象编程思维其核心则是找到问题域中的对象，将其 抽象为类，识别类应该有的属性和方法特征，同时去理清类和类之间的关联和交互关系，将问题本身的解决过程映射到类和类之间的方法交互上。如果从这个意义上 来说，好像也不是很复杂，那么实际面向对象编程的难点实际在为了保持代码足够的健壮性，可维护性，可扩展性而做出的各种抽象，包括接口的提取和组合，控制 或逻辑类的增加等，这些本质已经转换到技术域类本身。
除了上面谈到的，再谈下其它的一些内容。编程里面有一个重要的思想即是复用，从最简单的函数，到模版库，类库，再到更上层的公共组件等，都在体现复用的思 想，而复用本身的目的则主要是提升开发效率，提升可维护性和代码的可读性等。复用可以理解为编程过程中的编程思想更加恰当。
编程的思想是自动化，不要简单的理解为编程语言能够帮助你解决建模和映射的难题，编程的自动化更多的还是体现在机器可以自动化的进行大量计算和运算，而这 个运算是通过我们的程序进行的。程序中体现的一个重点我更喜欢把它理解为循环，从抽象中去发现和发觉一种可自动化的循环，这种循环的处理正是程序的强项。 任何人都应该有这种自动化的编程思维，即懒人思维，重复的事情一定不要自己手工重复完成。
师需要架构思维，对于我们IT从业人员都需要逐步学习，实践和培养自己的架构思维能力。
1. 架构思维的核心逻辑要素
对于架构思维本身仍然是类似系统思维，结构化思维，编程思维等诸多思维模式的一个合集。由于架构的核心作用是在业务现实世界和抽象的IT实现之间建立起一道桥梁，因此架构思维核心思想仍然是业务驱动技术，技术最终为业务服务。
架构设计本身就是一个系统和全局的工作，需要通过架构设计来完成业务和技术，需求和实现，软件和硬件，静态和动态，成本和收益等多方面的平衡。
早在2017年我就专门写过一篇架构思维的文章，对架构思维的核心逻辑要素进行了总结。即分解，集成，动静分析，复用，分层，模式匹配，抽象，结构化，维度思考，迭代和系统思维。
分解是最基础的，架构的重点就是要对复杂问题进行分而治之，同时保证分解后的各个部分还能够高内聚，松耦合，最终又集成为一个完整的整体。分解核心是定义问题，因此架构首先仍然需要理解清楚需求。
集成是配合分解完成的动作，最终分解完成的各个组件或子系统，通过合适的接口设计，最终还能够集成为一个完整的整体，分解仅仅是加速开发和降低问题复杂度，如果分解后的内容无法集成在一起，那么分解就没有任何意义。
因此分解+集成可以理解为架构最核心的思考方式和方法。
动态+静态：这一直是我强调的重要思维模式，架构思考里面一定要注意这两者的结合，即涉及到流程，用例等动态分析内容，又涉及到数据，类等静态建模内容，而是两者要高度协作起来完成整个架构思考。
复用是另外一个重要的思维，也可以理解为SOA参考架构的核心思考模式，包括最近谈的最多的业务能力组件化，组件能力服务化，平台+应用，共享中心建设，共性能力下沉等都是谈的复用的概念。即使你架构设计一个小系统，你也需要将各个模块需要用的共性功能抽取为可复用的共性组件。
分层思维本身也是一种分解思维。分层相当重要，架构在设计中要考虑分层，而核心仍然是资源+服务+应用的三大层，分为这三层仍然是SOA参考架构的核心思想。对于平台+应用更多只是上面分层模式的一个变形。分层的目的是通过分层既理清了整个应用的构建过程，又保证了各层之间的独立设计和松耦合。
模式匹配可以讲是所有思维模式里面的一个重点，而架构设计中的模式匹配就是要将最终的业务域问题匹配到对应的技术实现上面。即根据业务需求来挑选最适合的技术，而不是用主流和最先进的技术去反推业务。
抽象是面向对象分析设计里面的一个关键，抽象也是架构思维里面的一个重点，这里面包括了两个层面的内容，一个是常说的归纳方法，即各种类似场景的实现见的太多了，自然就归纳了一个规则或方法出来供以后的设计用。但是抽象更加重要，即将非类似场景中的共性内容也总结出来，进一步抽象为类似的东西，以更加方便的适应变更和各种变化。
结构化思维是架构思维必须具备的，类似大家常说的MECE法则和金字塔原理等。但是结构体现在静态的逻辑结构和动态的流程结构，这些都是结构。内在组件分解的有层次，有逻辑是结构；组件行为运行有流程有顺序逻辑也是结构。
迭代思维是架构思考中需要考虑的另外一个内容，没有最优的架构，只有不断进化的架构，只有最适合的架构。因此架构本身也在随着业务需求的变化不断的进行迭代和演化，而不是追求用最新的技术一步到位。
系统思维更是强调对事物的研究不是单独的组件，而是要研究组件之间的关系和相互作用，如何构成一个完整的整体，如何保证整个系统的动态平衡和相互制约关系，如何去追求整体的最优化而不是单个目标的最优。
2. 从架构思维到大架构观的培养
今天接着上期和大家进一步聊一下从架构思维到大架构观的一个培养，你要成为架构师，大量的编码和设计的这个积累它是必须的，而且这种编码积累还不能是简单的重复，必须要有抽象和复用的各种思维，不断重构的设计意识。
你自己走的路多了，各种业务到实现的匹配方式验证的多了，各种大型项目的经历解决的复杂问题多了，你自然而然你就有了这种能力。
一个架构很多时候并不是说你创新和学习能力有多强，而是他们的实践经验积累和知识库足够强大。
见多才能够识广。
大量的模式匹配库，自己形成的经验库能够随时可以使用。而对于一般人你经常发出的感慨就是我怎么没有想到那里去，我怎么没有想到这个方法？这个原因就是你自己的知识经验库的积累太弱了。
知识经验库的积累很值钱，但是这个本身它是经过大量长期的实践换来的，投入的是大量的时间和金钱的成本，经验库的积累它一定是知识理论到实践，再到总结复盘，再到抽象，形成在你自己脑海里面的这个过程本身它就是循序渐进，反复迭代，并没有什么捷径可以走。
所以我今天谈大架构观，首先说的还是架构思维，对于架构思维就是上面谈到的分解、集成、抽象、复用、组合系统化等多方面的一个思维能力。
这些思维能力都相当重要，它的本质就是你看待和理解事物的一个方式，也就是我们如何看待和理解一个产品，那么最终这个产品的实现就是按照你理解和建模的方式进行开发和产出，所有的产品后期可能出现的问题，可能都是我们在理解和建模上面本身你就出现了问题。
所以架构首先解决的是产品内部的组件如何高效的协同，产品和外围的系统间如何高效的协同，并满足业务和用户需求的问题。
这个就是我们常说的基本的功能性需求，架构必须要搭建这种业务场景和需求和最终产品实现之间的一个桥梁。就这么多年下来，我们还是发现就是很多人对架构它本身的理解存在偏差，很多人的理解就是我们会用了多层框架，就是J2ee的架构师。会用了SpringCloud就是微服务的架构师，会用Hadoop就是大数据的架构师。
这个本身是对架构一个巨大的误解，就能够基于开源项目或者是框架搭建一个基础的开发平台，确实是一个架构师应该具备的一个基本能力。但是这个能力它本身仅仅是架构设计里面很小的一个部分。
因为技术框架它不是业务需求，而实现在技术框架上面的业务功能组件，业务流程和业务逻辑，才能够满足真实具体的业务需求。
在业务需求没有最终实现前，技术框架它本身也没办法得到充分的验证，也没有和业务需求完成这个匹配过程。那么你这种空框架的搭建并没有很高的一个技术含量，或者说大部分人将架构他就理解成技术架构，而忽视了业务抽象和建模的这么一个能力。脱离了业务的技术架构，你连自己都无法验证最终架构的原型对现实业务的支撑能力及架构师最终设计的东西无法自己进行实证，这本身就是一个要命的事情。
架构师就变成了纸上谈兵，设计的模型也变成了空中楼阁，这显然不是我们想要的最终的一个结果。
一个好的架构师，我的理解他应该是给出在当前业务场景和需求下最合理的架构模型设计，而不是什么理想化的模型或者是网上顺手搬来的现成架构模型。架构师追求的不应该是理想化架构，而是当下的最合理化架构。
我们如何分析和理解产品，这是培养系统观和大架构观一个重点，你就是要能够深入细节，又能够跳出盒子的双重思维，既能够宏观全局，又能够微观局部，既能够把大的东西分解，又能够最终把它集成回去，既能够刨根究底，又能够不求甚解，置身产品之中，又能够跳出产品从用户视角的这么一个思考。
要具备这种架构能力，需要的是业务建模，业务到技术的分解转化能力，随时都是业务和需求导向，技术它是为业务服务，为需求服务，没有盲目的技术积累，只有合理的技术采用，没有理想化的模型，只有验证过的技术。
所以一个好的架构师一定是同时解决功能性架构和非功能性架构两方面的问题。对于非功能性架构就是我们常说的，它包括了可靠性、性能高、高可用，高扩展多方面的一个内容，这些都是架构师在搭建模型的时候必须要考虑的一个点。好的架构既可以做到稳如泰山，灵活扩展，具备弹性，以不变应万变的能力。同时好的架构也要充分考虑到各种异常边界、并发峰值、安全攻击等场景，能够确保系统平稳的高效运行。
所以越是复杂的业务，往往构建的业务系统和架构设计也就越复杂。但是对于架构师而言，你一定要意识到任何你做架构的这个复杂性，应该把它作为黑盒，屏蔽在架构设计内部，即架构的复杂性应该在架构设计的时候就隐藏掉，通过粗粒度的接口，将这种复杂性屏蔽在内部。
所以对于最终的开发人员，他往往并不需要知道你架构设计内部的这些复杂性，只是按照架构原则，标准规范，开发指南进行设计和开发就可以了。
这个本身也是架构设计一个重要的考虑点。大架构观本身就是认识和理解事物，分析和解决问题的的系统思维观。
在我前面发过相当多的关于思维框架和逻辑方面的一些文章或者是视频，那么对于我们IT从业人员如何去进一步的提升你的逻辑思考能力？今天结合个人实践给大家两个切实可行的建议，供大家参考。
建议1：养成阅读书和长文并总结的习惯
第一个点我把它叫做是一定要去养成读长文或者是读整本书，并自己进行归纳和总结的习惯。
因为当前在整个互联网快速发展的阶段，我们更多的人已经习惯于不断的去吸纳碎片化的知识，反而是不太注重长文的阅读，完整书籍的阅读。
但是对于书籍本身往往就是一种系统化的知识理论的总结，只前人知识经验的一种结构化呈现。你只有读这种系统化的书籍，往往才能够帮助你自己，结合你自己的工作经验去总结你系统化的知识体系，包括长文也是一样的道理。但是我现在发现很多人反而是喜欢去阅读别人的经验，别人已经归纳总结出来的经验点。你不断去阅读别人的经验，这些经验往往并不能变成你自己的经验。你只有去阅读和学习知识，并通过总结和实践，才能够成为转变为你的经验。
就拿我思维方面的文章来举一个简单的例子。
我个人发布过很多关于思维框架逻辑，个人知识管理方面的文章。不管是在头条号还是公众号，它实际的阅读量并不大。
但是在前段时间我发现一个问题，就是有另外一个也是在讲思维的人，他其实很少原创性的东西，他就是把别人包括我讲过的一些思维的一些文章，包括做的一些PPT的一些结构图，做了一个简单的整理，然后配一张图发布。反而是这类文章的阅读量相当高。
所以我有时候就也很纳闷，你去阅读这种文章看起来图也比较炫，归纳出来的经验点就那么三四个，你看了以后对你自己能有什么样的一些帮助呢？你都是在学别人归纳总结出来的知识，那么对于你自己去归纳你自己的知识体系有什么帮助呢？
所以在这个点上面我一直在强调，我们去阅读书籍和长文，并进行自我总结和笔记输出。不仅仅是去系统化整理我们自己的知识体系，更加重要的就是要去锻炼你个人去做归纳总结的能力。
所以现在随着AI和GPT的发展，我发现有些人很喜欢用Kimi，他用Kimi干什么用？就是别人的长文，别人的文章或者拿到的PDF文件输入给Kimi，让Kimi去做简单总结。
当然这个方法并不是说不好，确实是可以节约时间，但是你最后总结出来的你都是阅读的别人别人总结完以后的观点。你阅读的是结果，你没有阅读到别人总结出这个观点的时候，核心的思考的过程，所以这个时候其实对于你思维能力的提升没有任何的好处，这是我想说的第一个点。
建议2：形式化表达核心概念模型
多年前，我自己阅读书籍就养成了一个习惯。就是阅读过程中会直接在书籍上进行划线或批注，同时在书籍完成后再整理一篇读书笔记发布到博客上面。而且读书笔记内容尽量要少摘录书籍的原话，而是用自己总结的话语来阐述书籍中的关键内容和自己的心得体会。
在我开始做知识分享视频后，除了整理读书笔记外。我现在阅读完成书籍后，要求自己能够做到对书籍内容中的核心观点盲讲10分钟录制一期视频。而我们盲讲和口播的内容也正好就是我阅读书籍后我学习到的最关键内容点。
我一直强调，对于IT从业人员，特别是你已经逐渐的上升到架构师的时候，你一定要去提升你自己形象化表达的能力。
有时候我跟我们的技术人员跟我们的架构师去做交流，我们会去谈一些关键问题的技术解决方案，我就会说你既然把这个解决方案思路基本上已经想清楚了，你在白板上给我画一下，用简单的形式化的符号逻辑图或者是流程图，或者是集成交互图，你把你的思路简单的给我讲解一下。
实际上他很多时候讲不出来，你不能用最简单最形象化的东西把你的核心的要点思路呈现出来讲出来，那么很多时候你的思路其实逻辑并不是清晰的，你没有掌握这件事情核心的概念模型。这也正是费曼学习法所强调的一个关键点。你虽然大概知道这个事情怎么做，但是你的思路可能在你脑袋里面还是一团浆糊。
包括我最近跟有一些架构师去做沟通，也发现这个问题。说到类似于我们常说的云原生、微服务架构、缓存消息中间件各个技术点它都相当的清楚。但是一说到我们一个完整系统的设计，我们怎么样从前期的业务场景的分析，业务流程的梳理，逐渐的得出我们整个业务的架构、应用架构，底层的数据模型。他其实是没有一个系统化的设计方法，或者说他没有去完整的接受过类似于面向对象分析设计的训练，导致它很难用简单形式化的抽象的符号把它的核心的逻辑观点表达出来。
这也是IT人员从编码走向设计，从技术走向管理岗位的时候一定要有意识的去刻意训练的地方。训练的方式很简单，就是当我有了核心的观点了以后，我就跟我的团队讲，跟我的同事的讲，用形式化的一些符号，把我的核心的观点能够想明白又讲清楚。这个其实也是对于核心的你的思维能力逻辑能力的一个锻炼。
所以简单总结我刚才谈的这个两个点，第一个点是养成读书和读长文的习惯，读完了以后写总结写笔记，锻炼的是你核心的归纳的能力。第二个点，归纳完的东西要形象化的表达的出来，呈现出来，让别人能够理解锻炼了你的是演绎的能力。而对于归纳和演绎，刚好就是我们说的形式逻辑里面最核心的两个逻辑要素，你只有通过这种方法，你才能够不断提升你个人的思维能力。
好了，今天的简单分享就到这里，希望对大家有所启发。
