[P] 结对项目：影蛇舞

项目	内容
这个作业属于哪个课程	2025年春季软件工程（罗杰、任健）
这个作业的要求在哪里	[P] 结对项目：影蛇舞
我在这个课程的目标是	学习软件工程的基础知识，了解软件开发的基本流程，开发出一款受人欢迎的软件
这个作业在哪个具体方面帮助我实现目标	了解结对编程的基本流程，提高代码能力

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

引入

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

4月3日13：01

调查

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

I. 没有听说过；

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

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

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

I. 没有听说过

总结

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

4月3日13：30

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

结对过程

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

4月3日13：31

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

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

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

在整个编程流程中，我们首先查阅了Rust官方手册，对Rust语法有了一定的了解，然后进行了开发。由于第一题任务较为简单，在整体设计方面我们并未遇到问题，最大的问题是初次接触Rust导致的对语法的不熟悉，这些问题都可以通过阅读官方手册解决。

测试

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

• 测试目标：确保所实现函数在不同棋盘状态下能正确返回 0、1、2、3 之一的合法方向，同时检验检验算法在极端情况下(如封闭空间、果子在角落等)的表现。
• 测试用例设计：
  • 基本功能部分：涉及到大多数情况，包括果子在蛇的正前方，左前方，左后方等普通位置，可以用随机生成的策略来实现。
  • 特殊测试点部分：考虑一些极端情况，例如到果子的最短路径被蛇的身体阻挡，果子在边界等情况。
• 测试评估标准：
  • 所有测试结果中，蛇不会死亡，且能在200回合内吃到果子。
  • 算法执行时间不超过500ms。

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

1. 提高代码质量：单元测试能够帮助开发者发现代码中的错误，使代码更加可靠。
2. 提高工作效率：单元测试可以在开发早期阶段发现问题，避免Bug传播到后续的开发和测试环节，减少了后期调试的工作量，提高开发效率。
3. 确保代码的可维护性和可重用性：有单元测试的代码更容易进行修改和重构，因为测试可以帮助验证代码修改后仍然保持原有功能不变，这降低了对旧代码进行更改时引入新Bug的风险，提高了代码的长期可维护性。

总结

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

4月3日14：42，实际耗时见Q1.2。

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

在本次任务中，我们不仅设计并实现了控制蛇行动的函数，还通过单元测试评估了其正确性和执行效率。通过这次任务，我对如何构造测试用例有了更深的了解，也充分认识到了单元测试的重要性。

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

结对过程

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

4月3日14：50

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

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

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

在完成编程任务时，我们先查阅了搜索最短路径的相关算法，考虑到场地特征，我们决定采用BFS策略。在实现时，难点在于如何将BFS转化为我们并不熟悉的rust代码，不过通过查阅官方手册，我们最终克服了这一难点。

代码可复用性与需求变更

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

本次任务相较于上次任务做出了较大的修改，采用了完全不同的策略：

• 在T1中，由于不存在障碍物，蛇头一定可以到达果子，且最短路径长度可以直接计算出来。因此可以采用贪心策略，检查蛇头的四个相邻位置，如果到果子的最短路径长度最小且不与身体重合，则向这一方向移动。
• 在T2中，由于障碍物的存在，我们采用了BFS的思路，从蛇头位置开始BFS，直到搜索到一条到达果子的最短路径，或者发现果子不可达。

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

设计思想：

• 模块化设计：将代码拆分成独立的、可复用的模块，而不是写成一个大函数，例如本次任务中的路径搜索模块，碰撞检测模块。
• 面向对象思想：用类封装对象，提高可扩展性。
• 避免硬编码：尽量使用枚举类型，避免直接使用magic number。

设计冗余：

• 预留未来扩展接口：预测未来可能新增的功能，保留相关接口。
• 兼容不同输入格式：匹配不同的输入模式，并统一进行转换。

头脑风暴环节

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

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

考虑到果子数目小于10，因此可以分别判断果子之间的可达性，将其转换为无向图G。然后寻找蛇可以到达的果子，以这一点为起点搜索无向图G中的哈密顿路径，如果找到则说明找到了一条可以吃完所有果子的行动路径。

