[P] 结对项目：影蛇舞

结对项目：博客问题清单

项目	内容
这个作业属于哪个课程	2025年春季软件工程（罗杰、任健）
这个作业的要求在哪里	[P] 结对项目：影蛇舞
我在这个课程的目标是	学习软件工程的理论知识并进行实践。
这个作业在哪个具体方面帮助我实现目标	通过结对项目，提升团队交流合作的能力。

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

引入

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

2025/03/29 14:00

调查

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

I. 没有听说过；

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

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

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

I. 没有听说过；

总结

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

2025/03/29 14:20

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

结对过程

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

2025/03/29 14:30

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

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

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

2. 首先是根据 [G.2] Web Assembly 初见 中的指导学习了 Rust 程序设计语言（"the book"） 的前三章，安装了 Rust 的工具链并初步学习了相关的语法， 大致理解了题目的意思，并使用基于曼哈顿距离的贪婪算法，优先选择安全且距离果实最近的方向，距离相同时默认选择最后遍历到的方向。

   主要遇到的问题是再执行 wasm-pack build --target nodejs 出现构建问题，github仓库的 wasm-opt binary 拉 不下来，尝试了代理的方法也不太行。最后选择了手动下载这个依赖，并设置为环境变量才得以解决问题，在这里耗时较久。

测试

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

采用分层测试策略，针对贪吃蛇移动算法设计了五类核心测试用例：基础方向移动验证算法正确性、异常输入校验确保鲁棒性、身体避障逻辑测试、曼哈顿距离优先路径选择验证，以及200回合连续移动的集成场景测试，通过边界值分析法覆盖8x8网格的极端坐标，使用错误推测法注入非法参数，结合压力测试验证千次/秒的决策性能，最终以100%函数覆盖率和95%分支覆盖率确保算法在路径优化、安全避障和实时响应等维度的可靠性。

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

单元测试是软件开发过程中对最小可测试单元（通常是函数、方法或类）进行验证的实践。它可以提高代码质量、促进良好设计、提升开发效率和支持持续交付，它能显著提高软件的可维护性、可靠性和开发速度。

总结

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

2025/03/29 15:50

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

在较简单的样例中逐步熟悉了开发过程，为后面的开发打下基础。初步理解了 Wasm ，产生了继续开发的兴趣。

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

结对过程

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

2025/03/29 15:55

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

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

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

2. 首先读懂了题目的要求，然后两人稍微讨论下可行的算法，不算很难，所以这个模块耗时较少。

代码可复用性与需求变更

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

1. 复用部分：
   • 贪心框架：沿用 T1 的 贪心 算法框架，用于寻找最短路径。
   • 方向定义：保留 DIRECTIONS 数组的方向映射（上、左、下、右）。
   • 边界检查：场地的边界判断逻辑（GRID_SIZE=8 及坐标合法性校验）保持不变。
   • 碰撞检测：保留蛇身与自身的碰撞检测逻辑。
2. 修改部分：
   • BFS 处理：使用 BFS 算法验证可达性，并新增障碍物坐标的检查，路径规划时跳过障碍物。
   • 参数扩展：函数新增 obstacles 参数，并解析为 HashSet 用于路径搜索。
   • 蛇身初始化修正：修复 snake_positions 的初始化逻辑，正确收集所有四节蛇身坐标（原 T1 仅考虑头部）。
   • 可达性判断：在 is_reachable 函数中，同时考虑障碍物和蛇身的阻挡。

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

1. 设计思想：
   • 模块化：将碰撞检测（如 is_valid_position）、路径搜索（如 bfs）封装为独立函数，便于复用。
   • 参数化配置：将网格大小、方向等常量提取为配置参数，适应规则变化。
   • 数据抽象：使用 HashSet 存储障碍物/蛇身坐标，统一处理不同实体类型的碰撞。
2. 设计冗余：
   • 通用路径搜索：BFS 函数接受动态障碍物集合，可处理蛇身、障碍物或其他新增实体。
   • 状态分离：将游戏状态（蛇、果子、障碍物）与算法逻辑解耦，新增实体只需扩展输入参数。
   • 扩展性预留：预留钩子函数（如 pre_move_check），方便插入新规则（如动态障碍物）。

头脑风暴环节

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

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

1. 问题分析：
   • 旅行商问题（TSP）：需遍历所有果子，找到最短路径序列。
   • 启发式优化：由于 n < 10，采用贪心或动态规划近似最优解。
