20.计算思维（Computational Thinking，CT）

前言

方法论有很多：

本次介绍：计算思维

一、计算思维

重点：

1.脑子里怎么分析问题

2.把问题转成可以被信息处理（计算机）执行的方案

3.不是标准作业流程 SOP，不是：1 分解完→2 模式识别完→3 抽象完→4 写算法。 它是一套思考工具集合，解决复杂问题时脑子反复来回用，工程开发、写代码、调试都会交替跳转使用。

4.用计算机科学的思路去分析问题，而不等于写代码。代码只是算法的实现载体。

二、计算思维四大核心：分解、模式识别、模式概括（抽象）、算法

四大要素依次递进：把大问题拆开 → 找规律共同点 → 提炼抽象模型忽略无关细节 → 写出一步步可执行方案。

1. 分解 Decomposition

把复杂的大问题，拆成多个更小、更容易处理的小子问题。
大问题本身很难直接解决；拆分后逐个解决子问题，最后合并结果。

例子

一个模拟量采集项目：总任务：读取多路AD电压
分解：

• SPI硬件初始化
• 芯片复位
• 读取芯片ID校验芯片正常
• 寄存器配置、自校准
• 等待RDY就绪判忙
• SPI读写寄存器
• 读取ADC原始值
• 原始值换算成电压
• 互斥锁保护多线程访问
• 批量读取全部通道

每一块都是子问题，单独写函数，最后拼起来。

2. 模式识别 Pattern Recognition

观察数据、现象、子问题，找出其中的规律、重复出现的特征、相似点与不同点。
做完分解之后，观察各个小问题：哪些地方是重复的？哪些条件会带来什么结果？识别模式，避免重复劳动。

例子

• 读通道电压，流程高度相似：写控制寄存器 → 启动单次转换 → 等待RDY → 读2字节 → 转电压。
• SPI操作总是：CS拉低 → 收发 → CS拉高。这就是识别出来的模式。

关键点：找重复、找共性、找因果；看到现象归纳出现象背后的模式。

3. 模式概括 / 抽象 Abstraction（模式概括就是抽象的过程）

抽象：只保留解决问题必须的关键信息，忽略无关、次要细节；把识别到的模式提炼成通用模型，不绑定某一个具体案例。
“模式概括”就是从多个具体实例，总结出通用规则，是通向抽象的步骤。

• 具体：读ADC通道0；读ADC通道1（一个个具体操作）
• 模式概括：所有通道读取流程大体一致，只有通道号数字不一样
• 抽象：封装函数 adc_read_data(uint8_t Channel)，传入通道号就能读任意通道；隐藏内部SPI时序、CS操作细节。调用者只需要给通道号，不需要关心底层SPI怎么收发几个字节。

✅抽象核心：过滤不重要信息，聚焦对问题有用的信息。
调用函数的人不需要知道内部实现，只需要知道输入输出。

4. 算法 Algorithm

算法：一套明确、有序、可执行、有限步骤的指令序列，用来解决某一类问题。输入 → 执行步骤 → 输出。
经过分解、识别模式、抽象之后，最终产出就是算法。
算法必须满足：

例子

代码里adc_busy()就是一个算法：
输入：无；输出：是否AD转换就绪
步骤：
①循环读取RDY引脚电平
②如果RDY为低，返回就绪；
③超时则读状态寄存器打印报错，返回未就绪；
④中间间隔延时。

代码只是算法的一种实现载体；算法是思路，可以用中文描述、流程图、伪代码、C语言写出来。

完整流程串联（完整计算思维工作流）

以ADC多路采集举例完整链路：

容易混淆点区分

计算思维 ≠ 编程：编程是工具；计算思维是思考方法，可以不用电脑也能用。

三、具体实践

重点：

        不是严格先后执行的流水线步骤，不是：先做完分解 → 再做模式识别 → 再抽象 → 最后写算法，做完一个才能下一个。

        更准确：是解决同一个复杂问题时，脑子里用到的4种思考工具，会来回跳、反复用。

举个大白话类比：
好比你修一台坏的设备，你会用到：

你不会死板的：完全拆完，才开始对比；对比完才过滤无关信息；全部做完才动手检修。中间会来回倒。

例如写ADC代码

目标：要实现读取AD多路ADC电压。

1. 分解：把大任务切碎

脑子里想：这个大活太复杂，我把它切成一堆小任务。

• SPI初始化
• 芯片硬件复位
• 读ID判断芯片是否活着
• SPI读写寄存器
• 等待RDY就绪
• 芯片自校准
• 读ADC原始数据
• 原始值换算电压
• 多线程加互斥锁
• 循环读取全部通道

👉作用：大问题啃不动，切成小碎片，碎片一个个处理。

但切完碎片之后，你马上就要观察这些碎片，不是等全部切完。

2. 模式识别：看碎片，找重复、找相同、找规律

盯着上面一堆小任务看，找共同点：

• 不管读寄存器还是写寄存器，SPI都要：CS拉低 → 收发 → CS拉高。流程一模一样。
• 读通道0、通道1、通道2……流程几乎一样，仅仅通道号数字不同。
• 每次AD转换完成，都要看RDY引脚电平。

👉作用：发现重复劳动。看到“这件事反复出现”。

        发现重复之后，你不会停在这里，你会进一步想：能不能不要复制粘贴一模一样代码？→这就进入抽象。

3.模式概括+抽象：提炼通用，隐藏细节

        既然很多地方都要SPI收发，我不要每次都手写一遍CS拉低拉高。
        把重复的SPI收发封装成函数：adc_write() adc_read()。

        以后要用SPI写数据，直接调用函数。调用者不用关心CS怎么拉，延时多少，只需要传入要发送的数据。把底层细节藏起来。

        读通道也封装函数 adc_read_data(uint8_t Channel)，传入通道号就读对应通道。不用每路写一套代码。

👉作用：把具体案例，提炼成通用工具；丢掉无关细节。

4. 算法：给出一步一步明确操作流程

现在有了一堆封装好的函数工具，组合出做事的步骤。

示例：单通道读取算法

👉作用：把前面所有思考，变成一套可执行步骤。算法可以写成伪代码、流程图、C代码。

关键误区：是不是固定顺序1‑2‑3‑4？

❌错误理解：

分解全部做完 → 全部模式识别做完 → 全部抽象做完 → 写算法。线性流水线。

✅真实工程思考过程（来回跳转）：

甚至调试的时候：跑代码出错，又要重新分解问题、识别错误模式、重新抽象、修改算法。

总结

• 分解：大问题拆小
• 模式识别：在小问题里找重复规律
• 抽象：利用规律封装通用工具，屏蔽细节
• 算法：用工具编排一套一步步做事的流程

它们是四种思考武器，不是四步固定工序。解决工程问题会交替使用。

对比生活例子：做蛋糕

思考的时候，不会完全备完所有料，才想搅拌；搅拌过程发现问题还会回头调整配料。

四、缺少一项后的结果

如果缺少其中某一项，写代码会变成什么糟糕样子？

现实开发感悟

实际写代码，往往不是完全缺失某一项，而是做的不到位：

• 分解：拆了函数，但单个函数还是 200‑300 行，拆得不够；
• 模式识别：看到一部分重复，但漏掉一部分；
• 抽象：封装函数，但内部还是向外泄露很多硬件细节；
• 算法：正常情况可以跑，异常 / 边界情况完全没考虑。