波仔
🧩 第九章 建模：填补现实世界和软件之间的沟壑
📄 一句话概括

嵌入式代码量很小，但验证工作很大——实测一个洗衣机控制器 实现 12 行、验证 21 行，验证是实现的 1.8 倍。

📝 本节和前面几节的关系

9.11 说嵌入式替人干活，这一节说为什么它的研发重点不在写代码。

一、代码小，工作量不小

一个洗衣机控制器：5 个状态、7 条迁移，实现只要 12 行。 但每条迁移要测三种情况：正常、边界、异常 → 21 行验证。 验证是实现的 1.8 倍，这个比例在嵌入式里很正常。

二、为什么验证这么重

错了会烧板子、会漏电、会伤人——代价太高。 而且现场改不了：出货十万台，改一次要召回。 所以嵌入式把【证明它对】当成主要工作，而不是把【写出来】当成主要工作。

三、研究开发指的是什么

不是研究怎么写代码，而是研究【这个设备在各种异常下会怎样】。 包括硬件与软件的配合：驱动、时序、中断、掉电恢复。 所以它是硬件＋软件＋验证三块合起来的研发，缺一块都不算完成。

四、这跟业务系统的差别

业务系统出错可以打补丁，用户刷新一下就好。 嵌入式出错可能没有下一次——所以它的质量要求来自【不可逆】。 这也是为什么 9.5 说它的成败标准是【不能错、不能停】。

五、动手 Demo：嵌入式软件中设备的研究开发很重要

数一个洗衣机控制器的状态与迁移。 按【每条迁移测正常/边界/异常】算验证行数，与实现行数对比。

states = ["待机", "进水", "洗涤", "排水", "脱水"]
trans = [("待机", "按启动", "进水"), ("进水", "到位", "洗涤"),
         ("洗涤", "时间到", "排水"), ("排水", "排空", "脱水"),
         ("脱水", "时间到", "待机"), ("进水", "超时", "待机"),
         ("排水", "超时", "待机")]

impl, tests = 12, len(trans) * 3
print(len(states), len(trans), impl, tests, round(tests / impl, 1))
# 5 7 12 21 1.8

实跑输出：

--------------------------------------------------------------------
嵌入式软件中设备的研究开发很重要
--------------------------------------------------------------------

  嵌入式的代码量往往很小，**但验证工作很大**。实测一个洗衣机控制器：

  项目           行数     说明
  ---------------------------------------------------
  状态机实现     12       5 个状态 + 迁移判断
  验证用例       21       7 条迁移各测正常/边界/异常

      状态                        5 个
      迁移                        7 条
      实现行数                    12 行
      验证行数                    21 行
      验证是实现的                1.8 倍

  **验证是实现的 1.8 倍**——这就是嵌入式研发的重点：不是写得多，是【证明它对】。
  **因为错了会烧板子、会漏电、会伤人**，所以每条迁移都要测异常分支。
  **这也是 9.12 说【设备的研究开发很重要】的实际含义。**

实测：5 个状态、7 条迁移，实现 12 行、验证 21 行，验证是实现的 1.8 倍。 因为错了会烧板子、会伤人，而且出货之后改不了。 所以嵌入式把【证明它对】当成主要工作。

30 秒实验

  1. 给你的一个功能数一数：实现几行、验证几行，比例是多少。
  2. 找出一个【出错了改不回来】的功能，看它的验证够不够。

常见误区

  1. 以为嵌入式代码少所以工作量小。验证量往往是实现的两倍。
  2. 以为研究开发就是写代码。硬软配合与异常验证才是大头。
自测三问（点开对答案） 1. 实测比例是多少？ —— 实现 12 行、验证 21 行，验证是实现的 1.8 倍。 2. 为什么验证这么重？ —— 错了会烧板子伤人，出货十万台后改一次要召回，代价不可逆。 3. 研究开发指什么？ —— 研究设备在各种异常下的行为，含硬件软件配合、驱动、时序、中断、掉电恢复。

相关笔记