[P] 结对项目：影蛇舞

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

结对项目：博客问题清单

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

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

引入

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

3/21 15：35

调查

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

I. 没有听说过；

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

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

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

I. 没有听说过；

总结

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

3/21 16：09

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

结对过程

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

3/21 16：12

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

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

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

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

• 查阅了Web Assembly 初见文档，了解了如何初始化项目以及as语言的语法
• 先设计了蛇运动的逻辑，再去分析代码实现，完成后进行课程组提供的代码测试，最后自己再编写测试。
• 问题：无

测试

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

• 考虑到一些边界情况，我们设计了果子位置在边上乃至角落的测试点
• 考虑到果子会生成在蛇身后，需要蛇先远离再接近果子的情况，我们设计了果子在蛇尾后面的测试点
  我们设计了多组符合上述情况的测试点，来保证测试的有效性

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

• 便于及时发现错误，在编写一个函数时可以通过单元测试立即检查函数是否正确处理了各种情况
• 减少回归测试时间:在回归测试时，可以重新运行原本的单元测试，来验证修复bug后是否破坏了原有功能
• 提高程序员对自己代码的理解程度，同时鼓励开发人员降低代码复杂度

总结

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

3/21 18：30

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

到这还挺轻松，除了稍微需要了解一下as语言的语法，其他没有碰到什么问题。同时，我也体会到了结对编程的方便之处。

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

结对过程

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

3/26 10：25

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

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

Personal Software Process Stages	个人软件开发流程	预估耗时（分钟）	实际耗时（分钟）
PLANNING	计划	5	5
- Estimate	- 估计这个任务需要多少时间	5	5
DEVELOPMENT	开发	145	175
- Analysis & Design Spec	- 需求分析 & 生成设计规格（确定要实现什么）	10	5
- Technical Background	- 了解技术背景（包括学习新技术）	10	5
- Coding Standard	- 代码规范	5	5
- Design	- 具体设计（确定怎么实现）	20	15
- Coding	- 具体编码	60	100
- 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	合计	160	200

• 因为在这次任务中，需要使用bfs算法，所以需要创建二维数组，我们查阅了二维数组创建和赋值的方法。随后我们使用bfs算法查找出路径，然后按该路径吃到果子后，再bfs去搜索下一颗果子。在开发中，我们遇到了经常会装上障碍物的问题，后面通过编写特殊测试点修正了bug

代码可复用性与需求变更

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

T1中采用贪心算法直接到达目标，而T2中使用BFS算法避障，因此未对T1代码进行复用。

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

• 模块化设计：将复杂的系统拆分成多个独立的模块，让不同的功能交给不同的模块去实现。之后在某个功能出现需求变更时，只需要修改对应模块即可
• 预留接口：可以预留一些未实现的方法接口，方便未来的功能扩展

头脑风暴环节

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

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

• 查找当前场地上是否存在格点，其三面都被障碍包围。记这样的格点数为n。
• 若n=0：

1. 从蛇头初始位置进行bfs寻找最近的果子，找到后记录路径，并更新蛇头位置；
2. 从新蛇头位置继续进行bfs，直至吃完所有果子。

• 若n>0：三面被障碍包围的格点是“死路”。更进一步地，与该格点相邻的两面被障碍包围的格点也是“死路”的一部分，应该在吃掉“死路”外的果子后再进入“死路”。

1. 以三面被障碍包围的格点为起点寻找相邻可达的格点，找到后记录该格点，并更新起点位置；
2. 从新起点位置继续进行寻找相邻可达的格点，直至该格点周围的障碍数小于2；
3. 将刚才寻找到的所有格点视为障碍，进行n=0时的操作，直至吃掉所有果子；
4. 寻找“死路”中的所有果子。由于至少存在一条成功吃掉所有果子的路线，所有“死路”中至多有一个分支有果子。

总结

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

3/26 15：20

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

本次实验出现了bug，领航开发者难以发现的一些bug，被辅助开发者较为轻松的找出。深深体会到了结对编程的好处。

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

结对过程

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

3/26 16：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

在这次任务中，我们询问了gpt，让大模型给出过蛇运动的思路。另外，我们也尝试过去使用深度学习来解决问题。但是对于我们来说学习成本太高，在学习一段时间后我们还是放弃了。
随后我们和之前一样进行了开发，在测试阶段，我们去联系了一些组，得到了他们蛇的样本后，在进行多次对战后分析每组的优势和劣势，去取长补短，不断进行迭代开发。

需求建模和算法设计

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

