思考的逻辑-从意识到方法

本文主要是介绍思考的逻辑-从意识到方法，对大家解决编程问题具有一定的参考价值，需要的程序猿们随着小编来一起学习吧！

　　最基本的逻辑学只有归纳和演绎，归纳重点是由普遍现象得出一种结论，由实例得出抽象；而演绎重点则是从原则和规律演算事物的发展。逻辑本身让感性的思考增加了理性，让思考本身可以遵循一定的方式和方法，而不是天马行空。

　　注：在我对思考框架最新整理中，将思维逻辑分为两类，一个是归纳演绎逻辑，用于事物认知；一个是模式匹配逻辑，用于问题解决。

　　抽象和泛化，分解和集成，共性和个性，分类和聚合这些都是我们常用的思考方式。思考的事务本身唯有两种特性，一种是静态的结构，一种是动态的演进，静态+动态的构成了我们所思考的核心内容。

　　带着问题去思考，思考其本身是为了解决问题，因此思考的逻辑很多时候即是分析和解决问题的逻辑。那么从问题定义，问题的分类和分解，提出假设，制定方案，方案评估等即是一个可以参考的通用方法论。非结构化解决问题核心重点是优先提出假设再去验证，而非结构化解决问题的完全遍历。经验和隐形知识的一个重点体现则是提出假设的有效性和准确性。很多时候我们需要的是满意解而不是最优解。

　　注：实际在前期对思维能力和问题解决能力没做明确区分，在最新框架中将思维能力重新拆分为事物认知能力和问题解决能力。

　　思考和记忆不同，记性好的人并不一定就会思考，记忆唯一的作用就是方便你做最简单的1对1的模式匹配。思维方式并不在于记忆本身，懂得思考的路径，或者说如何去找到你需要的知识逐步求精才是重点。不破不立，破题往往比什么都重要。否则就是给你能够记住再多的公式也不会解一道复杂的试题。问题场景和方法工具的对应才是重点，方法工具本身无价值，知道什么问题场景下该用什么方法才会产生价值。

　　注：破题更多偏问题分析，而非简单的问题定义。

　　独立思考并不是指一定要有什么标新立异的想法，而是需要有一套适合自己的思考方法，能够独立地通过自己的思考来解决问题。在事物的发展之初，往往是从众性思考，而在事物发展中后期，往往需要的是独立思考。

　　系统思考是思维发展的一个重要阶段，系统思考的核心逻辑即系统工程。对任何事物的思考和观察首先是孤立的观察和分析，然后是放在一个群体或大环境里面进行分析。系统思考非单一目标思考，而是多目标的平衡性思考，不是单目标最优，而是整体最优化。动态平衡是我们谈系统思考的一个关键内容。

　　思考本身也有成本收益分析，因此思考不是一味地追求严密。任何严密的思考都趋同于一种穷举式的思考没有任何意义。但是在问题定义和进行归纳推论的时候却一定要严密。

　　思考有感性的成分，也有理性的成分；有完全的自觉，也有严谨的数据。思考真正的价值即在通过输入后大脑加工得出输出的过程。不同的人，在不同的场景下虽然可能有共同的输入，但是我们却往往得出不同的结论，思考真正体现出来的挑战往往正在于此。形成独立解决问题的能力是最难的，而这个能力的核心又在于适合自己的思维方式和逻辑，实践和工作的不断积累往往就是在完善思维模式。

　　思维模式的形成不能脱离实践，在实践过程中不断地遇到问题，解决问题，最终形成有价值的思维模式。抽象和归纳是形成思维库的过程；而分解和匹配是使用的过程。

　　注：早期已经提出归纳演绎和模式匹配两个逻辑，抽象归纳形成思维库自然是事物认知过程，而分解匹配使用思维库自然是问题解决过程。

　　抽象和归纳的重点是共性的提取，个性的抛弃，得出通用性的一些方法和原则。我们遇到的问题往往并不可能一成不变，但是我们一定要分析这些问题是否属于同类型的问题？是否有共性的地方？这些共性地方可以从问题场景，问题定义，问题解决方法等多个方面去抽取和提炼。

　　分解和匹配是使用思维库的过程，遇到复杂问题我们束手无策很多时候没有意识到问题是一个问题群，或问题本身是一个复合问题需要首先进行分解。分解后会形成子问题或子目标，这个时候才容易使用积累的思维库在细粒度层面完成模式匹配，匹配是最重要的思维模式，只有同匹配才能够真正解决问题。

　　很多时候我们谈到悟性，做技术往往也需要悟性，很多时候悟性问题并不是由于基础知识或技术技能没有通过。而是由于思维能力不能有效提升，很多时候只能解决重复的问题而不能解决新问题，能举一反一但是不能举一反三。

　　比如一个很熟练的编码人员往往很难提升到架构设计层面，不管做多少年他可能还是一个编码人员的思维模式，但是他编码熟练度和质量却很好。这些都是普遍存在的问题，而原因即在于事情做完后缺乏总结，总结的目的即是抽象和归纳，形成思维库，使自己的知识能够体系化。

