3.1 模型思维
模型这个词常常会听到，通常出现在某个 PPT 或者一篇商业评论中，社会和经济学中的模型往往比较朴素，金字塔、V 型图、四象限会以各种形式出现在不同场合中；软件工程师的模型会更加形式化，UML、E-R 图等，能用较为精确的形式语言描述；数学模型就更加精确，马尔可夫、蒙特卡洛等模型可以用数学语言描述。
广义来说这些都叫模型，甚至你随手在白板上画的一个用来解释当前程序结构的图形，这也能叫做模型。哲学家库恩将这种思维框架叫做范式，也就是模型。维基百科将广义的模型定义为：
我们天生就有用简单的东西代表另外一个东西的能力，比如幼儿园数数用的竹签，学习物理时的刚体、真空中的球形鸡，都是模型。通俗来说模型就是经验的抽象集合，平时听到的谚语、公式、定理本质上都是一种模型。
为了理解模型，斯科特·佩奇在 《模型思维》一书中给出了模型的几个特征：
模型是简化的。 正是因为我们要认识的事物非常复杂，因此需要通过简化找出最一般的规律，才能一语中的。"天圆地方"学说就是最简单的古人认识世界的模型之一；毛主席的"阶级划分论" 简单、直接的指出旧中国的社会状态。 模型是简化的。 正是因为我们要认识的事物非常复杂，因此需要通过简化找出最一般的规律，才能一语中的。"天圆地方"学说就是最简单的古人认识世界的模型之一；毛主席的"阶级划分论" 简单、直接的指出旧中国的社会状态。
模型是逻辑的。 例如用金字塔原理描述社会阶层，每层的定义是明确的而非模糊的，数学模型能用数学符号系统和公式描述，模型中的元素能用一种逻辑关系做到自洽。 模型是逻辑的。 例如用金字塔原理描述社会阶层，每层的定义是明确的而非模糊的，数学模型能用数学符号系统和公式描述，模型中的元素能用一种逻辑关系做到自洽。
模型是错误的。 因为模型是一种抽象，所有的模型都是错误的，只能在一个方面反映事物的特征。场景变了，模型就需要修正，连牛顿、爱因斯坦的定律都没能逃脱这个规律。好的模型能在尽可能简单的情况下较好的拟合事物，完全匹配现实的模型就不再满足简化特征了。 模型是错误的。 因为模型是一种抽象，所有的模型都是错误的，只能在一个方面反映事物的特征。场景变了，模型就需要修正，连牛顿、爱因斯坦的定律都没能逃脱这个规律。好的模型能在尽可能简单的情况下较好的拟合事物，完全匹配现实的模型就不再满足简化特征了。
为了建立和利用模型，模型思考有几个层次：
数据： 我们能直接观察到的现实情况，比如下雨了，并且雨下的很大。 数据： 我们能直接观察到的现实情况，比如下雨了，并且雨下的很大。
信息： 信息需要从观察到的情况中采样，转换成具体的的数字，比如某个地区某年的降雨量。 信息： 信息需要从观察到的情况中采样，转换成具体的的数字，比如某个地区某年的降雨量。
知识： 知识是面对信息的处理方式，比如我们利用信息，将信息中的一般规律找出来，建立模型。比如某地区降雨量和年度呈现一定相关性，建立一个周期性降雨模型。 知识： 知识是面对信息的处理方式，比如我们利用信息，将信息中的一般规律找出来，建立模型。比如某地区降雨量和年度呈现一定相关性，建立一个周期性降雨模型。
智慧： 面对不同情况需要使用不同的模型和修正模型的能力，并能用它指导实践，比如根据周期性降雨模型修建水利设施。 智慧： 面对不同情况需要使用不同的模型和修正模型的能力，并能用它指导实践，比如根据周期性降雨模型修建水利设施。
在斯科特·佩奇在《模型思维》[16]一书中，使用了一张形象的图例，如下所示：
我们可以尝试用这种方式来看待原本很困难的知识，比如去简化复杂问题，并理解它。通过模型思维来看待软件开发，我们会发现，软件从设计到开发的过程就是各种模型的转换。
我整理了一个图表，说明了一款软件从商业探索开始到编译成可交付的软件整个过程中可能会用到的模型。
我将模型分为形式化和非形式化两种。形式化的模型是精确描述的模型，例如表达领域模型的 UML、ER 图，而非形式化的模型是一些非精确描述的模型，主要用来做商业、业务探索。
对于应用开发的软件工程师来说，核心的问题并非如何编写代码，而是如何将非形式化的业务输入（模型）进行合理抽象、设计，并转换为形式化模型的过程。
某种程度上来说，通过高级语言编写的代码也是一种模型。在多年以前，计算机科学家们认为编写 Java 代码的人不算程序员，可以由业务人员直接编写业务软件。软件工程中非形式化和形式化之间存在一个巨大的鸿沟，编程就是模型的形式化过程，从这个角度看能深刻分析业务并获得良好抽象结果的程序员具有竞争力，并不会被 AI 编程所代替。
在非形式化模型这一步，实际上又存在两种模型。一种是描述软件背后的生意，即使不使用计算机系统参与到业务中，该如何完成交易，并让企业获得利润，我把它叫做商业模型。另一种是描述软件的操作和交互的模型，关注参与的用户、流程和业务规则，我把它叫做软件业务模型。
我们可以分别将其定义一下：
那么弄明白商业模型和业务模型后，再来看软件设计，软件设计就是关注软件如何为业务、商业提供服务，提高业务和商业能力。虽然商业模型和业务模型有所不同，但是从商业模型体现的生意出发就能快速地理解一个应用软件（和日常生活相关的软件，区别于工具类软件，例如电商、ERP 等软件）。
优秀的产品经理往往能深刻地理解商业模型，然后才设计出合适的软件业务模型，避免了空想的业务规则，以及铺天盖地无用的功能。优秀的架构师应该也能理解商业模型，并从软件业务模型中提取合适的概念，构建软件的骨架，而不是让软件构建在没有地基的空地上，然后修修补补。
在软件实施过程中，需要思考项目管理、团队的问题，项目经理或者 Tech Lead 也可以有自己的模型理解和认识项目、团队管理、项目管理的模型，就是我们熟悉的瀑布、敏捷。团队管理的模型比较少，在后面会讨论一种系统化的团队模型，通过将团队中的个体分为 Dispatcher、Worker 来认识团队。
除此之外，还有一些模型并不需要过多深入了解，这就是和计算机工作原理相关的模型，这是计算机科学家的工作，对于普通开发者来说可以加深对计算机的理解。例如，符合人类的认知的编程语言（面向对象、函数式）背后的模型，面向对象可以看做一种模型，还有一些计算机科学基础的模型：冯诺依曼结构、图灵模型、布尔逻辑（数理模型）。
将这些模型串起来，能够提高对软件工程的理解，以及每个部分背后的逻辑，明白这些模型背后的目标后可以更加从容地应对各种问题。