[P] 结对作业：影蛇舞

软工结对作业：影蛇舞

格式描述

项目	内容
这个作业属于哪个课程	软件工程
这个作业的要求在哪里	影蛇舞作业要求
我在这个课程的目标是	提升软件工程化能力，提升团队合作与交流沟通能力，培养敏捷开发能力
这个作业在哪个具体方面帮助我实现目标	培养结对编程与敏捷开发能力，熟练掌握GitHub等版本控制和协作开发平台的各类操作

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

引入

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

2025.03.27 10:52 - 2025.03.27 11:17

调查

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

I. 没有听说过；

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

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

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

II. 仅限于听说过相关名词，未进行过任何开发。

总结

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

2025.03.27 10:52 - 2025.03.27 11:17

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

结对过程

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

2025.03.28 14:57 - 2025.03.28 15:23
2025.03.28 19:18 - 2025.03.28 20:16

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

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

表格见总结部分。

在完成编程期间，我们主要查阅了Rust语言的基础语法、Rust-Wasm的编译文档，并进行了简单的开发实践。在这之中，由于初次接触Rust语言，我们也遇到一定问题，如编译过程中出现的模块丢失问题。经查验，发现是编译时命令使用出错：错用了 wasm-pack build --target web 指令，使得不能直接在js文件中引用和使用。

测试

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

章节一场景较为简单，不存在障碍物，同时数值为4的蛇身长度设置保证了正常情况下蛇不会出现锁死的状态。我们也使用样例进行了验证：在该任务中，主要需要测试蛇头与蛇身碰撞的情况，因此在正常样例外我们又设计了如下样例：蛇头和蛇身四个坐标呈正方形，果子、蛇头、蛇尾在同一直线上且蛇尾位于中央。经查验，算法对于样例效果良好。

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

• 将程序划分为多个小单元，降低了程序的耦合度与复杂度，可以简化测试难度，提高测试效率，保证代码正确性。
• 将程序划分为多个小单元，在确定接口文档后，可以将单元交给不同人开发与测试，促进团队协作。
• 单元测试作为早期测试，可以更早暴露代码问题，以减少功能性测试等更复杂测试的难度。
• 单元测试作为CI/CD的重要环节，提升开发效率，有利于敏捷开发的实现。

总结

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

2025.03.28 14:57 - 2025.03.28 15:23
2025.03.28 19:18 - 2025.03.28 20:16

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

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

在本部分中，由于选择了Rust语言，确实比较难上手、难以开发。在编译与链接阶段，出现了许多看不懂的Bug，两个人花费了许多时间查找资料，才最终解决。但在完成编译与链接后，代码的编写难度不是很高，很快便完成了。在这部分，感觉结对编程并没有发挥过多的正向或反向作用。

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

结对过程

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

2025.03.31 15:18 - 2025.03.31 17:03

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

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

表格见总结部分。

在本章节中，出于对语言的学习目的，尝试使用了更加复杂的数据结构，如结构体、 Vec 队列等。在使用过程中，遇到很多语法问题，比如为通过 Wasm编译，需在结构体定义部分新加 #[derive(Clone, Copy, PartialEq, Eq, Hash)] 说明；为完成函数的参数传递，需要更改和对应可变和不可变引用；为重复独立使用变量，需要对变量进行 clone() 操作。通过查阅资料，并借助大模型，对错误代码进行了一定修改。

代码可复用性与需求变更

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

• 复用：章节一设置的算法较为简单，因此在章节二中复用性较弱。主要复用了章节一的数据解析部分。
• 修改：章节二重写了核心算法，主要采用了广度优先遍历算法，查找从果子出发，到达蛇头的最短路径和方向。同时，使用了更多的数据结构，并尝试了构建函数和变量引用传递。

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

• 设计思想：
  • 模块化功能化：在实现代码时，可以按照功能将代码划为不同的代码块，以提高带啊吗的复用性；
  • 抽象化与策略模式：在实现代码时，有些代码在应用层面不同，但底层逻辑相似，可以抽取并提炼成抽象代码；
  • 接口：模块外留接口，只更改外部代码，减少模块内部代码变更。
• 设计冗余：
  • 预留扩展点：可以预测一些未来可能修改或扩展的位置，增添一些冗余代码创造接口；
  • 配置化参数化：一些参数提取出来，使用宏定义表示，增加复用性和可修改性；
  • 版本控制：实现代码中难免会遇到无法解决的Bug想要回溯版本，借用Git的版本控制功能来实现。

头脑风暴环节

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

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

可以把果子分类为四种，并进行分别讨论：

• 果子周边只有一格可达：可能有三种情况：位于地图顶角，周围有一个障碍；位于地图边，周围有两个障碍；位于地图中央，周围有三个障碍。对于这类果子，蛇应该最后吃掉。
• 果子周边有两格可达：在章节二中使用广度优先算法，并在其中规定，当从果子遍历到蛇时，停止搜索。这表明，蛇将要走的路径一定是最短路径。在最短路径下，一定不会出现当蛇吃到果子时，蛇身出现在果子另外两个方向的情况，即蛇身将蛇头围住。因此，正常吃果子即可。
• 果子周边有三格可达：情况与两格可达时相似。
• 果子周边有四格可达：情况与两格可达时相似。

