工程控制——失控类型、六字模型与统一闭环

一句话

软件工程控制 = 控制「做什么、做到什么程度、怎么做」。工程问题可以归纳为四类失控，用六字模型（做/对/全/适/整/快）逐一应对，最后用反馈闭环让每次修正都从问题产生处重新执行。

一、四类失控与六字模型

四类失控

问题 现象 控制方法
不做（漏做） 忘记实现、忘记测试、遗漏需求 Checklist、需求追踪、覆盖率、Review
少做（欠缺） 功能实现了一半、异常没处理、边界没考虑 Definition of Done、测试、Review、规范
多做（过度） 过度设计、提前优化、写很多没人用的代码 YAGNI、需求边界、架构约束、阶段目标
乱做（混乱） 代码耦合、职责不清、命名混乱 分层、模块化、代码规范、重构

四个问题分别对应不同的工程手段。

1. 防止漏做（Don’t Miss）

1
2
3
4
5
需求
 ├── 登录
 ├── 注册
 ├── 找回密码
 └── 修改密码

开发时每一项都必须对应：需求 → 设计 → 代码 → 测试 → 验收。任何一个没有对应，就知道漏了。本质是：确保每个需求都有归宿。

2. 防止少做（Don’t Underdo）

例如写了 SaveFile() 能够保存，但缺少：权限错误、文件不存在、磁盘满、编码错误、Undo、日志。怎么办？不是靠记忆，而是靠 Definition of Done（DoD）——规定一个功能完成必须满足编译通过、单元测试通过、异常处理、日志、文档、Review，否则不能合并。

3. 防止多做（Don’t Overdo）

需求是「显示一个按钮」，结果写了 WidgetFactory、ThemeFactory、ButtonManager、PluginSystem、Reflection、ScriptEngine——实际上一个 QPushButton 就够了。软件工程有一句很经典的话：You Aren’t Gonna Need It（YAGNI）——不要实现未来可能需要的东西。还有 MVP、KISS、迭代开发都是解决这个问题。

4. 防止乱做（Don’t Mess）

UI、网络、数据库、算法全部互相调用，最后成蜘蛛网。于是采用 View → ViewModel → Service → Repository → Infrastructure 或 Presentation → Application → Domain → Infrastructure，限制依赖方向。

工程控制远不止代码组织

控制对象 控制手段
做不做 需求管理、任务管理
少不少 DoD、测试、Review
多不多 MVP、YAGNI、需求边界
乱不乱 架构、分层、规范
对不对 测试、验收
快不快 自动化、CI/CD、工具
稳不稳 监控、日志、回归测试
能不能维护 模块化、文档、代码规范

六字控制模型

工程控制 = 控制六件事：做、对、全、适、整、快。

  • 做：有没有完成？（防止漏做）
  • 对：结果是否正确？（测试、验证）
  • 全：是否覆盖完整？（边界、异常、需求）
  • 适：是否做到恰到好处？（避免过度设计）
  • 整：是否组织良好？（架构、模块、命名）
  • 快：是否能高效持续开发？（自动化、工具链）

软件组织原则主要解决「整」；测试主要解决「对」；需求管理和清单主要解决「做」和「全」；YAGNI、MVP 等原则主要解决「适」。把这些组合起来，基本就覆盖了软件工程中绝大多数的控制目标。

二、反馈闭环：原创开发与两种流程

原创 vs 复刻：最大的区别

复刻软件时：需求 → 基本完整 → 一路做到发布（目标软件已经存在，你只是分析、拆解、实现）。

原创软件不是这样：

1
2
3
想法 → 分析需求（一定是不完整的）→ 第一版（Prototype）→ 实际体验
→ 发现不足 → 修改需求 → 修改设计 → 修改代码 → 重新测试 → 再次体验
→ ……重复很多轮 → 功能基本稳定 → Beta → 继续修改 → Release v1.0

每次插手都要全流程重执行

每次插手都要从插手处到后面的流程全执行。

例如：

1
需求 → 设计 → 编码 → 测试 → 体验 → 发布
  • 测试时发现「这个功能其实应该再加一个选项」→ 回到需求重新走
  • 体验时发现「CLI 参数应该换个名字」→ 回到 CLI 接口设计重新走
  • GUI 使用后发现按钮位置不合理 → 回到 UI 设计重新走

任何阶段发现问题，都回退到问题产生的位置，然后重新流向最后。

两种流程同时存在

第一种：开发流程（Forward Flow）——不断向前推进：需求 → 设计 → 编码 → 测试 → 发布。

第二种：反馈流程（Feedback Flow）：

1
用户体验 → 发现问题 → 定位问题属于哪一阶段 → 回退到该阶段 → 重新执行后续所有阶段
  • 需求错了 → 从需求开始重新执行
  • API 设计错了 → 从接口设计开始重新执行
  • CLI 参数设计错了 → 从 CLI 接口开始重新执行
  • GUI 布局不好 → 从 UI 设计开始重新执行
  • 代码 Bug → 从编码开始重新执行
  • 测试漏了 → 从测试开始重新执行

真正的软件工程不是一条直线，而是一条带反馈闭环的流水线。

CLI / GUI 接口 = 产品对外接口