将蛇的第二节、其他蛇的前三节当作障碍物；其他蛇蛇头周围三格视为潜在障碍物，该问题即等价于T2——在有障碍的棋盘上寻找可达果子的问题。
由于T3需要在尽可能少的轮数获得高得分，需要考虑所有可达果子的最短路径，我们选择了bfs算法；考虑到1v1模式下双蛇相杀即导致游戏结束，而4蛇对战需要保证存活率从而获得更高得分，可以在1v1模式下采取更激进的策略，即减少对潜在障碍物的判定。

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

怎么避免死亡：

• 将本蛇的第二节、其他蛇的前三节当作障碍物，是必然不能走的方向；
• 将其他蛇的第一节周围的点当作危险点，是潜在的障碍物，除非其他无路可走才选该方向；
• 蛇在沿墙前进时，若有蛇在距墙一格的位置与本蛇平行前进，则我们的蛇有在角落无路可走的情况，因此在决策时，尽量避免蛇的贴墙移动。
  怎么吃到更多果子：
• 在1v1对战中，以激进策略为主，每次朝当前距离最短的果子前进，如果两蛇同时出现在一个果子两侧，则选择吃掉果子。如果发生对撞，也会因为先前的贪心策略获得更高分数。
• 在4蛇对战中，以保证存活为主，不会争抢两蛇中间的果子。
  编程实现：
• 使用二维数组储存棋盘状态，每个格点有空、障碍、潜在障碍、食物四种状态。每次进行一次bfs决定目标果子，并向其方向前进；
• 如果任何果子均不可达，则走向周围空格；若周围无空格，则走向周围潜在障碍；
• 为了减少在角落被击杀的情况，检测蛇是否在贴墙移动，如果蛇在贴墙移动且下一个目标果子不在该墙边，则立即远离墙。

软件度量

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

为了选择是否使用某些优化策略，我们生成了多条使用不同优化策略的蛇进行对战，并进行自动化测试进行1000局游戏。统计所有游戏结果中每条蛇的死亡率、平均得分从而判断哪种优化策略更加合理。在对弈能力方面，我们获取了其他小组的蛇函数并进行类似测试。最终死亡率和平均得分均达到较好水平，可以说明我们的程序具有不错的对弈能力。

总结

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

4/2 18：12

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

哎呦我，想个优化方法怎么这么难呢？有时候加了经过复杂思考得出的优化方案，性能却反而不如原本的版本。还有结对编程集思广益，确实对开发大有裨益。结对编程牛啤！

结对项目总结

结对过程回顾和反思

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

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

• 在结对编程时，因为我们很少找到较长的共同空闲时间，所以导致我们的开发过程非常碎片化，难以有对算法的深度思考。
• 队伍两人的代码风格不同，导致互相理解代码难度较大。可以在开发前约定好代码风格，方面理解

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

优点：

• 非常肯承担责任，主动担其领航开发的任务
• 聪明，想出了很多靠谱的优化方案
• 有耐心，出现bug后修复了很久依旧没放弃

缺点：

• 过于精益求精，反而会降低效率

对结对编程的理解

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

优点

• 可以即时进行代码审查，领航开发者在编写代码时，辅助开发者可以即使检查代码是否存在问题，而且也更容易发现问题
• 促进知识共享。在开发过程中，双方都可以分享自己独到的经验，向对方传授自己掌握的技术，有利于提高整个团队的开发水平
• 提高解决问题能力，两人一起思考问题，集思广益，还可以从不同角度分析问题，有助于更快的找到问题的解决方案
• 提高团队成员沟通能力与协作能力

缺点：

• 可能会降低效率，一个人开发只需要按照自己的想法执行，但是结对编程时，双方可能对某些点产生分歧，需要花费时间去沟通协商，如果不能妥善处理，可能导致项目进度停滞
• 初期磨合难度大，不同开发人员有不同的代码风格、工作节奏等，结对编程需要双方去适应对方，如果双方水平差异大、性格难以相容，会花费大量时间去适应

对结对编程的理解：

• 结对编程时一种团队合作的开发方式，强调两个人共同完成一个编程任务。这种模式不仅仅是简单的分工合作，而是要求两位程序员在思想和行动上高度统一，需要共同讨论问题、共同设计解决方案、共同编写代码。
• 结对编程需要双方能够进行良好的沟通与协作，开发者能够认真接受并尊重对方的想法，也要能够清晰地表达自己的观点。如果能够做到这些，会大大提高代码的质量。
• 但是结对编程不是适用于所有的开发任务，它更适合于一些复杂、关键或者需要高质量保证的任务。

代码实现提交

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

https://gitcode.com/pink_f/BUAASE2025-PairProgramming_5889

附录

附录A：基于 PSP 2.1 修改的 PSP 表格

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