[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) 请说明单元测试对软件开发的作用。

• 提高代码质量和可靠性，单元测试可以检测和修复代码中的错误和缺陷，从而提高代码的质量和可靠性。通过对每个单元进行独立测试，可以确保代码在不同情况下都能正常运行，减少潜在的错误。
• 改善代码设计，单元测试要求程序员编写可测试的代码，这可以促进代码的模块化和松耦合，从而改善代码的设计和可维护性。这种设计方式使得代码更易于理解和维护

总结

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

3/21 18：30

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

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

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，感受到了结对编程的优势所在。

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	合计