CLI 命令参数和 GUI 用户功能可以视为产品对外接口（Public Interface）。当这两个接口稳定时，意味着产品的外部行为已经基本确定；内部实现仍然可以继续重构优化，只要不破坏对外接口即可。这也是很多成熟软件能够长期演进而保持兼容性的原因。

三、与相近学科的关系

这个方向不是一个全新的思想，但总结的角度和现有软件工程教材并不完全一样。有几个非常接近的学科：

  1. 控制论（Cybernetics）：研究如何通过反馈让系统达到目标。核心概念：目标、反馈、误差、修正、闭环。「发现问题→回退→重新执行后续流程」就是一个典型的反馈控制。
  2. 软件工程（Software Engineering）：需求、设计、实现、测试、维护，以及生命周期、软件质量、软件度量、软件过程、配置管理、风险管理。
  3. 系统论（Systems Theory）：研究复杂系统如何组成（元素、边界、层次、相互作用、演化）。
  4. 信息论（Information Theory）：什么是信息（熵、编码、信道、噪声、压缩、容量）。

如果存在一本「软件工程控制论」，它更可能不是按开发阶段组织，而是按控制对象组织：控制目标 → 控制对象（需求/功能/架构/接口/代码/文档/测试/发布）→ 控制方法 → 控制流程 → 控制反馈 → 控制指标 → 自动控制。每一种控制对象都会讨论：为什么控制、控制什么、如何控制、如何检查、如何度量。假想的书目可能是：第一章 什么是工程控制 / 第二章 控制目标 / 第三章 控制对象 / 第四章 控制方法 / 第五章 控制流程 / 第六章 控制反馈 / 第七章 控制指标 / 第八章 自动控制 / 第九章 工程优化。

这种「……论」类的学科通常不是在教具体技术，而是在回答「这个领域最基本的规律是什么」，一般包含八项通用内容：研究对象（究竟研究什么）、基本概念（定义术语统一语言）、基本原理（最核心规律）、模型（用模型解释现实）、方法（如何应用规律）、验证（如何证明理论有效）、应用（解决哪些问题）、局限（哪些情况不适用）。工程控制若成体系，也应具备这八项。

如何验证「所有实践都能归类为某种控制」

不要急着叫「软件工程控制论」——控制论已是成熟学科。更稳妥的是先验证一个问题：软件工程中的所有实践，是否都可以归类为某一种控制？ 例如：

1
2
3
4
5
6
7
8
代码规范 → 控制「乱」
单元测试 → 控制「错」
需求评审 → 控制「漏」
YAGNI    → 控制「多」
重构      → 控制「乱」
CI       → 控制「回归」
Git      → 控制「变更」
日志      → 控制「定位」

如果大部分工程实践都能自然落入少数几个控制类别，那说明找到的是一种统一的分类模型——未必成为新学科，但很可能成为比按开发阶段组织知识更容易理解的软件工程框架。

四、失控分类的扩展

已总结出的漏做、少做、多做、乱做，其实已经是在建立一种分类体系。如果继续发展，这个体系还可能扩展为：

  • 漏（遗漏）
  • 错（错误）
  • 少（欠缺）
  • 多（过度）
  • 乱（混乱）
  • 慢（效率低）
  • 脆（稳定性差）
  • 难（难维护）

然后针对每一类总结：产生原因、控制方法、检查方法、自动化工具、度量指标。

这种组织方式与传统软件工程教材按生命周期（需求→设计→编码→测试）编排相比，是另一种以控制目标为中心的框架。如果这种分类能够系统地覆盖软件工程实践，并且具有解释力和指导性，就有可能形成一个完整的理论框架。

五、三个核心问题

现在已经从「怎么写代码」进入到「如何让工程系统持续受控」这个层面。最值得抓住的不是急着给它命名，而是逐渐回答三个问题：

  1. 工程到底有哪些失控类型？
  2. 每种失控如何被发现？
  3. 发现后应该从哪里回退，并重新执行哪些流程？

如果这三个问题能形成稳定、可复用的规则，「工程控制」框架就会越来越清晰。

六、统一闭环模型与软件工程元模型

如果能回答一个更有价值的问题：

能不能把需求、设计、代码组织、Review、测试、迭代、发布、维护，统一放进一个「目标 → 实际 → 偏差 → 检查 → 修正 → 再验证」的闭环模型里？

1
2
3
4
5
6
7
8
9
10
目标
 ↓
控制器
 ↓
系统
 ↓
输出
 ↑
反馈
 └──────────

如果能，而且能够解释现有软件工程方法为什么存在、各自解决什么问题，那么这个框架就不只是「类比控制论」，而会比较像一个真正的软件工程元模型——从「怎么写软件」往上走一层，到「软件工程为什么需要这些东西，以及这些东西分别控制什么偏差」。

与其他线的关系

  • 与过程与流程线：工程控制管「失控和回退」，过程与流程管「变化和步骤的层次」——控制作用在流程上
  • 与单一职责主题：「乱做（混乱）」的解法（分层、模块化、职责单一）就是单一职责主题
  • 与文档组织线：文档组织线的「逐项审查」是工程控制在审查环节的执行——一次只审查一种性质
  • 与最小闭环主题（最小闭环/）：统一闭环模型（目标→实际→偏差→修正→再验证）就是最小闭环在工程层面的展开