[P] 结对项目 ：影蛇舞

结对项目：博客问题清单

项目	内容
这个作业属于哪个课程	2025年春季软件工程（罗杰、任健）
这个作业的要求在哪里	[P] 结对项目：影蛇舞
我在这个课程的目标是	学习软件工程的思想和方法，进行软件开发的实践
这个作业在哪个具体方面帮助我实现目标	通过二人合作的方式体验结对编程，提高合作和沟通能力

请将本文件在代码仓库外复制一份，一边阅读和完成结对项目、一边填写入代码仓库外的版本，或采取简记、语音备忘等方式记载较复杂问题的要点之后再补充。请不要将本文档内的作答提交到代码仓库。

Chapter.0 Belua multorum es capitums.（你是多首的怪物。）

引入

→ 📖 Q0.1(P) 请记录下目前的时间。

3/28 16:50

调查

→ 📖 Q0.2(I) 作为本项目的调查：请如实标注在开始项目之前对 Wasm 的熟悉程度分级，可以的话请细化具体的情况。

I. 没有听说过；

II. 仅限于听说过相关名词；

III. 听说过，且有一定了解；

IV. 听说过，且使用 Wasm 实际进行过开发（即便是玩具项目的开发）。

I. 没有听说过；

总结

→ 📖 Q0.3(P) 请记录下目前的时间。

3/28 16:50

Chapter.1 不畏迷茫，只管前进。（迷子でもいい、前へ進め。）

结对过程

→ 📖 Q1.1(P) 请记录下目前的时间。

3/28 16：50

→ 📖 Q1.2(P) 请在完成任务的同时记录，并在完成任务后整理完善：

1. 浏览任务要求，参照 附录A：基于 PSP 2.1 修改的 PSP 表格，估计任务预计耗时；

Personal Software Process Stages	个人软件开发流程	预估耗时（分钟）	实际耗时（分钟）
PLANNING	计划	10	5
- Estimate	- 估计这个任务需要多少时间	10	5
DEVELOPMENT	开发	85	113
- Analysis & Design Spec	- 需求分析 & 生成设计规格（确定要实现什么）	5	5
- Technical Background	- 了解技术背景（包括学习新技术）	20	40
- Coding Standard	- 代码规范	5	0
- Design	- 具体设计（确定怎么实现）	10	3
- Coding	- 具体编码	20	15
- Code Review	- 代码复审	5	25
- Test Design	- 测试设计（确定怎么测，比如要测试哪些情景、设计哪些种类的测试用例）	5	5
- Test Implement	- 测试实现（设计/生成具体的测试用例、编码实现测试）	15	15
REPORTING	报告	20	20
- Quality Report	- 质量报告（评估设计、实现、测试的有效性）	5	5
- Size Measurement	- 计算工作量	5	5
- Postmortem & Process Improvement Plan	- 事后总结和过程改进计划（总结过程中的问题和改进点）	10	10
TOTAL	合计	115	138

1. 完成编程任务期间，依次做了什么（比如查阅了什么资料，随后如何进行了开发，遇到了什么问题，又通过什么方式解决）；

• 查阅了Web Assembly 初见文档，了解了如何初始化项目以及as语言的语法。
• 学习了AssemblyScript语言（是的，我们都没有用过JavaScript）。
• 在写代码上，由于AssemblyScript语言不熟悉，因此先使用了C++进行代码初步构建。
• 一提到在图中查找路径，我们第一反应是想到bfs，飞快搭建了一个bfs搜索框架。后期将C++代码经过测试后改成了AssemblyScript。
• 问题：在配置AssemblyScript运行环境时尝试了很久，有一种深深的无力感（不知道怎么de啊）所幸最后弄出来了。

测试

→ 📖 Q1.3(P) 请说明针对该任务，你们设计和实现测试的方法及过程，包括但不限于：出于对需求的哪些考虑设计了哪些测试用例、如何评估所设计测试的有效性 等等。

• 这步测试较为简单，我们主要测试了果子在边角的情况。

→ 📖 Q1.4(I) 请说明单元测试对软件开发的作用。

• 即时反馈：在代码编写阶段就能快速发现逻辑错误或边界条件问题，避免缺陷累积到后期。越早发现的缺陷修复成本越低（相比集成测试或生产环境才发现的问题）

• 提升代码质量：迫使开发者编写可测试的代码，自然促进高内聚、低耦合的设计。后续修改代码时，单元测试能快速验证原有功能是否被破坏。

