[P] 结对项目：影蛇舞

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

引入

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

31/03/2025 19:30

调查

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

I. 没有听说过；

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

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

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

I. 没有听说过，第一次接触WASM。

总结

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

31/03/2025 20:29

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

结对过程

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

31/03/2025 20:33
配了一个半小时环境，燃尽了
再启动时间：04/04/2025 16:10

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

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

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

估计任务耗时

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

---

任务记录
首先花了很长时间折腾环境，探索如何跑Rust。过程中最大的问题是构建不了，查找群聊后修改了代理配置，还是不行，最后选择改成手动下载。
第一次修改代码时发现新增的代码不生效，查询大量资料后，手动删除了.cargo目录下的registry似乎就解决了（也可能并不需要删除这个）

实际编写较为顺利，对Rust语法不熟练的地方借助LLM辅助编写。

---

设计思路：

• 先确定蛇身体方向，四个方向排除一个。
• 在剩下的三个方向中fake move获取新坐标，判断是否撞墙或者撞到自己，借此筛选出可以移动的方向。
• 在可以移动的方向中选择举例果子最近的方向。

测试

测试

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

为了测试是否能正确运行，编写了两个简单测试样例。
然后考虑到容易相撞的情况进行特殊情况的样例编写。

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

1.单元测试首先可以自测检查代码的运行情况，便于做出相应的修改和补充。
2.如果代码发生问题或者需要优化时，单元测试可以验证新的修改是否正确，能否保持正确运行。
3.单元测试可以协助团队理解代码，便于结对开发时理解编写者代码。

总结

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

04/04/2025 17:07

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

在T1时，最大的难点在于rust环境的配置和如何按照课程组要求进行测试，代码和测试本身的编写难度不大

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

结对过程

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

04/04/2025 17:07

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

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

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

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

一开始试图在之前的代码基础上增加“果实是否可达”的检查，其他不变。然而这样的结果是蛇蛇容易一直安全地绕圈。
试图记录蛇蛇走过的地块，不让他多次经过同一个地块。然而实现的函数是一步步调用，如果要增加一个静态的记录容器略显奇怪，因此这个方案被废除掉了。
退回到之前的版本，试图在有多个安全方向的情况下随机选择一个方向，进而破除循环，但是也是治标不治本，未采用。
最后选择修改BFS的方法，不止用于可达性检测，还返回这条可行的路径。然后吩咐蛇蛇沿着这个可行的路径行走。虽然不一定是最近的路径，但T2也没有追求性能，所以直接采用了这个方案。

代码可复用性与需求变更

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

一开始进行了大批量的复用，但是在迭代过程中已经修改得和最初的两模两样了，最终只是在局部（如碰撞检测、方向选择）等进行了少量代码复用。

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

模块化设计：将系统划分为独立的模块，每个模块只负责单一的功能。模块之间通过明确的接口进行交互。当需求变更时，只需要修改相关模块，而不需要改动整个系统。

接口优先：优先设计接口，而不是直接实现具体功能。接口定义了功能契约，需求变更时可以通过实现新的接口来扩展功能。

接口冗余：在设计接口时，预留一些未使用的参数或方法，以便未来扩展。需求变更时，可以直接使用预留的接口，而不需要重新设计。

异常处理冗余：在代码中添加额外的异常处理逻辑，以应对未预见的错误。需求变更时，即使引入了新的异常，系统也能更好地处理。

缓存机制冗余：在系统中引入缓存机制，即使当前需求不需要缓存，也可以为未来优化性能预留空间。当需求变更需要优化性能时，可以直接启用缓存。

头脑风暴环节

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

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

​ 初始获取所有果子的位置，计算贪吃蛇当前位置到每个果子的最短路径。构建果子之间的距离矩阵。随后找到果子的访问顺序，规划从贪吃蛇当前位置到第一个果子的路径。每次贪吃蛇吃掉一个果子后，更新状态，重新计算剩余果子之间的最短路径，并调整访问顺序，确保路径不会导致贪吃蛇撞到自己或障碍物。

总结

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

04/04/2025 17:07

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

有了第一部分和基础，第二部分还是蛮快的，主要调整了一下算法，免得蛇蛇无法回头。

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

结对过程

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

04/06/2025 8:30

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

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

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

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

需求建模和算法设计

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

思路大致沿用T2，将场上其他蛇蛇视为障碍物。我们的蛇蛇目标是在不死的情况下，努力往最近的果子的方向走。

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

首先，由于其他蛇的位置直接影响我们的寻路，我们重新规划了“障碍物”的区域。考虑到其他蛇蛇也会移动，因此其他蛇的蛇尾并不用视为障碍物。然而，其他的蛇蛇盘起来的情况下，如果他选择往蛇尾移动，我们可能会直接撞上。我们最终考虑把其他蛇拆成蛇头、蛇头周围四格、第二节身体（第一节算在蛇头周围四格里），不让我们的蛇走到这些地方。重新规划后蛇蛇不那么容易暴毙了，而且有时候可以钻别蛇的蛇尾！
另外，我们还考虑到有时候蛇蛇到别的果子的路会被堵死，但是蛇蛇可以通过绕圈来苟活一段时间，直到其他的蛇走掉或者死掉，然后再进行移动。
果子的寻路采用简单的贪心算法，计算路径最短的果子然后出发。

软件度量

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

由于蛇死不能复活，因此我们优先考虑蛇的生存能力，其次是获取果子的数量。具体而言，我们考虑了蛇蛇的生存能力（存活回合数或步数），果子获取能力（在都存活的情况下是否获取最多）。

总结

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

04/06/2025 11：41

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

难度很大，只是简单进行设计，感觉还是有可以优化的地方

结对项目总结

结对过程回顾和反思

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

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

​ 应该第一周了解一下as和rust的相关环境，这样就不会在开始时浪费很多时间在配环境和尝试运行测试上了。

​ 到第三次时有很多思路当时没有记录，应该在讨论时直接填写到表格里。

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

优点：代码能力强，主动沟通，对时间的把控很准确。
缺点：由于客观原因，没法大规模集中编程，可恶的方法论！

对结对编程的理解

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

优点：一个人指导一个人编码的模式十分明确，两个人的合作可以更好地完成项目，同时学习新东西会更快。
缺点：如果两人配合不当会降低效率。

代码实现提交

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

https://github.com/Carbon231/Snake-PP

附录

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