总结

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

3月29日17：09，实际耗时见Q2.2

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

在第二次任务中，我们需要在原有的代码基础上，加入障碍物判定和路径搜索功能。在这次任务中，我深刻体会到良好代码设计的重要性，例如对代码进行模块化设计，采用合理的算法。同时，在迭代开发的过程中，我认识到需要保持代码的可扩展性。

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

结对过程

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

4月5日13：43

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

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

任务耗时：

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

在完成本次任务时，我们首先阅读了任务描述，明确了需求与关键点，然后我们搜索了其他更优秀的寻路算法与对抗策略，然后确定了蛇的两种前进策略并将其转化为代码，最后让不同策略进行对抗并优化得到最终结果

需求建模和算法设计

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

需求建模：给定场地，果子的位置，其他蛇的位置，需要保证自己的蛇能检索到最近可以到达的果子，并避免与其他蛇相撞。同时在不存在可到达果子时，需要控制蛇向安全位置移动。

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

我们首先考虑了两种可行的策略并加以实现，然后筛选出更优秀的策略。
策略一：

• 利用A*算法搜索最近的可达果子，并向果子移动
• 如果不存在可达果子，则向一个安全位置移动
  策略二：
• 对四个方向进行评分，细则如下:
  • 在** 不考虑 **其他蛇的情况下，越靠近最近的果子，评分越高，若吃到果子，获得极高的加分
  • 移动之后，远离其他蛇加分，过于靠近其他蛇扣分。
  • 为避免被包围，移动之后，下次移动可选方向越多，评分越高。
  • 离边缘越远，分数越低。
• 对于与其他蛇抢果子的情况，我们先进行躲避，并将这一方向移入待考虑方向。
• 选择分数最高的方向移动，如果不存在，则从待考虑方向中选择分数最高的方向。

经过反复比较，我们发现策略二在大多数情况下有更优秀的表现

软件度量

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

让不同策略互相对战，统计以下指标：

指标	定义	解释
存活回合数	蛇在游戏中的存活回合数	存活时间越长，说明策略越稳健
平均得分	每局游戏最终吃到的果子数	高得分表示能够有效获取果子
果子采集速率	得分 / 存活回合	代表每回合的得分效率

总结

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

4月5日17：45，实际时间见Q3.2

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

本次任务比前两次复杂得多，在本次任务中，我对如何分析用户需求，如何对需求建模，如何制定合理的策略等内容有了更进一步的了解。

结对项目总结

结对过程回顾和反思

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

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

以下部分需要提升和改进：

• 协作能力不足：在任务初期未能进行充分讨论，对对方的意图不够了解，导致进度较慢。
• 最初代码结构比较混乱：代码耦合度较高，未进行模块化处理，导致迭代开发过程出现困难。
• 策略未得到充分优化：最后一次任务的执行策略较为简单，没有在决策中加入对其他蛇策略的思考。

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

优点：

• 有自己的想法
• 代码能力强
• 认真负责

缺点：

• 一开始沟通不太顺畅
• 疯狂星期四没有V我50

对结对编程的理解

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

结对编程是一种软件开发实践，两名程序员共同使用一台计算机进行开发。其中导航员负责审查代码，提出建议，思考整体结构，并提前发现潜在问题；驾驶员负责实际编码，编写和实现逻辑。
优点：

• 知识共享与技能提升：结对编程可以让团队成员相互学习，提高编码技巧和对项目的理解。
• 代码质量提升：通过实时代码审查，可以减少 bug，编写更清晰、可维护的代码。
• 增强团队协作：促进团队成员的沟通，减少代码风格或思路的分歧，提高团队凝聚力。

缺点：

• 短期效率可能较低：由于两人共同完成一个任务，开发初期可能感觉进度变慢，且如果任务较为简单，单人编写可能效率更高。
• 角色分配不均衡：如果一方始终处于“驾驶员”或“观察者”角色，可能会影响体验，需要定期交换角色。

代码实现提交

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

https://github.com/k6699k/snake

附录

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