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

项目	内容
这个作业属于哪个课程	2026年春季软件工程（北航计算机学院）
这个作业的要求在哪里	[I.3] 个人作业：结课总结
我在这个课程的目标是	锻炼团队协作开发能力；学习一套完整的项目开发范式；学习完成一个复杂性较高内容较多的完整项目
这个作业在哪个具体方面帮助我实现目标	回顾一学期的学习经历和实践经历，总结收获

提问回顾与个人总结

在经历了这一个学期的软件工程课程，从个人练习到结对编程，再到两个阶段的团队项目实践，我不仅在代码能力上有了提升，更对软件开发背后的流程、逻辑和团队协作有了深刻的理解。

一、 链接到以前提问题的博客

我的软工快速阅读提问博客 - questions.md

二、 提问回顾：从疑惑到释然

问题一：是否存在比代码覆盖率更强的指标？

【解答】：通过后期的实践和调研，我接触到了变异测试（Mutation Testing）和分支/条件路径覆盖（MCDC）。
在我们的结对编程中，我发现即使代码行覆盖到了 100%，如果我没有测试数组为空或数值溢出的边界条件，程序依然会崩溃。我意识到代码覆盖率只是一个“及格线”，而真正的逻辑严密性需要通过等价类划分和边界值分析来保障。

问题二：如何界定“必要文档”与“繁文冗节”？

【解答】：在团队项目的第一阶段，我们为了赶进度减少了架构设计文档，结果在进行功能对接时，开发人员对 API 的理解不一致，导致了大量的重复返工。
实践证明：在敏捷开发中，接口文档（API Spec）、核心类图和部署手册是不可或缺的。它们不是“繁文冗节”，而是团队沟通的“共同协议”。敏捷不代表不设计，而是“适度设计”。

问题三：PM“不做开发”在小团队中是否可行？

【解答】：经过讨论和观察，我发现小团队中的 PM 必须具备技术理解力。
在我们的团队中，PM 虽然写的代码较少，但他负责梳理需求、定义 Backlog 和进行原型测试。我发现，如果 PM 不懂技术，他提出的需求往往会超出 Sprint 的承载能力。PM 在小团队中确实不需要是“主程序员”，但他必须是“技术翻译官”。

问题四：用户体验是可量化的工程学吗？

【解答】：是的，它是感性设计与理性量化的结合。
在实现小地图功能时，我最初认为只要放上去就行，但后来通过观察队友的使用，发现按钮位置不符合费茨定律（Fitts's Law），导致操作极其不便。我认识到，费茨定律等公式提供了设计方向的理论依据，而 A/B 测试则提供了结果的实证。

问题五：关于先发优势的否定是否会误导竞争？

【解答】：书中强调的是“不要盲目追求第一，而忽略了产品质量”。
在我们的项目中，我们由于追求第一个发布 Beta 版，导致 Bug 极多，用户口碑很差。后来在转会环节，我观察到有的团队虽然发布慢，但其核心功能（如数值守恒系统）非常稳健，反而吸引了更多人。这让我明白，“先发”是运营手段，而“后发制人”靠的是产品壁垒。

三、 是否还有不明白的问题？

原来的问题： 我对 “技术债务的自动化度量” 依然感到困惑。
分析： 虽然我们可以通过覆盖率、Lint 工具（静态代码检查）来量化代码质量，但由于软件逻辑的复杂性，很难有一个指标能完美预测“由于现在乱写代码，未来维护会多花多少个小时”。这似乎更依赖于架构师的经验而非工具。

四、 产生的新问题

新问题： 在大规模团队中，如何解决“转会环节”带来的上下文丢失问题？
背景： 在本学期的转会环节，新成员加入后往往需要很长时间才能理解我们之前的 BigObject/SmallObject 架构。
思考： 是否存在一种比文档更高效的“知识传递”方式？比如代码即文档（Self-documenting code）是否真的能承载所有设计意图？

二、 各个阶段的知识点总结

在“做中学”的实践中，我在各个阶段都掌握了核心知识点：

1. 需求（Requirement）：
   • 知识点：用户场景与 User Persona。
   • 理解：在做 NPC 交互系统前，我们必须模拟不同类型的玩家（如成就党、剧情党），从而决定对话框是否需要支持“跳过”功能。
2. 设计（Design）：
   • 知识点：MVC 架构的解耦。
   • 理解：将数值守恒逻辑放在 SmallObjectProperty（Model），将动画逻辑放在 PlayerView（View），将输入逻辑放在 IOSubsystem（Controller）。这保证了我们在修改 UI 时不需要动战斗逻辑。
3. 实现（Implementation）：
   • 知识点：代码重构与防御性编程。
   • 理解：在处理击退效果（Knockback）时，为了防止逻辑帧覆盖物理帧，我学会了使用状态锁（IsHurt），这极大减少了偶发性 Bug。
4. 测试（Testing）：
   • 知识点：回归测试（Regression Testing）。
   • 理解：每当我们给 BigObject 添加新功能后，必须跑一遍旧的“树与门”联动测试，确保因果律系统没有因为新代码而崩溃。
5. 发布（Release）：
   • 知识点：持续集成（CI）与自动化构建。
   • 理解：学会了配置 GitHub Actions，在每次 Push 后自动构建 Unity 的 WebGL 版本，确保护发版本始终可用。
6. 维护（Maintenance）：
   • 知识点：Issue 优先级排序。
   • 理解：在项目收尾阶段，面对大量的 UI 细节 Bug 和一个致命的存档崩溃 Bug，我们学会了根据影响范围和紧急程度进行资源分配。

三、 心得体会

• 个人项目：让我明白了“一个人也要像一支军队”，建立了对代码规范的敬畏。
• 结对编程：最深刻的体会是 “1+1 > 2”。当我在写复杂的数值守恒算法时，队友的即时 Review 帮我避开了至少三个死循环。
• 团队项目：软件工程不是写代码，而是管理复杂度和预期。最难的不是实现功能，而是让 5 个人在两个月的时间里对同一个目标达成共识。

通过这学期的学习，我从一个“写代码的学生”成长为了一个“初步具备工程思维的准开发者”。软件工程不仅是技术，更是平衡、权衡与沟通的艺术。