总结

→ 📖 Q1.5(P) 请记录下目前的时间，并根据实际情况填写 附录A：基于 PSP 2.1 修改的 PSP 表格 的“实际耗时”栏目。

3/28 21:02

→ 📖 Q1.6(I) 请写下本部分的心得体会。

这部分了解了wasm的基本知识，学习了AssemblyScript的基本语法，初次体会到两个人合作编程的过程。

Chapter.2 即使迷茫，也要前行。（迷子でもいい、迷子でも進め。）

结对过程

→ 📖 Q2.1(P) 请记录下目前的时间。

3/28 22:40

→ 📖 Q2.2(P) 请在完成任务的同时记录，并在完成任务后整理完善：

1. 浏览任务要求，参照 附录A：基于 PSP 2.1 修改的 PSP 表格，估计任务预计耗时；
2. 完成编程任务期间，依次做了什么（比如查阅了什么资料，随后如何进行了开发，遇到了什么问题，又通过什么方式解决）；

Personal Software Process Stages	个人软件开发流程	预估耗时（分钟）	实际耗时（分钟）
PLANNING	计划	3	3
- Estimate	- 估计这个任务需要多少时间	3	3
DEVELOPMENT	开发	145	65
- Analysis & Design Spec	- 需求分析 & 生成设计规格（确定要实现什么）	10	5
- Technical Background	- 了解技术背景（包括学习新技术）	10	0
- Coding Standard	- 代码规范	5	0
- Design	- 具体设计（确定怎么实现）	20	5
- Coding	- 具体编码	20	10
- Code Review	- 代码复审	10	10
- Test Design	- 测试设计（确定怎么测，比如要测试哪些情景、设计哪些种类的测试用例）	10	10
- Test Implement	- 测试实现（设计/生成具体的测试用例、编码实现测试）	20	25
REPORTING	报告	30	20
- Quality Report	- 质量报告（评估设计、实现、测试的有效性）	10	5
- Size Measurement	- 计算工作量	5	5
- Postmortem & Process Improvement Plan	- 事后总结和过程改进计划（总结过程中的问题和改进点）	15	10
TOTAL	合计	158	88

• 由于T1代码已经写了BFS，我们直接使用了T1代码，只向其中添加了障碍物。
• 但AssemblyScript的二维数组定义有些奇怪，我们出现了好多次的越界问题，de出来之后也莫名奇妙不知道怎么de出来的。

代码可复用性与需求变更

→ 📖 Q2.3(P) 请说明针对该任务，你们对 🧑‍💻 T1 中已实现的代码进行了哪些复用和修改。

几乎是完全使用了T1代码。仅仅修改了障碍物部分。

→ 📖 Q2.4(I) 请说明在编码实现时，可以采取哪些设计思想、考虑哪些设计冗余，来提高既存代码适应需求变更的能力。

• 数据与配置分离：将可能变化的参数（如阈值、规则）外置为配置文件或数据库表。
• 过度抽象的风险平衡：对明确不会变更的部分避免过度抽象，而对可能扩展的部分预留抽象层。

头脑风暴环节

**→ 📖 Q2.5(P) **只吃一个食物可满足不了贪吃蛇的欲望，请一起思考并简述以下场景中贪吃蛇的策略：

在 🧑‍💻 T2 的基础上，场地里不再是只有 1 个果子，而是总共有 n 个果子 (1 < n < 10 )，果子随机分布在场地中且不会刷新，保证不与障碍物重叠，保证每个果子均可达，且至少存在一条成功吃掉所有果子的路线，其余条件保持不变，请你找出一条吃完所有果子的行动路径。

• 维护障碍队列Q：查找当前场地上是否存在格点，其三面都被障碍包围。将这样的点加入Q中。
• 遍历Q：将Q头弹出，判断Q头是否是三面被障碍包裹的点，如果是，则将Q头所对应的点在地图上标注为“障碍阴影点”。“障碍阴影点”属于不能走的点。同时将“障碍阴影点”四周的队列push到队尾。
• 执行上述行为，直至队列为空。
• 对图进行搜索，遍历当前图中所有能走到的果子。遍历后执行下面的步骤：
• 假如存在一个果子，它不属于“障碍阴影点”，并且也无法被遍历到，则该果子必然是无法到达的果子。
• 假如存在属于“障碍阴影点”里的果子，则现在开始对“障碍阴影点”里的果子进行bfs。由于“障碍阴影点”必是死路，也就是说只能吃掉一条死路里的果子。
• 如果还剩余“障碍阴影点”里的果子，说明存在第二条死路，这条死路里的果子无法吃到。
• 如果不剩余“障碍阴影点”里的果子，说明只存在一条死路，可以遍历到所有的果子。

