[I.3] 个人作业: 结课总结

项目	内容
这个作业属于哪个课程	2026 年春季软件工程
这个作业的要求在哪里	[I.3] 个人作业: 结课总结
我在这个课程的目标是	理解工业级软件开发的完整链路, 学习如何将需求、设计、实现、测试、发布和维护连接成一个可持续演进的软件工程过程; 同时提升团队协作、项目管理和复杂问题拆解能力
这个作业在哪个具体方面帮助我实现目标	重新回顾学期初提出的问题, 并结合个人作业、结对编程和团队项目中的实际经历, 检查自己对软件工程方法的理解是否发生了变化

提问回顾与解答

提问题的博客

Q1. “精通” VS “全栈”

当我们谈论“全栈工程师”的时候，我们说的究竟是“交响乐作曲家写各个乐器的乐谱”，还是“演奏家满场奔走，操作各种乐器”呢？当工程师设计软件的时候，工程师的设计、修改错误等活动大致等同于交响乐的谱写完善阶段，两个职业都假设一旦程序/乐谱写好，它们就会被正确地执行。

• 问题：作者用了单人乐队和乐手的例子，想说明我们需要精通某一门技术。就像交响乐团，是由很多人来演奏不同的乐器。但在现实中，只精通一项技术已经不足以满足需求了，比如训练模型的时候，如果只懂算法，但不了解硬件相关知识，或许也不能达到很好的效果。很多问题需要跨领域的知识才能解决。

• 回答：通过课程实践，我认为一方面要有一个相对深入的主攻方向，另一方面也要对相关领域有基本理解，要理解系统边界、接口关系和协作方式。比如在我们的项目开发中，前端同学如果完全不了解后端接口设计，就很容易出现字段理解不一致、状态同步困难等问题；后端同学如果不了解前端交互流程，也可能设计出虽然逻辑正确但很难使用的接口。即使每个人都有分工，也需要一定程度的跨领域理解来降低沟通成本。

Q2. 结对编程

• 问题：就读到的材料而言，我觉得结对编程有不少的缺点：需要两个人协调配合，比如商议时间，感觉不是很灵活；编程时不全在写代码，也需要查阅文档、学习一些新知识之类的，我觉得两个人在一起看的效率是没有单独思考的效率高。结对编程的优点是可以互相检查，但我觉得这也可以利用代码审查的方式来实现。所以结对编程是否真的有必要（利 vs 弊）？何时使用结对编程模式？
• 回答：结对编程不是一种应该始终使用的开发方式，而是一种适合特定场景的协作手段。它的价值并不只是让两个人一起写代码，而是在问题复杂、风险较高、需要快速统一理解时，通过实时讨论和即时反馈来减少错误和返工。比较适合使用结对编程的场景包括：核心模块设计、疑难 bug 排查、复杂重构、新成员 onboarding、关键接口联调等；而对于重复性强、独立性高、实现路径明确的任务，更适合单人开发加代码审查。代码审查和结对编程也不是互相替代的关系。代码审查偏向事后发现问题，结对编程偏向事中共同理解和即时纠偏。

Q3. 用户需求

• 问题：“用户最需要的 > 用户表达出来的 > 软件团队能理解的 + 团队的商业目标 > 软件团队成员具体表达出来的 (PM 写 Spec) > 在各种约束条件下，具体执行表达出来的 (Dev 写代码) > 验证通过的 (Test) > 通过各种渠道告诉目标用户 (发布 / 推广) > 用户终于能用上了，但是他们不满意。”书中列出了需求传递过程，可以发现需求在层层传递中不断失真，这是否是软件工程的必然现象？有没有什么机制能减少这种信息衰减现象？

• 回答：

  需求在传递过程中发生一定程度的失真几乎是软件工程中的必然现象，但这种失真可以通过机制设计被控制和减少。原因在于，用户真正需要的东西往往并不等于用户直接表达出来的东西。用户可能只能描述自己的痛点，却不一定能准确描述解决方案；PM、开发和测试人员又会根据自己的经验、技术限制和项目目标去理解需求，因此每经过一层转换，就可能丢失一部分信息或加入新的假设。

  减少需求信息衰减的机制，我认为主要有几类。第一是让需求尽量可视化和可验证，比如原型图、交互流程图、用户故事、验收标准等，比单纯文字描述更不容易产生歧义。第二是缩短反馈周期，不要等到最后才让用户或目标使用者看到产品，而应该尽早做原型、Demo 或小版本测试。第三是让团队成员直接接触用户反馈，开发人员不能只看二手需求文档，也应该了解真实用户为什么需要这个功能。第四是建立统一的需求变更记录，避免口头沟通后大家理解不一致。

Q4. MSF 过程模型