总结

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

2025.03.31 15:18 - 2025.03.31 17:03

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

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

本部分算法设计比较简单，可以直接采用 BFS ，而Rust编程具有一定难度。在本节中，为了进一步练习Rust语言和优化程序，使用了结构体、 Vec 可变队列等数据结构，在使用规范和Wasm编译上花费了一定时间，最终也是通过查阅资料和借助大模型解决了这一系列问题。完成代码编写后，轮流进行了测试，查出并修改了一些Bug，两个人的思考范围确实会更广泛，更容易查出问题。

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

结对过程

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

2025.04.01 14:35 - 2025.04.01 18:02

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

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

表格见总结部分。

首先回顾了广度优先遍历算法，然后进行具体编码，在实现过程中发现了不同蛇下一步吃同一颗果子的相撞情况，为此进行系数调整，提高其他蛇到果子最短距离的权重；此外，有联想到了不同蛇在运动过程中蛇头相撞，因此找出其他蛇的蛇头下一步可能到达的格子，并在选择运动方向时候避开这些格子。

需求建模和算法设计

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

将其他蛇的蛇头蛇身所在坐标都视为障碍，之后实现策略仿效章节二采用广度优先遍历算法即可。

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

• 基本策略：
  • 采用广度优先遍历算法，获得每个果子到本蛇蛇头和其他蛇头的距离以及方向；
  • 对于每个果子，赋予果子到本蛇蛇头距离、果子到其他最近蛇蛇头距离权重，获得果子的得分（以距离本蛇越近，距离其他蛇越远为佳）；
  • 比较每个果子的得分，向得分最高的果子前进一格。
• 死亡避免：
  • 按照本蛇蛇头坐标，判断蛇头周围一格是否存在障碍（障碍及其他蛇）；
  • 按照本蛇蛇头坐标及其他蛇蛇头坐标，判断周围一格是否存在有其他蛇蛇头在下一轮次可以到达的情况，并尽量避免其他蛇蛇头可能到达的格子，降低同归于尽的可能。

软件度量

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

• 存活：将其他蛇的蛇头蛇身坐标以及它们即将可能到达的格子都视为障碍，在选取运动方向时候尽可能避开这些格子；

• 系数：给其它蛇蛇头到目标果子的最小距离赋予权重，这样在选择运动方向时就会避免选择离其它蛇更近的果子，减少了不同蛇争取同一个果子或者在运动过程中相撞的情况的出现；

• 得分：蛇吃掉果子得1分，分数理所当然的作为一个评价标准。

总结

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

2025.04.01 14:35 - 2025.04.01 18:02

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

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

在本章节中，核心算法仍然使用的是 BFS 算法。笔者注意到，有其他大佬使用深度强化学习的 DQN 算法对环境和策略进行学习，确实是一个非常新颖和可行的方案。但是碍于初次学习使用Rust语言，还不熟悉如何将Python程序接入Rust程序中（主要还是懒，而且其实棋盘很小， BFS 算法消耗的时间也不大），笔者并未进行该方向的探索。在章节三中，笔者增加了多个函数，提高了程序的单元化、模块化。但与此同时，也增加了程序出现Bug的概率，确实耗费了一定的时间与精力。

啊对，最后的最后，还有最重要的事情，骚扰咨询助教是一个解决问题的好方法，感谢🐻学长！感谢🐻学长！感谢🐻学长！👏

结对项目总结

结对过程回顾和反思

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

约到研讨室和未约到研讨室的两人……

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

• 本次结对过程中，队友间的交流仍然不够，还需要多通过微信等社交软件多沟通；
• 本次结对过程中，分工不是十分明确，出现过一个人编程另一个人休息的局面，还是应该确定分工策略，提高并行效率；
• 本次结对过程中，对于时间安排规划不足，分多时段完成，以后可以商量出整块时间进行编程。

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

• 优点：
  • 编程能力强，很快便能完成代码；
  • 思考全面，可以想到程序应当囊括的各种情况；
  • 资料查找能力强，能够阅读大量资料并提炼。
• 缺点：
  • 能力太强，气场太盛，带给笔者极大的压力。

对结对编程的理解

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

• 优缺点：
  • 优点：结对互补，编码速度快，能快速找到代码的问题所在；思路全面，能想到面对的全部情况。
  • 缺点：思考困难，依赖于两人的交流沟通。
• 理解：笔者认为，结对编程优点在于快速互补，缺点在于依赖沟通。在某些任务上，结对编程的效率不如单人完成，但是其正确率与全面性可能超越单人完成。对于善于沟通交流与完成文档的程序员，可以发挥结对编程的优势，规避劣势。但对于不是很擅长沟通的程序员，结对编程可能会带来较大的压力与负担。

代码实现提交

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

2025 SE - Pair Program

附录

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