总结

→ 📖 Q2.6(P) 请记录下目前的时间，并根据实际情况填写 附录A：基于 PSP 2.1 修改的 PSP 表格 的“实际耗时”栏目。

3/29 00:08

→ 📖 Q2.7(I) 请写下本部分的心得体会。

基本上没遇到什么困难，但双人合作很爽，两个人可以一起思考。

Chapter.3 这就是我的前进、到我出场了！！！！！（It's MyGO!!!!!）

结对过程

→ 📖 Q3.1(P) 请记录下目前的时间。

4/4 14：00

→ 📖 Q3.2(P) 请在完成任务的同时记录，并在完成任务后整理完善：

1. 浏览任务要求，参照 附录A：基于 PSP 2.1 修改的 PSP 表格，估计任务预计耗时；
2. 完成编程任务期间，依次做了什么（比如查阅了什么资料，随后如何进行了开发，遇到了什么问题，又通过什么方式解决）；

Personal Software Process Stages	个人软件开发流程	预估耗时（分钟）	实际耗时（分钟）
PLANNING	计划	10	5
- Estimate	- 估计这个任务需要多少时间	10	5
DEVELOPMENT	开发	210	305
- Analysis & Design Spec	- 需求分析 & 生成设计规格（确定要实现什么）	5	5
- Technical Background	- 了解技术背景（包括学习新技术）	5	5
- Coding Standard	- 代码规范	5	5
- Design	- 具体设计（确定怎么实现）	20	30
- Coding	- 具体编码	120	200
- Code Review	- 代码复审	20	20
- Test Design	- 测试设计（确定怎么测，比如要测试哪些情景、设计哪些种类的测试用例）	10	10
- Test Implement	- 测试实现（设计/生成具体的测试用例、编码实现测试）	25	30
REPORTING	报告	20	20
- Quality Report	- 质量报告（评估设计、实现、测试的有效性）	5	5
- Size Measurement	- 计算工作量	5	5
- Postmortem & Process Improvement Plan	- 事后总结和过程改进计划（总结过程中的问题和改进点）	10	10
TOTAL	合计	240	330

我们一共建了两次模。第一次建模采取TN*算法，最后因为时间复杂度过高而不得不重构；第二次采用TN-Value算法，在调参时耗费了很多工作量。

需求建模和算法设计

→ 📖 Q3.3(P) 请说明你们如何建模这一需求。

我们使用了TN_Value算法，计算每个格子的Value。Value越大表示这个格子越适合走。影响value的因素有：

1. 蛇惩罚：包含蛇目标惩罚与蛇身惩罚。

   • 蛇目标惩罚（Snake_target）：其它蛇有可能前往的位置离当前格子越远，当前格子越好。
   • 蛇身惩罚(Snake_body)：其它蛇的身体离当前格子越远，当前格子越好。

2. 果子奖励：有三个影响因素

   • 果目标惩罚：果子离其它蛇头的距离越远，果子对当前格子的奖励越大；

   • 果中心奖励：果子离中心越近，果子对当前格子的奖励越大；

   • 果距离奖励：果子离我的蛇头的距离越近，果子对当前格子的奖励越大。

     注意，上面三个式在一个乘式中，共同决定当前果子的Value。

3. 中心奖励：当前格子距离中心越近，格子越好。

→ 📖 Q3.4(P) 请说明针对该任务，你们采取了哪些策略来优化决策。具体而言，怎么避免死亡？怎么吃到更多果子？如何编程实现。

怎么避免死亡：

• 对于每一步的调参，我们都进行了一定程度的优化：
  • 蛇目标惩罚：
    • 对于每条蛇来说，能前往的位置有三个，该蛇到达这三个位置的可能性相同，因此对当前格子的影响相同。
    • 但是，假如对于该蛇而言，这三个位置中有一个位置是不能走的，也即该蛇到达其他两个位置的可能性将上升。
    • 因此，我们引入了蛇生命系数，该系数记录当前蛇的可选格子数量，相应调整每个选择的位置的影响力。
  • 蛇身惩罚：
    • 每条蛇的身体会对当前格子产生影响。
    • 但是，身体的不同节的影响应当不同：越靠近头的部分，说明在接下来的几个回合中，该部分仍有蛇身体的可能性越大；而越接近尾巴的地方，在接下来的几个回合中，该部分的有蛇身体的可能性小。
    • 因此，这里使用了蛇身系数，该系数让蛇身靠近头部的地方权重更大，靠近尾部的权重更小
  • 中心奖励：对于距离的判断，越靠近中心分数越大，但是在靠近中心的地方分数差别不大。而在边角的地方，越靠近边角，分数衰减越快。因此我们将其归一化到指数函数计算公式中。

