[P]结对项目：影蛇舞
| 项目 | 内容 |
|---|---|
| 这个作业属于哪个课程 | 2025年春季软件工程（罗杰，任建） |
| 这个作业的要求在哪里 | [P]结对项目：影蛇舞 |
| 我在这个课程的目标是 | 体验完整的软件开发流程，并且学习软件的搭建与如何在团队中与他人协作 |
| 这个作业在哪个具体方面帮助我实现目标 | 提高代码编程能力，锻炼个人编程素质 |
结对项目：博客问题清单
请将本文件在代码仓库外复制一份，一边阅读和完成结对项目、一边填写入代码仓库外的版本，或采取简记、语音备忘等方式记载较复杂问题的要点之后再补充。请不要将本文档内的作答提交到代码仓库。
Chapter.0 Belua multorum es capitums.（你是多首的怪物。）
引入
→ 📖 Q0.1(P) 请记录下目前的时间。
2025/4/2/20:24
调查
→ 📖 Q0.2(I) 作为本项目的调查：请如实标注在开始项目之前对 Wasm 的熟悉程度分级，可以的话请细化具体的情况。
I. 没有听说过；
II. 仅限于听说过相关名词；
III. 听说过，且有一定了解；
IV. 听说过，且使用 Wasm 实际进行过开发（即便是玩具项目的开发）。
I
总结
→ 📖 Q0.3(P) 请记录下目前的时间。
2025/4/1/23:17
Chapter.1 不畏迷茫，只管前进。（迷子でもいい、前へ進め。）
结对过程
→ 📖 Q1.1(P) 请记录下目前的时间。
2025/4/2/20:24
→ 📖 Q1.2(P) 请在完成任务的同时记录，并在完成任务后整理完善：
- 浏览任务要求，参照 附录A：基于 PSP 2.1 修改的 PSP 表格，估计任务预计耗时；
- 完成编程任务期间，依次做了什么（比如查阅了什么资料，随后如何进行了开发，遇到了什么问题，又通过什么方式解决）；
| Personal Software Process Stages | 个人软件开发流程 | 预估耗时（分钟） | 实际耗时（分钟） |
|---|---|---|---|
| PLANNING | 计划 | ||
| - Estimate | - 估计这个任务需要多少时间 | 10 | 10 |
| DEVELOPMENT | 开发 | ||
| - Analysis & Design Spec | - 需求分析 & 生成设计规格（确定要实现什么） | 5 | 28 |
| - Technical Background | - 了解技术背景（包括学习新技术） | 60 | 37 |
| - Coding Standard | - 代码规范 | 5 | 5 |
| - Design | - 具体设计（确定怎么实现） | 30 | 49 |
| - Coding | - 具体编码 | 90 | 103 |
| - Code Review | - 代码复审 | 20 | 21 |
| - Test Design | - 测试设计（确定怎么测，比如要测试哪些情景、设计哪些种类的测试用例） | 10 | 8 |
| - Test Implement | - 测试实现（设计/生成具体的测试用例、编码实现测试） | 30 | 48 |
| REPORTING | 报告 | ||
| - Quality Report | - 质量报告（评估设计、实现、测试的有效性） | 10 | 9 |
| - Size Measurement | - 计算工作量 | 10 | 11 |
| - Postmortem & Process Improvement Plan | - 事后总结和过程改进计划（总结过程中的问题和改进点） | 10 | 17 |
| TOTAL | 合计 | 290 | 346 |
2.查阅了关于Python中如何定义函数，随后首先在草稿纸上对于蛇的行动进行了各种手绘模拟，并且就距离的计算进行了多种模拟，确定使用贪心算法；随后在开发过程中发现采用勾股定理（后得知这种实际是欧氏距离）计算距离在代码的实现上会有困难，于是查阅CSDN相关文章与询问AIGC工具，最后发现使用欧氏距离适用于自由移动（即可以斜向运动），而对于贪吃蛇这种在网格环境中运动的情况应该使用曼哈顿距离进行计算最短距离。
测试
→ 📖 Q1.3(P) 请说明针对该任务，你们设计和实现测试的方法及过程，包括但不限于：出于对需求的哪些考虑设计了哪些测试用例、如何评估所设计测试的有效性 等等。
我设计了一个通过遍历所有current_dir的方向值来测试我编写的代码是否有问题。总共有四个方向值，我设计了四组擦色，并且首先手打给出了正确答案，再调用greedy_snake_move函数，通过对比代码输出结果与我手写写过来测试代码的有效性。
→ 📖 Q1.4(I) 请说明单元测试对软件开发的作用。
1.单元测试可以让开发者在当前单元就能发现问题并且解决，避免了问题的累积导致修复代价大幅提升。
2.单元测试可以督促开发者更加严谨的编写代码，降低bug的出现概率。
3.单元测试可以使项目各个模块按预想工作，为后期的集成测试奠定基础，使项目更可能按照计划交付。
总结
→ 📖 Q1.5(P) 请记录下目前的时间，并根据实际情况填写 附录A：基于 PSP 2.1 修改的 PSP 表格 的“实际耗时”栏目。
实际耗时：2h46min
→ 📖 Q1.6(I) 请写下本部分的心得体会。
本部分让我重新拾起编写Python代码的基础（在此之前已经有长达半年没有敲过代码），并且也让我清晰地认识到数学方法与代码实现的差异性，并且针对不同的场景应该使用不同的数学理论，让代码的实现更贴合需求。
Chapter.2 即使迷茫，也要前行。（迷子でもいい、迷子でも進め。）
结对过程
→ 📖 Q2.1(P) 请记录下目前的时间。
2025/4/3/1:32
→ 📖 Q2.2(P) 请在完成任务的同时记录，并在完成任务后整理完善：
- 浏览任务要求，参照 附录A：基于 PSP 2.1 修改的 PSP 表格，估计任务预计耗时；
- 完成编程任务期间，依次做了什么（比如查阅了什么资料，随后如何进行了开发，遇到了什么问题，又通过什么方式解决）；
| Personal Software Process Stages | 个人软件开发流程 | 预估耗时（分钟） | 实际耗时（分钟） |
|---|---|---|---|
| PLANNING | 计划 | ||
| - Estimate | - 估计这个任务需要多少时间 | 10 | 10 |
| DEVELOPMENT | 开发 | ||
| - Analysis & Design Spec | - 需求分析 & 生成设计规格（确定要实现什么） | 20 | 16 |
| - Technical Background | - 了解技术背景（包括学习新技术） | 60 | 115 |
| - Coding Standard | - 代码规范 | 10 | 5 |
| - Design | - 具体设计（确定怎么实现） | 10 | 7 |
| - Coding | - 具体编码 | 120 | 228 |
| - Code Review | - 代码复审 | 30 | 19 |
| - Test Design | - 测试设计（确定怎么测，比如要测试哪些情景、设计哪些种类的测试用例） | 10 | 6 |
| - Test Implement | - 测试实现（设计/生成具体的测试用例、编码实现测试） | 30 | 104 |
| REPORTING | 报告 | ||
| - Quality Report | - 质量报告（评估设计、实现、测试的有效性） | 10 | 14 |
| - Size Measurement | - 计算工作量 | 10 | 7 |
| - Postmortem & Process Improvement Plan | - 事后总结和过程改进计划（总结过程中的问题和改进点） | 10 | 23 |
| TOTAL | 合计 | 330 | 554 |
- 在T2中因为有障碍物的引入，所以增加了障碍物的定义，并且增加了障碍物碰撞检测，因为障碍物的引入，会导致蛇可能无法吃到果子（即障碍把所有可能通向果子的路线封锁住了），所以最开始设计只是沿用贪心算法来寻路，但是在测试的时候发现在某些情况下，蛇在原地打转，最终因为循环次数超过200回合而超市报错。随后查阅资料发现贪心算法只在乎下一步的最高收益而忽略了对全局的影响，从而导致上述情形的发生。最后在csdn上查阅决定改用BFS算法首先算出一整条通路，再在通路中运用贪心算法选择行进方向来解决单一使用贪心算法的不足。
代码可复用性与需求变更
→ 📖 Q2.3(P) 请说明针对该任务，你们对 🧑💻 T2 中已实现的代码进行了哪些复用和修改。
- 在T1中，我已经对蛇的身体和果子的坐标进行了定义，并且设计了身体碰撞和边界碰撞检测，所以我复用了这一部分代码使蛇的基本运动逻辑不会出现变化。
- 在T2中，在使用了助教的测试代码后，发现T1中关于身体碰撞测试部分的设计过于简化了，所以重新设计了一套身体碰撞测试的代码。
→ 📖 Q2.4(I) 请说明在编码实现时，可以采取哪些设计思想、考虑哪些设计冗余，来提高既存代码适应需求变更的能力。
设计思想：
模块化：让每一部分的工作独立分开，当一个模块进行多次更改的时候不会影响其他模块的正常运行。
设计冗余：
通过提供默认值，增加系统的鲁棒性，或者提供默认策略，方便未来的扩展。
头脑风暴环节
**→ 📖 Q2.5(P) **只吃一个食物可满足不了贪吃蛇的欲望，请一起思考并简述以下场景中贪吃蛇的策略：
在 🧑💻 T2 的基础上，场地里不再是只有 1 个果子，而是总共有 n 个果子 (1 < n < 10 )，果子随机分布在场地中且不会刷新，保证不与障碍物重叠，保证每个果子均可达，且至少存在一条成功吃掉所有果子的路线，其余条件保持不变，请你找出一条吃完所有果子的行动路径。
通过遍历所有果子的坐标，通过曼哈顿距离来判断距离远近，最后使用BFS算法将所有的果子进行串联，得出路径。
总结
→ 📖 Q2.6(P) 请记录下目前的时间，并根据实际情况填写 附录A：基于 PSP 2.1 修改的 PSP 表格 的“实际耗时”栏目。
2025/4/6/10:36
→ 📖 Q2.7(I) 请写下本部分的心得体会。
本部分耗时偏长主要是因为在这部分才得知有助教提供的测试代码，但是在打开后才发现原本使用的Python会很难以转化为wasm文件（起码我自己是没研究明白的），但是时间实在太紧张了，就让ChatGpt帮我把Python代码转换为Assembly script，然后我又去学怎么生成胶水代码，怎么配置环境让生成的Assembly script代码能够进行测试。然后在测试之后发现自己写的T1里面把移动想的太简单了，就又去查资料看怎么改比较好。总之就是一个过得非常苦的状态...
Chapter.3 这就是我的前进、到我出场了！！！！！（It's MyGO!!!!!）
结对过程
→ 📖 Q3.1(P) 请记录下目前的时间。
2025/4/6/10:37
→ 📖 Q3.2(P) 请在完成任务的同时记录，并在完成任务后整理完善：
- 浏览任务要求，参照 附录A：基于 PSP 2.1 修改的 PSP 表格，估计任务预计耗时；
- 完成编程任务期间，依次做了什么（比如查阅了什么资料，随后如何进行了开发，遇到了什么问题，又通过什么方式解决）；
| Personal Software Process Stages | 个人软件开发流程 | 预估耗时（分钟） | 实际耗时（分钟） |
|---|---|---|---|
| PLANNING | 计划 | ||
| - Estimate | - 估计这个任务需要多少时间 | 10 | 10 |
| DEVELOPMENT | 开发 | ||
| - Analysis & Design Spec | - 需求分析 & 生成设计规格（确定要实现什么） | 10 | 10 |
| - Technical Background | - 了解技术背景（包括学习新技术） | 30 | 18 |
| - Coding Standard | - 代码规范 | 5 | 5 |
| - Design | - 具体设计（确定怎么实现） | 10 | 47 |
| - Coding | - 具体编码 | 120 | 131 |
| - Code Review | - 代码复审 | 20 | 32 |
| - Test Design | - 测试设计（确定怎么测，比如要测试哪些情景、设计哪些种类的测试用例） | 20 | 19 |
| - Test Implement | - 测试实现（设计/生成具体的测试用例、编码实现测试） | 50 | 87 |
| REPORTING | 报告 | ||
| - Quality Report | - 质量报告（评估设计、实现、测试的有效性） | 10 | 16 |
| - Size Measurement | - 计算工作量 | 10 | 9 |
| - Postmortem & Process Improvement Plan | - 事后总结和过程改进计划（总结过程中的问题和改进点） | 10 | 5 |
| TOTAL | 合计 | 305 | 339 |
需求建模和算法设计
→ 📖 Q3.3(P) 请说明你们如何建模这一需求。
把所有会让我碰撞身亡的坐标都收集起来，这些被收集起来的坐标就等同于T2中障碍物，在当前这一时刻，我再使用BFS算法来寻址
→ 📖 Q3.4(P) 请说明针对该任务，你们采取了哪些策略来优化决策。具体而言，怎么避免死亡？怎么吃到更多果子？如何编程实现。
避免死亡：收集所有可能让我身亡的坐标（其他蛇的四个坐标，自己身体的坐标），同时考虑边界问题。
吃到更多果子：通过遍历所有可能的方向，用BFS算法找出最短路径
软件度量
→ 📖 Q3.5(P) 请说明你们如何量度所实现的程序模块的有效性，例如：“如何说明我们的程序模块对弈能力很强？”尝试提出一些可能的定量分析方式。
作为单人完成了结对作业，我的程序模块的对弈能力实际是有限的。我在多次进行测试的过程中，大概会有50%的概率我自己的四条小蛇全部死亡，其中又有将近70%的情况是小蛇在20个回合之内就会死亡。只有10%左右的概率我会有多于一条小蛇是存活的状态。
总结
→ 📖 Q3.6(P) 请记录下目前的时间，并根据实际情况填写 附录A：基于 PSP 2.1 修改的 PSP 表格 的“实际耗时”栏目。
2025/4/6/16:08
→ 📖 Q3.7(I) 请写下本部分的心得体会。
在初次看到的时候我把这个问题想得很复杂，但是后来当我把思维转变成“其他蛇其实就是动态的障碍物”的时候，我就发现这个任务也没有我想象中那么困难。
结对项目总结
结对过程回顾和反思
→ 📖 Q4.1(P) 提供两人在讨论的结对图像资料。
因本人的结对作业队友失联了，所以本人单独完成的本次作业
→ 📖 Q4.2(P) 回顾结对的过程，反思有哪些可以提升和改进的地方。
希望下次能有个靠谱的队友
→ 📖 Q4.3(I) 锐评一下你的搭档！并请至少列出三个优点和一个缺点。
无
对结对编程的理解
→ 📖 Q4.4(I) 说明结对编程的优缺点、你对结对编程的理解。
没经历结对编程，不予置评。
编程就是把抽象问题具体化的一个过程。
浙公网安备 33010602011771号