一句话：软件开发生命周期就是做一个软件要经历的固定几个阶段：想清楚要做什么 → 设计 → 写代码 → 测试 → 发布 → 维护。
前面讲的系统设计、架构原则属于"设计"阶段；碰撞检测、走迷宫算法属于"写代码"阶段。这一篇把它们串起来，看看整个流程是什么样的。
一、生活里的例子：请朋友吃一顿饭
| 步骤 | 做饭 | 对应软件阶段 |
|---|---|---|
| 1 | 问朋友想吃什么、有没有忌口 | 需求分析 |
| 2 | 定菜单、列购物清单、安排先做哪道 | 设计 |
| 3 | 切菜、炒菜 | 编码 |
| 4 | 出锅前尝一尝咸淡 | 测试 |
| 5 | 端上桌 | 发布 |
| 6 | 朋友说太辣，下次少放辣椒 | 维护 |
如果跳过第 1 步，做了一桌辣菜，结果朋友不吃辣，前面全白做了。软件也是这样。
二、六个阶段（用"做一个小射击游戏"举例）
阶段 1：需求分析 —— 要做什么？
做什么：弄清楚玩家要什么、游戏要有哪些功能、要做到什么程度。
射击游戏例子：
- 俯视角，玩家用 WASD 移动、鼠标瞄准射击
- 3 种武器、5 种敌人、10 个关卡
- 能在普通笔记本上跑到 60 帧
产出：需求文档（游戏里常叫策划案 / GDD）
上一篇说的"功能需求 + 非功能需求"，就是在这一步写清楚的。
阶段 2：设计 —— 怎么做？
做什么：决定系统怎么拆、模块怎么连、数据怎么存。
射击游戏例子：
- 拆成 Input、Movement、Weapon、Health、AI 等组件
- 子弹用对象池，快子弹用射线检测
- 敌人寻路用 BFS / A*
- 武器数值放进 ScriptableObject
产出：结构图、接口说明、技术方案
前面两篇"架构原则"和"系统设计"，全部属于这一步。
阶段 3：编码 —— 动手做
做什么：按设计写代码、做美术、做音效、搭关卡。
射击游戏例子：写移动脚本、写碰撞、写敌人 AI、拼关卡……
好习惯：
- 用Git管理代码，每做完一个小功能就提交一次
- 一个功能一个分支，做完再合并
- 写完先自己跑一遍
阶段 4：测试 —— 检查有没有问题
做什么：找 bug，确认功能符合需求。
| 测试类型 | 测什么 | 射击游戏例子 |
|---|---|---|
| 单元测试 | 一小块代码对不对 | 扣 30 血后，血量是不是 70 |
| 集成测试 | 几块合在一起对不对 | 子弹打中敌人 → 血条有没有变 |
| 游戏测试 | 好不好玩、难不难 | 第 3 关是不是太难，玩家都卡住 |
| 性能测试 | 卡不卡 | 屏幕上 500 颗子弹时还有没有 60 帧 |
单元测试小例子（Unity Test Framework）：
usingNUnit.Framework;usingUnityEngine;publicclassHealthTests{[Test]publicvoidTakeDamage_ReducesHealth(){vargo=newGameObject();varhealth=go.AddComponent<Health>();// Awake 会把血量设为满血 100health.TakeDamage(30);Assert.AreEqual(70,health.Current);// 需要 Health 公开一个 Current 属性}[Test]publicvoidHealth_NeverBelowZero(){varhealth=newGameObject().AddComponent<Health>();health.TakeDamage(999);Assert.AreEqual(0,health.Current);}}前面"把 Health 单独拆出来"的好处这里就体现了：拆得小，才好测。一个 2000 行的上帝 Player 几乎没法写测试。
阶段 5：发布 —— 交给玩家
做什么：打包、上架、上线服务器。
射击游戏例子：
- 打包 Windows / 安卓版本
- 上传到 Steam / 应用商店
- 联机游戏还要部署服务器、准备好回滚方案（新版本出问题能退回旧版）
阶段 6：维护 —— 上线后才是开始
做什么：修 bug、调平衡、出新内容、根据玩家反馈改进。
射击游戏例子：
- 玩家反馈：霰弹枪太强 → 改 WeaponData 里的伤害数字（数据驱动的好处！）
- 出新地图、新武器
- 修复"子弹偶尔穿墙"的 bug
很多游戏上线后的维护时间，比开发时间还长。所以前面架构做得好不好，维护阶段最能感觉出来。
三、为什么不能跳过前面的阶段？
bug 越晚发现，修起来越贵。（下面是业界常见的大致说法，用来感受数量级）
| 发现问题的阶段 | 修复代价（大约） | 例子 |
|---|---|---|
| 需求阶段 | 1 倍 | 改一句话：“敌人不会飞” |
| 设计阶段 | 5 倍 | 改一下结构图 |
| 编码阶段 | 10 倍 | 改代码 |
| 测试阶段 | 20 倍 | 改代码 + 重新测一遍 |
| 发布之后 | 100 倍 | 改代码、重新测、重新发版、玩家差评、可能要补偿 |
就像做菜：放盐前想清楚只要一秒钟；菜都端上桌了才发现太咸，就只能重做。
四、几种常见的开发模型
六个阶段是固定的，但怎么走有不同方式。
1. 瀑布模型：一步走完再走下一步
需求 → 设计 → 编码 → 测试 → 发布 → 维护 （像瀑布一样只往下流，不回头）| 优点 | 缺点 |
|---|---|
| 简单、清楚、文档全 | 做到最后才能看到成品，发现方向错了很难改 |
适合：需求非常明确、很少变的项目（如银行系统、硬件配套软件）
2. 敏捷 / 迭代模型：小步快跑，反复循环
┌─→ 需求 → 设计 → 编码 → 测试 → 演示 ─┐ └──────────────── 每 1～4 周一轮 ───────┘每一轮（叫一个迭代或Sprint）都做出一个能玩的小版本，然后根据反馈调整下一轮。
| 优点 | 缺点 |
|---|---|
| 很早就能看到成品，方向错了能及时改 | 需要经常沟通，文档可能不全 |
适合：需求经常变的项目 ——游戏开发大多用这种，因为"好不好玩"只有玩了才知道。
3. 原型模型：先做个粗糙的试试
先花几天做一个很丑但能玩的版本，验证想法，再决定要不要正式做。
游戏行业非常重视这一步：先用方块和圆圈做出来，好玩了再加美术。
五、游戏行业的特殊版本：里程碑
游戏开发通常按这些里程碑推进：
| 里程碑 | 意思 | 射击游戏例子 |
|---|---|---|
| 原型（Prototype） | 验证核心玩法好不好玩 | 方块小人能移动、开枪、打死圆形敌人 |
| 垂直切片（Vertical Slice） | 做一小段完整品质的内容 | 第 1 关：有美术、音效、UI，就像最终成品 |
| Alpha | 所有功能都有了，但 bug 多、内容不全 | 10 关都能玩，很多是临时素材 |
| Beta | 内容齐全，主要修 bug、调平衡 | 找玩家来测试 |
| Gold / 发布 | 正式发售 | 上架 Steam |
| 运营（Live Ops） | 持续更新 | 新武器、新地图、活动 |
核心思想：“先确认好玩，再投入大量资源”。很多失败的项目，问题都出在原型阶段没验证就直接开工。
六、每个阶段常用的工具
| 阶段 | 工具 |
|---|---|
| 需求 | 文档（Notion、飞书文档）、思维导图 |
| 设计 | 画图工具（draw.io、Figma） |
| 编码 | IDE（Visual Studio、Rider）、Git |
| 任务管理 | 看板（Trello、Jira）：待办 → 进行中 → 完成 |
| 测试 | Unity Test Framework、Bug 记录表 |
| 发布 | 自动打包（CI，如 GitHub Actions） |
| 维护 | 崩溃收集、玩家反馈渠道 |
七、常见的坑
| 坑 | 现象 | 建议 |
|---|---|---|
| 直接开始写代码 | 写一半发现方向不对，推倒重来 | 至少花一点时间写下需求 |
| 只有最后才测试 | 发布前一周 bug 多到修不完 | 每做完一个功能就测一下 |
| 不停加新功能（需求蔓延） | 项目永远做不完 | 先定"必须有"的功能，其他放下一版 |
| 不用版本管理 | 改坏了回不去，文件叫"最终版_改3_真最终版" | 第一天就用 Git |
| 以为发布就结束了 | 上线后 bug 一堆没人管 | 预留维护的时间和精力 |
| 原型做得太精致 | 花一个月做美术，结果玩法不好玩 | 原型用方块就够了 |
八、个人做小游戏怎么用？
不需要完整的流程，轻量版就够：
1. 写一页纸：游戏玩法、必须有的功能（需求） 2. 画一张图：分几个系统（设计） 3. 用方块做原型，1～2 周，看好不好玩（原型） 4. 好玩 → 每周做一个小功能，做完就玩一遍（迭代 + 测试） 5. 给朋友玩，收集意见（测试） 6. 发布到 itch.io 等平台（发布） 7. 根据反馈更新（维护）一句话总结
软件开发生命周期 = 需求 → 设计 → 编码 → 测试 → 发布 → 维护。
越早发现问题越便宜；游戏开发通常用迭代的方式小步快跑，先做原型确认好玩，再投入资源做完整内容。