• 问题：在大规模团队中，是否可能真正实现阶段节奏统一？现实中需求频繁变更是否使阶段模型失效？
• 回答：结合课程项目来看，虽然我们的团队规模不大，但也能体会到阶段节奏的重要性。如果没有相对明确的时间节点，比如什么时候完成基础功能、什么时候进行联调、什么时候冻结功能、什么时候集中修 bug，项目很容易陷入“大家都在做，但不知道整体进度如何”的状态。但同时，实际开发中又总会出现新需求、新 bug 和临时调整，因此阶段安排不能太死板。因此，我现在认为 MSF 这类过程模型的价值不在于预测一切，而在于帮助团队在不确定性中进行阶段性收敛。阶段模型不会因为需求变化而失效，但如果团队把阶段模型当成不可调整的计划，而不是风险管理和协作同步工具，它就会变得低效甚至失效。

Q5. PM

Program Manager (PM)

1. 负责一个功能的开发/测试人员和相关的 PM 密切合作，再由 PM 代表这一小组去和别的小组或客户代表打交道，大大降低了交流的成本；
2. 有专人负责开发 / 测试之外的许多事务和项目进度的管理，让开发和测试人员专注技术方面的工作；
3. 牛人主导的项目，往往会大起大落；PM 主导的产品中，“不犯大错”成了一个特点。微软的很多产品在长期的竞争中，靠“不犯大错”，从第三版开始，赶上并超越对手，这也是了不起的能力。

• 问题：如果团队规模较小（比如我们的软工小组），是否还需要 PM？另外 PM 没有了解开发的细节，是否反而会增加沟通成本？
• 回答：我认为即使是小团队，也需要有人承担 PM 的职责，但不一定需要设置一个完全独立的 PM 岗位。PM 的核心价值在于帮助团队把模糊目标转化成可以执行、可以检查、可以交付的任务。

新的问题

1. 在 AI 工具逐渐普及的背景下，软件工程中的分工会发生什么变化？工程师是否会更需要需求理解、系统设计、测试验证能力？
2. 课程项目中，我们可以通过同学试玩、老师反馈和组内讨论来调整需求，但真实软件产品面对的用户更复杂，需求也更分散。如何从大量甚至互相矛盾的用户反馈中提炼出真正重要的需求？

各阶段学到的知识点

需求阶段

需求要转化为清晰、可实现、可验收的功能描述。

以团队项目 Paradice 为例，“引导玩家使用道具”一开始只是一个比较模糊的想法，但真正开发时需要明确：什么时候提示、提示给谁、提示持续多久、是否影响玩家操作、是否只提示一次等。如果这些细节没有提前确认，后续实现就容易反复修改。因此，需求阶段的重点不是简单记录想法，而是把模糊需求具体化。

设计阶段

模块之间需要通过清晰的接口协作。

在团队项目中，前端、后端和游戏逻辑需要频繁交互。如果没有提前约定消息格式和字段含义，就很容易出现理解不一致。例如服务端向客户端发送 StateSync、TurnSync，客户端向服务端发送 RollDice、UseItem 等操作请求，本质上就是在定义前后端之间的接口契约。接口设计清楚后，团队成员才能并行开发，联调成本也会降低。

实现阶段

代码不仅要能运行，还要便于他人理解和后续修改。

团队项目中，代码需要被队友阅读、调试和扩展。比如游戏状态机、道具逻辑、Buff 逻辑如果混在一起，后续添加功能就会很困难。因此，实现阶段要注意命名、结构划分和函数职责，让代码保持可读、可维护。

测试阶段

测试用例覆盖要全面。

例如测试一个道具功能时，不能只看点击按钮后程序是否正常运行，还要检查它是否只能在合法阶段使用、目标是否合法、使用后状态是否同步、异常情况是否有提示。通过团队项目的测试，我认识到测试用例应该覆盖正常流程、边界情况和异常情况，才能真正提高软件质量。

发布阶段

开发环境能运行并不代表发布环境也能运行。依赖版本、端口配置、数据库、服务器环境等都可能导致问题。因此，发布时需要清楚说明运行步骤、环境依赖和部署方式。使用 Docker、脚本或文档，可以让项目更容易复现和展示。

维护阶段

项目上线或展示后仍然需要持续修改，因此必须做好版本管理。

团队项目在 Beta 阶段收到反馈后，需要继续修改规则说明、优化道具提示、修复 bug。如果没有 Git 记录和清晰的 commit message，就很难追踪每次修改的原因，也不方便回退问题版本。

课程心得

这学期的软工对我来说是一次很完整的工程实践，我以开发者的身份体验了软件工程中需求、设计、实现、测试、发布、维护等各个环节。我们组开发了 Paradice 派对游戏，我负责动画和 UI，接触到了 Godot / Phaser / Go + Nakama / 像素画，学到很多新知识。

和软工的缘分可以追溯到两年前，当时偶然间读到了学长学姐们的软工博客，挺期待说两年后自己能写个怎么样的软件。一学期下来，在结对编程和团队游戏开发中，涉猎了许多新领域，认识了许多新朋友，也合作得非常愉快，是一段很美好的旅程 (,,>ヮ<,,)!

软工完结撒花！