2. 策略步骤：
   • 步骤 1：计算全源最短路径：对每对果子（及起点），用 A* 或 BFS 计算最短路径及代价。
   • 步骤 2：构建路径图：将果子间的最短路径代价建模为带权图。
   • 步骤 3：求解 TSP：使用动态规划（状态压缩 DP）或启发式算法（如最近邻）确定访问顺序。
   • 步骤 4：分段执行路径：按顺序逐个吃掉果子，实时更新蛇身和剩余果子坐标。
3. 优化点：
   • 路径缓存：预计算所有果子间的最短路径，减少实时计算开销。
   • 实时避障：每次移动前动态检查路径有效性，若受阻则重新规划。

总结

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

2025/03/29 16:50

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

整体上难度并不大，在ai的帮助下很轻易的完成了。

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

结对过程

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

2025/03/29 17:00

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

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

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

2. 在理解了题意之后就开始疯狂敲打 deepseek 来寻求一个尽可能完美的策略，结果都不尽人意，遂两个人根据实际模拟的情况稍稍优化了下贪心和BFS就放弃了。

需求建模和算法设计

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

我们通过 四层建模 实现多蛇博弈需求：

1. 物理层：用Position结构体映射棋盘坐标，将蛇身解析为Vec<Position>链式结构，食物存储为HashSet<Position>离散点集，建立8×8网格空间模型。
2. 障碍层：

• 即时障碍：收集所有蛇的第2-4节身体坐标（代码中obstacles集合）
• 预测障碍：标记其他蛇头周边四格（防范头对头碰撞，见other_snakes处理逻辑）

1. 决策层：

• 主动寻食：BFS广度优先搜索生成最短安全路径（bfs_search函数）
• 被动避险：当无食物路径时，遍历四方向选择首个安全移动（生存策略循环）

1. 博弈层：

• 通过将敌方蛇头周围标记为障碍（代码35-45行），实施威慑策略
• 路径选择时优先远离多蛇争夺区域（隐含在BFS的障碍过滤中）

该模型将蛇身动态变化、食物分布、多蛇位置关系映射为可计算的离散空间状态，通过双重障碍系统和状态机决策实现安全与效率的平衡。

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

生存策略：

• 建立双重障碍系统：
  • 即时障碍：所有蛇当前身体坐标
  • 预测障碍：其他蛇头周围四格（防范下一回合头对头碰撞）
• 采用 安全逃生通道检测：优先选择可扩展移动空间的方向

进食策略：

• 路径分级系统：
  1. 最短路径：A*算法寻找曼哈顿距离最近食物
  2. 低竞争路径：过滤被多蛇争夺的食物
  3. 安全路径：确保路径周围有逃生空间
• 动态权重调整：根据剩余回合数平衡冒险系数

博弈策略：

• 威慑走位：故意靠近食物制造竞争假象
• 路径封堵：利用自身身体压缩对手移动空间

软件度量

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

可以通过多维度指标来量化程序有效性：

1. 生存指标：统计存活回合占比（≥85%合格）及碰撞规避率（总危险移动次数/实际碰撞次数），验证障碍检测系统可靠性；
2. 效率指标：计算单位回合进食量（吃果子数/存活回合数）与路径优化率（实际路径长度/曼哈顿距离），评估BFS寻路效果；
3. 博弈指标：在8x8四蛇对抗测试中，记录头对头碰撞诱发率（主动引发敌方碰撞占比）与被迫碰撞率，反映威慑策略有效性；

总结

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

2025/03/29 22:00

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

要考虑的东西太多，比不过神经网络的大佬(orz)

结对项目总结

结对过程回顾和反思

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

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

启动时间可以更早一些，T3可以寻求更优的解法。

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

优点：学习能力强，思维活跃，善于测试。

缺点：从配环境开始启动速度较慢。

对结对编程的理解

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

结对编程是两人共用一台电脑合作写代码的开发方式，一人负责敲代码，另一人专注审查和规划。优点明显：能减少代码错误、促进经验分享，还能碰撞出更好的设计方案；缺点是短期人力成本翻倍，且长时间配合容易疲劳。其核心在于互补：一人专注执行，另一人全局审视，平衡效率与质量，适合复杂任务或新人培训，长期收益常高于成本。

代码实现提交

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

https://github.com/tpxuan/PairProgramming

附录

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