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

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

项目	内容
这个作业属于哪个课程	2026年春季软件工程
这个作业的要求在哪里	[I.3] 个人作业：结课总结
我在这个课程的目标是	学习现代软件构建的工程方法，锻炼团队协作能力。在团队的共同合作下产出符合流程的高质量软件。
这个作业在哪个具体方面帮助我实现目标	总结在课程中学到的技能和方法

我的阅读提问博客链接： 个人作业：阅读和提问

---

一、对曾经提出问题的解答

问题一：单元测试是否必须由代码作者编写？由其他人来编写是否更好？

• 思考解答： 通过项目的实践，我认识到两者并非只能选其一，而是互有利弊、不可互相替代。在团队项目中，负责shared层和核心计算逻辑的同学编写单元测试，能促使其在编码时考虑边界条件；而在结对编程的T3阶段，我们两个人分别审视并编写测试样例，能起到更好的黑盒测试效果。总的来说，我觉得作者自己写单元测试是为了保证实现符合设计，其他人写测试是为了验证设计符合需求，两者均应存在。

问题二：书中关于“所有时间”的定义是否出现错误？

• 思考解答： 这个问题我在提出的时候就已经通过查阅资料确定了可能是书上的印刷错误或者笔误。

问题三：在AI辅助编程越来越普遍和高效的当下，基础性操作的熟练度要求是否应该适当降低？

• 思考解答： 经过了结对编程和团队项目的实践后，我认为当前基础语法的熟练度要求确实降低了，取而代之的是对于需求分析和架构设计的要求更高了。在结对编程中，我们使用了claude-sonnet辅助，它能迅速写出样板代码，能够直接正确运行；在组队编程当中的绝大多数Bug也可以通过AI来进行修复。但是部分优化方案、游戏设计这种需求性和架构性的东西仍然需要人为进行确定。

问题四：基于结对编程发挥作用的严苛条件和高成本，是否应该认为结对编程对于提高项目质量和效率作用并不大？

• 思考解答： 并不能说结对编程完全没有作用，但是我感觉其效果也并不如刚提出的时候或者教材上提出的作用那么大。确实两个人进行并行编程能够发现一些一个人可能忽略的问题，从而减少返工以及后续审查的时间。但是这部分节省的时间与两个人分开独立开发两部分内容节省的时间其实并不好比较，并且可能两个人独立开发各自的部分带来的效率提升更大。所以我认为结对编程还是更适合那种老带新的场景，用于帮助新手熟悉开发流程与技巧等。

问题五：敏捷冲刺期遇到突发变更是否应该立即响应？

• 思考解答： 我认为应该有选择性地响应。比如在杰后余生的beta阶段，我们收集到了许多试玩反馈，如人数不足无法体验、射手蓄力不清晰等。此时我们的做法是优先修复阻塞性体验问题，即优先修复原定的基础游戏内容中破坏完整体验流程的问题，而对于非核心的新功能、新反馈、新改动则推迟。也就是说对于突发变更，还是要先评估其重要性与核心性，先保证有一个完整可运行的基础内容，在尝试去按照变更进行修改。

问题六：在实际、复杂的项目管理中，有没有更通用的绩效管理和工作量评定准则或方法？

• 思考解答： 在我们的团队项目中制定了一套完整的工作量评估标准，详情可见[T.8] 团队项目：团队贡献分分配规则。大体来说是结合角色责任、任务完成度、跨角色贡献等进行分配。既主观又客观地去进行评定，要看每个人完成的硬工作量指标，但是也要主观去评价每个人完成工作任务的实现难度、设计难度以及个人能力。但是，其实我们仍然觉得自己设计的评分准则不够完美，区分度不算大，不能很好的完成任务贡献划分。

---

二、原来不明白的问题

关于问题六（绩效评定），我虽然在6人小组中找到了相对平衡的给分方式，但我依然存疑：当团队规模扩大到50人甚至数百人时，这种高度依赖互相了解和主观评估的考核方式显然会失效，而纯客观指标又容易导致“内卷”或“面向KPI编程”。在企业级复杂项目中，究竟该如何量化绩效？

---

三、新产生的问题

我们团队的作业是做的游戏，我负责进行测试，最终我也缺乏对Phaser场景的浏览器自动化检查和AI行为的确定性回归测试。当项目状态机极其复杂且高度依赖视觉表现时，低成本、高收益的自动化测试体系究竟该如何搭建？而且这种游戏我感觉都需要自己上手游玩，自动化测试究竟能对游戏进行怎样的质量保证与效果？

