波仔
⌨️ 第一章 编程的基础知识
📄 一句话概括

软件不是一上来就敲代码的：需求分析→需求定义→设计→开发→测试，五步流水线里【写代码】只排第四——上游错一步，下游全返工。

📝 本节和前面几节的关系

1-5 的五种职业各自在哪一环出力，本节给出时间轴答案。它与 数据库课 5-1 引入系统的流程 讲的是同一件事——那门课站在【引入数据库】的角度，本节站在【开发软件】的角度，两条流程能一一对上。

一、五步流水线一张图

需求分析（问明白：要解决什么问题）
    ↓
需求定义（写清楚：系统该有哪些功能）
    ↓
设计（画图纸：架构、数据库、界面）
    ↓
开发（施工：写代码）
    ↓
测试（验收：按需求逐条验货）

核心思想：越靠前的步骤越便宜、越靠后越贵。改一行需求的字，设计图跟着改；改一张设计图，代码跟着重写；代码写完了才发现需求理解错，是软件行业最贵的错误。

二、每一步在干什么

① 需求分析：还没到系统层面——先搞清【客户的业务哪里痛】。方法：访谈、看现有的工作方式、盯异常流程（数据库课 5-4 说过：异常流程才是设计难点）。

② 需求定义：把调研结果写成白纸黑字：谁用、干什么、数据保什么、性能要多快。这份文档是后面所有步骤的【合同】——验收时逐条对照的就是它。

③ 设计：翻译成技术方案——系统怎么分层（1-2 的执行环境选哪种）、数据库怎么建表（数据库课第五章整套方法在这里用上）、界面长什么样。

④ 开发：写代码＋调试。这一步只占全程的一小段（1-9 会讲写码之外的活）。

⑤ 测试：按需求定义逐条验货——【需求文档第 3 条说批量导入，那就造 1 万条数据导一次】。测试发现的问题按严重程度回炉。

三、为什么【问明白】是专业活

新手以为需求分析是【客户说什么记什么】。正解是客户说的叫愿望，不是需求：

四、动手 Demo：给【教室照明管理系统】走一遍五步

看到什么算成功： 1. 需求分析：校方痛点＝放学忘关灯、电费高、手动巡楼；观察现有巡楼流程与异常（暴雨提前开灯）； 2. 需求定义：三条硬需求——按课表自动开关、支持手动强制、月度能耗报表；写清【断网时控制器本地策略照旧】； 3. 设计：控制器＋网关＋云端数据库＋Web 界面，画出数据流与表结构； 4. 开发：实现并联调； 5. 测试：按三条硬需求逐条验，再专测异常——【断网 10 分钟恢复后，灯的状态对不对？】

读结果：注意第 2 步那行【断网时本地策略照旧】——它来自需求分析时问出的异常场景，而不是开发时的灵机一动。上游多问一句，下游少熬一夜。

30 秒实验

回忆任何一件你参与过或听说过的【做了返工】的事（不限于软件），按五步对号：问题出在哪一步？

看到什么算成功：能明确说出【其实是需求那步没问清／设计那步没定协议版本】这类上游归因。

读结果：多数返工向上追因，都会追到需求或设计——五步流水线不是流程图装饰，是追责和自保的工具。

常见误区

  1. 【需求文档是走形式】——它是验收的依据、变更的基准线；没有它，【做完了】与【做对了】无法区分。
  2. 【测试放最后做就行】——测试用例应与设计同步产出（1-5 讲过），敏捷开发更是全程边测边写（下一节）。
  3. 【写代码是工作量最大的环节】——行业经验里代码往往不到一半；需求、设计、测试、维护合起来才是大头。
  4. 【五步只能严格顺序走】——瀑布模式是这样，但还有小步循环的走法（下一节的敏捷）；五步讲的是【该做的事】，不是【做事的顺序只有一种】。
自测三问（点开对答案） 1. **需求分析与需求定义的区别？** 分析是【调研搞清楚】（访谈、观察、挖异常），定义是【落成文档】（谁用、做什么、验收标准）——一个在问，一个在写。 2. **为什么上游错误最贵？** 改需求的成本是改文档，改代码的成本是重写＋重测＋回归；越靠后，同一个错误的波及面越大。 3. **本节五步与数据库课 5-1 的引入流程怎么对上？** 调查→需求→设计→开发→测试→运用，两边的【需求/设计/开发/测试】一一对应；数据库课多了【运用】，因为引入系统后还有长期运维（那门课第六、七章整章都在讲它）。

相关笔记