软件度量

→ 📖 Q3.5(P) 请说明你们如何量度所实现的程序模块的有效性，例如：“如何说明我们的程序模块对弈能力很强？”尝试提出一些可能的定量分析方式。

我们选取了其他组的蛇进行运算。我们发现，对于中等智能的蛇（比如只有简单策略的bfs），我们往往会有更优的分数。但是对一些低智能蛇，我们的蛇常常会被别人一头撞死（）。因此在4V4中，一旦对面有奋不顾身的蛇蛇，我们很容易开局被撞死，随后分数极低，输掉比赛。

总结

→ 📖 Q3.6(P) 请记录下目前的时间，并根据实际情况填写 附录A：基于 PSP 2.1 修改的 PSP 表格 的“实际耗时”栏目。

4/6 22：12

→ 📖 Q3.7(I) 请写下本部分的心得体会。

这部分面对了多种优化方法的抉择，最终经过实际的大量测试选出了合适的方法。我们在TN*算法上浪费了大量的时间，导致最后做的很破防，不得不在最后换策略。但总的来说，在这个过程中收获了不少的快乐。有个队友比自己开发快乐太多了。

结对项目总结

结对过程回顾和反思

→ 📖 Q4.1(P) 提供两人在讨论的结对图像资料。

→ 📖 Q4.2(P) 回顾结对的过程，反思有哪些可以提升和改进的地方。

• 我们两个结对最大的优势就是在同一个宿舍，可以有很多的大块时间讨论。
• 但是在错误的算法中浪费了大量时间。我们应该在开始时候就及时止损，而不是一条路走到黑。我们在复盘中认为，我们应该在模型构建初期，多思考全局可能性，在构建之前先考虑算法的实现可能和复杂性。

→ 📖 Q4.3(I) 锐评一下你的搭档！并请至少列出三个优点和一个缺点。

优点：

• 情绪能力相当稳定，每当我破防的时候都能稳下来。
• 推公式能力相当优秀，推出让我猪脑过载的公式。

缺点：

• 她好香，干扰我思考。

对结对编程的理解

→ 📖 Q4.4(I) 说明结对编程的优缺点、你对结对编程的理解。

优点

1. 代码质量更高
   • 实时代码审查能减少错误，避免低级bug，代码可读性和设计更优。
   • 领航员从全局视角思考，避免驾驶员陷入细节陷阱。
2. 知识共享与技能提升
   • 经验较少的开发者能快速学习技术、工具或设计模式。
   • 资深开发者通过讲解巩固知识，同时可能获得新视角。
3. 减少上下文切换成本
   • 两人共同维护同一段代码的逻辑，避免单人开发时因任务切换导致的思维断层。
4. 更高的专注度
   • 两人互相监督，减少分心（是的，说的就是刷手机），尤其适合复杂或枯燥的任务。

缺点：

• 性格或风格冲突
  • 若两人技术水平、沟通方式差异大，可能导致效率低下（如一方过于强势或消极）。
  • 需要双方具备开放心态和耐心。
• 疲劳感
  • 高强度结对可能导致精神疲劳。由于两个人的高强度沟通使得需要不停地了解别人思路，会更容易疲惫。

对结对编程的理解：

• 结对编程是一种强大的开发实践，能够显著提高代码质量、增强解决问题的能力，并提升团队协作能力。然而，它也有其缺点，如沟通压力等问题。因此，是否采用结对编程需要根据具体的项目需求、团队规模和成员特点来综合考虑。在实际应用中，可以通过合理安排结对人员、优化工作环境和加强沟通技巧培训等方式，最大限度地发挥结对编程的优势，同时减少其带来的负面影响。

代码实现提交

→ 📖 Q4.5(P) 请提供你们完成代码实现的代码仓库链接。

https://github.com/lilyCuZn/BUAASE2025_PairProgramming ######