---

四、各阶段学到的知识点

• 需求阶段：
  • 知识点：“可观测性”本身就是一种刚性需求。 在团队beta阶段，我们发现缺乏产品运营数据（日活、首局完成率、地图选择分布等），导致很难靠主观讨论来判断好不好玩。需求不能仅仅停留在功能表面，必须在一开始就将数据埋点和事件统计纳入需求范围。
• 设计阶段：
  • 知识点：策略与机制的解耦 & 前后端分层共享。 在结对项目中，我们将解析历史记录的机制代码与选择卡牌的策略代码分离；在团队项目中，我们采用了 client/server/shared 工作空间架构，通过共享层统一定义地图 JSON 和职业配置，极大地减少了前后端字段漂移，提升了系统适应需求变更的能力。
• 实现阶段：
  • 知识点：防御性编程与去硬编码。 在结对项目中，不仅要考虑正常的出牌逻辑，还要处理历史记录中对手盟约和弃牌为'X'的盲区反推。我们发现通过减少代码中的魔法数字，用常量字典统一配置，能让代码在面对未来平衡性调整时更加从容。
• 测试阶段：
  • 知识点：测试前置的重要性（TDD理念）。 结对项目初期我们先写完再补测试导致了一些逻辑错误被掩盖。测试不仅是找Bug的手段，更是验证设计的工具。团队项目中，我们因为缺少端到端的自动化集成测试，导致每次改动AI或地图后都需要巨大的人工回归成本，这让我明白了测试驱动和自动化测试的价值。
• 发布阶段：
  • 知识点：CI/CD自动化流水线。 对于多人在线游戏，服务端的房间逻辑必须和客户端严格一致。我们通过引入GitHub Actions构建Node.js和pnpm的自动化部署脚本，保障了多版本迭代时的发布可靠性。
• 维护阶段：
  • 知识点：变更管理与Issue闭环。 在多线并行开发时，代码合并冲突和需求变更是家常便饭。我学到了把每一次用户反馈变成可复现的Issue用例，并且每次提交都要尽量留下devlog和TODO，保证每个Bug都有“复现-定位-修复-验证”的最小闭环。

---

五、个人项目/结对编程/团队项目的心得体会

个人项目心得体会：在个人项目中，通过阅读书籍以及提问与思考的过程后，我最大的感触是“写代码”和“软件工程”有着本质的区别。以前写作业往往是拿到题目直接上手敲代码，走一步看一步；而根据PSP的观念，在动手前应该先进行需求分析、时间预估和架构设计。一开始实践的时候很不适应，觉得太麻烦了，预估耗时也经常和实际耗时大相径庭，但在后面的团队项目中这种“先设计、后实现、再复审”的习惯让我受益匪浅。

结对编程心得体会：结对开发《花见小路》的经历让我初次体验到了“1+1>2”的协作感觉，以前的作业大多数都是自己做或者分工做，但是两个人同时做同一件事情还是第一次。我和搭档在学习全新的AssemblyScript语言和设计minimax算法策略时，结对模式极大地缓解了面对未知技术的焦虑。结对的本质是高强度的实时代码审查，我们互相充当驾驶员和领航员，不仅有效杜绝了条件遗漏、计算偏差等低级错误，还促使我不断去向对方解释和优化自己的代码逻辑。虽然初期需要沟通磨合，但这种将交流、审查与编码合二为一的敏捷实践，显著提高了代码的下限，也让我学会了如何更好地与他人进行技术协同。

团队项目心得体会：《杰后余生》团队项目是我第一次真正意义上的工程实战。在多人协作中，技术往往不再是唯一的瓶颈，我觉得跨角色的沟通对齐与版本节奏的把控才是最难的。通过这个项目我深刻认识到了良好架构（如前后端shared层类型共享）与自动化部署（CI/CD流水线）的重要性，它们是支撑多线并行开发的基石。同时，面对beta阶段涌入的试玩反馈，我切身体会到了可观测性的价值——判断功能好坏不能仅靠主观臆测，必须依赖用户埋点数据。而在展示前果断冻结新功能、全力修Bug则是保障敏捷交付的核心策略。这次从零到一的完整开发历程，真正为我构建了软件生命周期的全局观。