9.1 设计方法论

9.1 设计方法论

本节摘要：从需求到架构有一条可复演的推演链：翻译时间指标、划分任务、分配优先级、设计同步与缓冲、规划内存与中断、汇总预算、评审定版。本节给出这条七步链的具体操作与每步产出物，让「设计」从个人手感变成团队可审查的文档。

给设计方法论下一个操作性定义：设计是把时间指标逐层翻译成机制参数的过程，每一步翻译都要留下可复查的书面记录。本节按七步展开这条链。它不神秘，也不需要重型工具——一张表格加一套公式，就能把「我觉得这样行」升级为「按这个推演，最坏情况也满足」。

第一步：需求翻译成时间指标

需求文档里的时间语言必须全部翻译成可测参数：周期、截止期、抖动上限、响应时限、吞吐速率。逐条检查需求，凡出现「及时」「实时」「尽快」而无数字的，打回补数字——没有数字的需求无法设计也无法验证。产出物是时间指标表：每行一条需求、对应的指标、数值、来源（物理过程、通信协议、客户条款）与硬度（按 1.1 节分类）。这张表是后续所有步骤的输入，也是 9.2 节验证矩阵的对照物。

第二步：任务划分

划分的三个维度按序应用：速率——周期不同的动作不塞进一个任务（十毫秒的控制环与一秒的状态上报混在一个任务里，等于让快任务陪慢任务打瞌睡）；关键性——截止期硬度不同的动作分属不同任务，优先级才有意义；阻塞源——会阻塞在不同对象上的动作分开，避免「等网络时把控制环也睡了」。划分的产出物是任务清单：任务名、职责、触发方式（周期或事件）、触发速率。经验法则是中小系统五到十个任务为宜，任务过多则切换与同步开销反噬，过少则退化回大循环。

第三步：优先级分配与可行性分析

按速率单调（或截止期单调）定初始优先级，然后立即跑 3.2 节的两道闸门：利用率判据做快速体检，响应时间迭代给关键任务精算。这一步的价值在设计早期就显现：如果迭代结果超期，现在改任务划分或速率，代价是一行表格；联调后才发现，代价是一轮架构返工。产出物是优先级表：任务、优先级、周期、最坏执行时间、响应时间分析结果、余量比。余量低于两成的任务要标注，它们是后续负载增长时最先失守的部位。

第四步：同步与通信设计

逐对检查任务间的共享与传递：共享资源列清单，每项指定保护手段（4.1 节三级保护的哪一级）；数据流画成管线，每段管道指定队列深度、条目尺寸与满队列策略（4.2 节三取舍）；多锁任务标注加锁顺序（4.3 节纪律）。产出物是共享与管道表，它同时是评审会上被质询最狠的文档——锁与缓冲是运行期故障的头号来源，值得被狠问。

第五步：内存与中断规划

内存侧按第五章路线定案：栈预算表（初值、验证方法）、静态池清单（块尺寸、深度、耗尽策略）、堆的使用边界（谁能在什么时候分配）。中断侧按第六章规则定案：中断清单（源、优先级档位、服务程序职责、预期延迟）、优先级划线配置、屏蔽窗口清单。产出物各一张表，与前面的任务表合起来构成架构设计的全部主体。

第六步：预算汇总

把所有表格汇成一张时间预算总表：每个截止期需求，列出其构成项（任务最坏执行时间、抢占干扰、阻塞延迟、中断延迟、缓冲延迟），合计与需求对照，标注余量。这张表是设计阶段的毕业考：任何一行合不上，回到对应步骤改设计而不是拖到联调。它同时也是活的文档——需求变更、参数修订都从改这张表开始，而不是从改代码开始。

预算总表行模板（每条截止期需求一行）：
需求编号 | 指标与上限 | 执行时间 | 抢占干扰 | 阻塞延迟 | 中断与缓冲延迟 | 合计 | 余量
示例：  R-07   | 10ms 内响应 | 1.2ms   | 2.9ms   | 0.8ms    | 1.5ms         | 6.4ms | 36%
​

第七步：评审与定版

设计评审的质询按固定路线走：指标表有没有无数字项；任务划分有没有「一个任务多个速率」；优先级表的分析假设是否成立（独立任务？阻塞计入了吗）；锁顺序有没有全局一致；预算总表有没有余量低于两成的行。评审通过后架构定版，此后的变更必须走「先改表、后改码、再复算」的流程——设计文档从此不是历史文件，而是系统的运行宪法。

两个使用提醒

其一，方法的价值在「留下可复查的翻译链」，不在表格本身的格式——团队完全可以按自家模板裁剪，但每步的产出物必须存在且最新。其二，警惕把方法论做成一次性仪式：预算总表在需求变更后没有同步，是复盘案例（下一节）里反复出现的肇因。设计方法不是项目启动时的开幕式，而是贯穿全程的记账纪律。

本节要点回顾

• 设计是时间指标的逐层翻译，每步留下可复查的书面记录；
• 无数字的时间需求打回重写，否则设计与验证都无从谈起；
• 任务划分按速率、关键性、阻塞源三维展开，中小系统五到十个为宜；
• 优先级表附响应时间分析结果与余量比，低余量任务提前标注；
• 预算总表是设计阶段的毕业考，合不上的行回设计改、不拖到联调；
• 定版后的变更走「先改表、后改码、再复算」，文档即运行宪法。

常见问题

问：需求方给不出时间数字怎么办？ 协助翻译：把「用户觉得不卡」翻译成界面刷新间隔与响应上限，把「不丢数据」翻译成缓冲深度与丢弃策略。方法论的第一个动作就是这次翻译——需求方给的是意图，工程给的是数字，翻译是设计的起点。

问：任务划分有争议怎么裁决？ 回到三维度：速率不同必分、关键性不同必分、阻塞源不同宜分；同维度的争议（要不要把两个同速率功能合并），看共享状态量——共享越多越该同任务，同步开销就能省下来。

问：优先级表里的余量比怎么用？ 它是负载增长的缓冲指示：新需求来了先看还有哪些任务余量高于四成，把新增量安排到它们头上；全员余量见底时，方案不再是「调优先级」而是「重新划分」。

问：方法会不会拖慢小项目？ 七步法的最小形态（指标表、任务表、预算表各一页）半天就能完成，换来的是联调期的成周返工。小项目省的不是方法，是方法的表格体积。

问：已有系统怎么补方法？ 从复盘切入：挑最近一次时序故障，按 9.3 节的流程完整复盘，把过程中缺失的文档（指标、预算、验证矩阵）补齐——一次真实故障驱动的补课，比凭空补全更聚焦。

问：方法与敏捷迭代冲突吗？ 不冲突，颗粒度对齐即可：每次迭代的需求进入指标表与预算表，迭代评审对照预算增量——表格是活的，迭代的正好是表格。

方法论与工具的衔接

本节的产出物与第八章的工具一一对接：时间指标表对接验证矩阵，预算总表对接运行时统计的读数，优先级表对接跟踪时间线的核对。这条衔接链让设计文档「活」在开发过程中：每个阶段的工具输出都能回到表格核对，偏差即改。方法论落到这一步，就不再是文档架上的一叠纸，而是系统的运行时镜像——这也是本节开头那个操作性定义的完整兑现：每一步翻译都有记录，每条记录都能复查。