　　如果说思维能力提升，一定是先从底向上，通过抽象和归纳将离散的经验结构化和体系化，然后再来考虑从顶向下的系统思考和分解规划。我们一直强调地解决问题是分而治之，但是前面没有抽象的经验库积累，我们就无法清楚该如何去分解，分解后该如何去解决问题。凡事有记录，看起来最不重要的事情，但是在个人知识管理和思维提升上却很重要。记录的是数据，只有拿到一手的数据我们才能够进行总结和归纳。

　　对于遇到问题时候的思考，一定要首先从自己身上找原因，再考虑外界和别人。很多时候并不是思考逻辑出问题，而是我们犯我执的大毛病，一有问题都是别人的跟自己无关。先把别人累一圈，问题解决不了自己再回头看看，这是个人很消极和官僚的做法。

　　要知道个人思维能力提升和进步，都是通过不断的实践，去积极面对和解决新问题的过程中解决的。我们只能通过实践来培养思考的逻辑，而不可能是通过思维形成实践方法。

　　多年前当我开始接触大型SOA实施项目的时候，由于前面根本没有接触过SOA，如何快速地熟悉和进入？没有实践过之前首先要在理论上弄清楚，道理上讲明白。那就先看一本SOA相关的书，找些标准的SOA资料学习，然后接着发现原有的平台，组件化，web service，基于流程的业务分析和建模，EAI企业服务总线，工作流很多知识其实是接触过，唯一需要的就是需要基于SOA把这些知识串联起来。越到后面，你会觉得本身已经不可能再衍生太多的新技术，都是原有的方法和理论的进一步融合而已。

　　在我接触MDM主数据管理的时候也是同样情况，开始并没有关注过MDM这个词，但是我原来做过SRM，PDM诸多业务系统，很早前就在做基础数据统一，流程统一，编码统一方面的工作，和MDM主数据管理的思路是吻合。只是现在的MDM主数据管理更加强调了全局统一主数据视图的提供和服务的实时集成。再看，主数据管理里面有部分本身就是BI的内容，BI这块原来也接触过，很多东西都是一样的，需要的是进一步进行知识的差异分析和比较。

　　当接入到SOA具体项目实施过程中的时候，我发现工作做得很多，但是确实方法和体系的指引，实践性的工作无法进一步抽象到更高科学体系和方法论层面。实践很重要，但是经过实践被验证有用的内容一定需要沉淀和总结，抽象为模型或方法论，这样的方法论是可以落地的方法论。

　　学习和实践需要的是站在别人肩膀上，模仿并超越，而不是简单复制。在过程中我们接触了业绩的SOA参考模型，SOA成熟度框架，IBM，微软，HP，埃森哲，Oracle多家的SOA理论体系和实施方法。我们需要做的是参考，而不是照搬，吸取各家好的一面，抛弃到复杂和无效的环节，最终形成自我的可落地的实践方法。自我经验形成一定遵循的是别人的方法-》自我实践-》自我方法的过程。没有最好，只有最适合；不要全部从头做起，而是扬弃。

　　触类旁通，同类型的知识往往并无边界。很多时候我在思考，我做过Delphi，VC++，.net开发，但是一直没有做过java开发，甚至一个很小的实际应用项目都没有开发过。但是我有java最基础的知识，有软件工程方面的设计和开发知识，懂那么一点点设计模式，有这些经验往往并不会阻碍到我去解决java项目开发中遇到的问题，去分析和定位。那就进一步说明开发过程中抽象出来的经验，分析解决问题的思路本身已经和任何语言无关。

　　这种经验可以应用到所有的软件开发中。很多时候知识本身无边界，流程分析和业务建模知识本身就会用到SOA中的流程集成和前期SOA需求分析中，数据库分析和设计知识在任何领域的数据建模都适用，单个大型软件产品中的架构分析知识你发现完全也可以应用到更高端的企业架构和应用架构中。已有的实践知识先抽象，当你面对新场景和新问题的时候再根据已有抽象模型进行泛化和匹配，越到后期你会发现你接触到的新东西越来越少，但是你能够不断组合的新东西却越来越多。

　　再回来说个人知识管理，我一直思考的就是知识管理本身不是目的，唯一的作用就是创造价值和帮助你快速地解决问题和达成目标。显性的知识，文档再多，在转化为你的经验的时候不能融合也没有用。包括我们说的知识分类和文档库的整理，如果不是亲自实践后的再整理和归档，基本是用处不到，没有经过我们说的显性-》隐性-》显性的转化。

　　正如别人拷贝一个几十G的资料给你，你不清楚如何用那就是一堆废纸。这也是我时刻考虑的是，清楚如何用，知识什么时候用什么，远远比单纯的记忆更加重要。我现在很少做各种知识的记忆，我需要的记忆都是实践完成后的关键线索，记忆力本身可以说是思维能力里面最次要的。知识管理本身也是，没有专门经过知识管理方面学习的人，他们完全也可能具备超强的思考能力，只是知识管理可以让我们更加高效，但是这个基础是思维能力本身达到。

　　当你面对一个新问题的时候，关键输入只有三个，从问题本身定义寻找线索，从你已有的知识积累寻找线索，从互联网大知识库中寻找线索，最终做好三者得匹配解释最简单的思考逻辑。

这篇关于思考的逻辑-从意识到方法的文章就介绍到这儿，希望我们推荐的文章对大家有所帮助，也希望大家多多支持为之网！