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

项目	内容
这个作业属于哪个课程	2026年春季软件工程 (北京航空航天大学 - 计算机学院)
这个作业的要求在哪里	[I.3] 个人作业：结课总结
我在这个课程的目标是	学习软件工程相关的基础知识，并在实战中运用这些知识
这个作业在哪个具体方面帮助我实现目标	回顾、总结一学期的软件开发历程与学到的知识

提问回顾与个人总结

一、旧问题博客链接

个人作业：阅读和提问

二、对旧问题的回顾

1. 单元测试是否应完全由代码作者编写？

现在我的理解是：不应该完全由作者独自完成。

代码作者最了解实现细节，适合写基础单元测试；但作者也最容易带着自己的实现假设写测试，遗漏需求误解和边界情况。更合理的方式是：作者负责编写核心测试，其他成员通过代码审查、交叉测试和场景测试补充外部视角。

结对项目中，我们先实现规则判定，再不断补边界测试，才发现“规则顺序”和“平局细分”容易出错。团队项目中，很多 Bug 也来自前端表现、后端规则、测试假设不同步。这说明测试不能只验证“我以为的正确”，还要验证“用户实际会遇到什么”。

2. “过早泛化”和必要架构设计的边界在哪里？

现在我的答案是：先保证核心闭环跑通，再对稳定变化点做抽象。

一开始就设计大而全的平台，容易浪费时间；但完全不设计，也会在迭代中留下技术债。关键不在于“要不要设计”，而在于抽象是否服务于当前明确的变化点。

结对项目中，我们把计分、计数、档位比较拆成辅助函数，这不是过度设计，而是让规则更清晰。团队项目中，Alpha 先完成可玩版本，Beta 再扩展地图、小游戏、音效和结算，也让我理解到：好的架构应该允许逐步演进，而不是一开始就追求完美。

3. RUP 的“重文档”和“迭代”是否矛盾？

我认为不完全矛盾，矛盾的是：文档如果不能跟着变化更新，就会变成负担。

RUP 可以在大阶段上有计划，在阶段内部做迭代。但这要求文档是“活的”，能记录需求、设计、风险和变更，而不是一次写完后放在那里。

团队项目中，功能规格、测试矩阵、新手引导文案有时没有及时同步，导致后期集成和测试压力变大。这让我理解到，文档的价值不在于多，而在于能不能帮助团队对齐。

4. 如何把模糊需求拆成 Sprint 任务？

我的理解是：先从用户场景出发，再拆成有验收标准的小任务。

不能只写“做一个小游戏”“优化结算页面”这种大任务，而要写清楚：谁来做、做什么、做到什么算完成、如何测试。

Beta 阶段任务拆得比 Alpha 更细，任务表中有动画、道具、Bug、测试场景和发布条件等内容。这个过程让我体会到，敏捷不是少写计划，而是让计划足够小、足够可检查。

5. MSF 中的授权是否适合学生团队？

现在我的答案是：授权需要边界，信任不等于放任。

成熟工程师可以更准确地估计时间并主动承担责任，但学生团队经验不足，容易低估任务复杂度。因此组长或 PM 需要做的不是控制每个人，而是帮助团队暴露风险、调整优先级、推动沟通。

团队项目中，我们通过例会、微信群、飞书任务表、GitHub PR 和 CI 管理进度。实践后我感觉，负责人真正要管的是“风险是否被看见”和“问题是否被及时处理”。

三、仍然没有完全弄清楚的问题

我现在仍然不太清楚：在大型真实项目中，如何在“文档足够完整”和“维护成本可接受”之间取得平衡。

课程项目规模有限，很多文档可以靠会议和任务表补救。但企业项目中，人员流动、模块复杂度和维护周期更长，文档同步的难度会更高。这个问题还需要更多真实工程经验才能理解。

四、新产生的问题

1. 对体验类需求，如音效、新手引导、动画反馈，怎样设计可量化的验收标准？
2. 多人联机项目中，弱网、断线重连、并发房间这些问题，应该在什么阶段开始系统测试？
3. 自动化测试如何覆盖 Buff、道具、成就、结算这类组合规则，而不是只测单一场景？

五、六个阶段中学到的知识点

阶段	学到的知识点	我的理解
需求	用户故事与验收标准	需求不能只写功能名，还要写清用户场景和完成标准。
设计	面向变化点抽象	不要为了抽象而抽象，应围绕可能变化的规则、状态和接口做设计。
实现	分支、PR 与 CI	功能写完不等于完成，代码合并前需要审查和自动检查。
测试	场景测试与回归测试	真实 Bug 往往出现在多个模块组合后，不能只测单个函数。
发布	发布准入标准	发布前要检查核心流程、P0/P1 Bug、构建、类型检查和关键场景。
维护	变更可追溯	规则、代码、测试、文档要同步更新，否则后期排查成本很高。

六、结合项目经历的心得

个人作业

个人作业让我意识到，看一个软件不能只看“能不能用”，还要从用户体验、功能完整性、Bug、生态限制等角度分析。软件工程关注的不只是代码，还有需求、用户和质量。

结对编程

结对项目让我体会到，沟通能提升代码质量，但也会带来协调成本。两个人一起讨论规则、拆分函数、补测试时，确实更容易发现问题；但如果时间不好约，效率也会受到影响。

我最大的收获是：规则类程序不要急着写完，应该先把规则顺序理清楚，再用测试覆盖边界情况。

团队项目

团队项目让我真正理解了“集成”的复杂度。单个模块完成不难，难的是前端、后端、测试、文案、音效、部署同时对齐。

Paradice 从 Alpha 到 Beta 的过程说明，软件工程不是把代码写出来就结束了。任务拆分、优先级、测试矩阵、Bug 管理、发布检查、文档同步，都会直接影响最终交付质量。

七、总结

这个学期最大的体会是：软件工程的知识点只有在实践中才会变得具体。

以前我会把单元测试、敏捷、文档、项目管理当成概念；做完结对项目和团队项目后，我发现它们其实都对应着真实问题：怎么少写错代码，怎么减少返工，怎么让团队对齐，怎么保证版本能交付。

“做中学”的意义就在这里：实践会不断暴露问题，而软件工程的方法，就是帮助我们更系统地面对这些问题。