[p] 结对项目：影蛇舞
软工结对作业：影蛇舞
| 项目 | 内容 |
|---|---|
| 这个作业属于哪个课程 | 软件工程 |
| 这个作业的要求在哪里 | 影蛇舞作业要求 |
| 我在这个课程的目标是 | 提升软件工程化能力，提升团队合作与交流沟通能力，培养敏捷开发能力 |
| 这个作业在哪个具体方面帮助我实现目标 | 培养结对编程与敏捷开发能力，熟练掌握GitHub等版本控制和协作开发平台的各类操作 |
结对项目：博客问题清单
Chapter.0 Belua multorum es capitums.（你是多首的怪物。）
引入
→ 📖 Q0.1(P) 请记录下目前的时间。
2025.04.01 ,16:00
调查
→ 📖 Q0.2(I) 作为本项目的调查：请如实标注在开始项目之前对 Wasm 的熟悉程度分级，可以的话请细化具体的情况。
I. 没有听说过；
II. 仅限于听说过相关名词；
III. 听说过，且有一定了解；
IV. 听说过，且使用 Wasm 实际进行过开发（即便是玩具项目的开发）。
II
总结
→ 📖 Q0.3(P) 请记录下目前的时间。
2025.04.01 ,17:08
Chapter.1 不畏迷茫，只管前进。（迷子でもいい、前へ進め。）
结对过程
→ 📖 Q1.1(P) 请记录下目前的时间。
2025.04.01 ,18:04
→ 📖 Q1.2(P) 请在完成任务的同时记录，并在完成任务后整理完善：
- 浏览任务要求，参照 附录A：基于 PSP 2.1 修改的 PSP 表格，估计任务预计耗时；
- 完成编程任务期间，依次做了什么（比如查阅了什么资料，随后如何进行了开发，遇到了什么问题，又通过什么方式解决）；
| Personal Software Process Stages | 个人软件开发流程 | 预估耗时（分钟） | 实际耗时（分钟） |
|---|---|---|---|
| PLANNING | 计划 | 5 | 5 |
| - Estimate | - 估计这个任务需要多少时间 | 5 | 5 |
| DEVELOPMENT | 开发 | 120 | 55 |
| - Analysis & Design Spec | - 需求分析 & 生成设计规格（确定要实现什么） | 5 | 10 |
| - Technical Background | - 了解技术背景（包括学习新技术） | 5 | 2 |
| - Coding Standard | - 代码规范 | 15 | 3 |
| - Design | - 具体设计（确定怎么实现） | 15 | 5 |
| - Coding | - 具体编码 | 35 | 10 |
| - Code Review | - 代码复审 | 15 | 15 |
| - Test Design | - 测试设计（确定怎么测，比如要测试哪些情景、设计哪些种类的测试用例） | 15 | 5 |
| - Test Implement | - 测试实现（设计/生成具体的测试用例、编码实现测试） | 15 | 5 |
| REPORTING | 报告 | 25 | 20 |
| - Quality Report | - 质量报告（评估设计、实现、测试的有效性） | 10 | 10 |
| - Size Measurement | - 计算工作量 | 5 | 5 |
| - Postmortem & Process Improvement Plan | - 事后总结和过程改进计划（总结过程中的问题和改进点） | 10 | 5 |
| TOTAL | 合计 | 150 | 80 |
2.分析文档--建模并得出解决方案--编码实现--编写测试
测试
→ 📖 Q1.3(P) 请说明针对该任务，你们设计和实现测试的方法及过程，包括但不限于：出于对需求的哪些考虑设计了哪些测试用例、如何评估所设计测试的有效性 等等。
经过分析问题后，我们的决策方案是：贪心地前往曼哈顿距离下离果子最近的点。决策过程如下：
- 对于4个方向按距离果子的曼哈顿距离排序(曼哈顿距离相同的看坐标差值)，然后从最优的方向开始选择
- 对于选择的移动方向，检查移动的有效性，即蛇是否和自己相撞，是否与边界相撞
- 若有效，则return 该方向；若无效，选择次优的下一个方向并检查直到有一个方向通过有效性检查
- 如果所有的方向都没有通过检查，则任意返回一个方向
对于测试，我们利用java随机生成了n组合法的蛇身数据和果子坐标作为输入参数，调用函数greedy_snake_fn_checker进行断言测试，这里我们设定的n足够大，满足测试的随机性和有效性。此外，我们人工设计了一组数据，模拟蛇在极端情况下的决策，即蛇不能在曼哈顿距离最优的1-2个方向上移动（因为其会遇到边界或蛇身而死亡），从而使得其只能沿着一个远离果子的方向移动（测试样例：assert.strictEqual(greedy_snake_fn_checker([1,1,2,1,3,1,4,1], [5,1], greedy_snake_move) >= 0, true);）。
→ 📖 Q1.4(I) 请说明单元测试对软件开发的作用。
单元测试是软件开发中至关重要的实践，它通过在编码阶段快速发现逻辑错误并提供精准定位，帮助开发者及早修复缺陷；同时验证每个功能单元的行为是否符合预期，特别关注边界条件的覆盖，从而提升代码质量。此外，单元测试还作为可执行的文档，清晰说明接口的预期行为，并在重构时充当安全网，确保修改不会破坏现有功能，显著提高代码的可维护性。
总结
→ 📖 Q1.5(P) 请记录下目前的时间，并根据实际情况填写 附录A：基于 PSP 2.1 修改的 PSP 表格 的“实际耗时”栏目。
2025.04.01 ,20:15
→ 📖 Q1.6(I) 请写下本部分的心得体会。
T1还不算很难，做的比较轻松。
Chapter.2 即使迷茫，也要前行。（迷子でもいい、迷子でも進め。）
结对过程
→ 📖 Q2.1(P) 请记录下目前的时间。
2025.04.02 ,18:36
→ 📖 Q2.2(P) 请在完成任务的同时记录，并在完成任务后整理完善：
- 浏览任务要求，参照 附录A：基于 PSP 2.1 修改的 PSP 表格，估计任务预计耗时；
- 完成编程任务期间，依次做了什么（比如查阅了什么资料，随后如何进行了开发，遇到了什么问题，又通过什么方式解决）；
| 1 | |||
|---|---|---|---|
| Personal Software Process Stages | 个人软件开发流程 | 预估耗时（分钟） | 实际耗时（分钟） |
| PLANNING | 计划 | 5 | 5 |
| - Estimate | - 估计这个任务需要多少时间 | 5 | 5 |
| DEVELOPMENT | 开发 | 60 | 200 |
| - Analysis & Design Spec | - 需求分析 & 生成设计规格（确定要实现什么） | 10 | 15 |
| - Technical Background | - 了解技术背景（包括学习新技术） | 5 | 10 |
| - Coding Standard | - 代码规范 | 3 | 5 |
| - Design | - 具体设计（确定怎么实现） | 2 | 20 |
| - Coding | - 具体编码 | 25 | 80 |
| - Code Review | - 代码复审 | 5 | 10 |
| - Test Design | - 测试设计（确定怎么测，比如要测试哪些情景、设计哪些种类的测试用例） | 3 | 20 |
| - Test Implement | - 测试实现（设计/生成具体的测试用例、编码实现测试） | 7 | 40 |
| REPORTING | 报告 | 35 | 35 |
| - Quality Report | - 质量报告（评估设计、实现、测试的有效性） | 25 | 20 |
| - Size Measurement | - 计算工作量 | 5 | 5 |
| - Postmortem & Process Improvement Plan | - 事后总结和过程改进计划（总结过程中的问题和改进点） | 10 | 15 |
对于T2，我们起初的想法是在T1的基础加上对障碍物的判断，但后来发现无法通过绕远路的方式避开障碍物，之后我们采用bfs进行最短路径搜索，同时融合了贪心思想（加入贪心的目的是为了更快地找到最优路径，提升效率）。具体来说，利用优先队列存储接下来要搜索的节点，用节点类属性visited来表示该节点是否被访问过，属性x,y表示该节点位置，属性parent存储父节点（相信助教在这里一定看出了我是先用java写，之后再转成rust）。最终获得蛇到果子的路径后返回第一步动作即可。
代码可复用性与需求变更
→ 📖 Q2.3(P) 请说明针对该任务，你们对 🧑💻 T2 中已实现的代码进行了哪些复用和修改。
数据测试部分：大部分沿袭T1代码，只增加了障碍物的随机生成。
移动决策部分：基本都有改动，从原来的根据哈密顿距离和是否碰到障碍物决策到现在的使用bfs搜索+贪心思想。复用部分的话，在判断方向是否是有效方向函数中isValidMove复用较多，相对T1增加了对障碍物的处理部分。
→ 📖 Q2.4(I) 请说明在编码实现时，可以采取哪些设计思想、考虑哪些设计冗余，来提高既存代码适应需求变更的能力。
采用模块化的思想分装函数，对于代码中不同逻辑部分可以拆分封装成不同函数，使得在题目需求改变时，仅仅需要改变参数配置而无需重构代码。同时使得代码逻辑清晰，不冗长。
头脑风暴环节
**→ 📖 Q2.5(P) **只吃一个食物可满足不了贪吃蛇的欲望，请一起思考并简述以下场景中贪吃蛇的策略：
在 🧑💻 T2 的基础上，场地里不再是只有 1 个果子，而是总共有 n 个果子 (1 < n < 10 )，果子随机分布在场地中且不会刷新，保证不与障碍物重叠，保证每个果子均可达，且至少存在一条成功吃掉所有果子的路线，其余条件保持不变，请你找出一条吃完所有果子的行动路径。
判断是否有果子存在于死路中（判断方法：蛇到达该果子后，无法到达任一其他果子），由题意可知，该果子至多只有一个。只需要让该果子最后被吃即可。
总结
→ 📖 Q2.6(P) 请记录下目前的时间，并根据实际情况填写 附录A：基于 PSP 2.1 修改的 PSP 表格 的“实际耗时”栏目。
2025.04.02 ,21:30
→ 📖 Q2.7(I) 请写下本部分的心得体会。
在T2中，因为rust，wasm中较难调试，因此我选择将原来的js，rust代码翻译为java后在编写算法部分代码，过程中也遇到不少bug，但好在我们比较熟练java的调试，最终也是顺利完成了该任务。总的说来，T2相比T1难度还是上了一个层次的。
Chapter.3 这就是我的前进、到我出场了！！！！！（It's MyGO!!!!!）
结对过程
→ 📖 Q3.1(P) 请记录下目前的时间。
2025.04.03 ,17:30
→ 📖 Q3.2(P) 请在完成任务的同时记录，并在完成任务后整理完善：
- 浏览任务要求，参照 附录A：基于 PSP 2.1 修改的 PSP 表格，估计任务预计耗时；
- 完成编程任务期间，依次做了什么（比如查阅了什么资料，随后如何进行了开发，遇到了什么问题，又通过什么方式解决）；
| Personal Software Process Stages | 个人软件开发流程 | 预估耗时（分钟） | 实际耗时（分钟） |
|---|---|---|---|
| PLANNING | 计划 | ||
| - Estimate | - 估计这个任务需要多少时间 | 360 | 320 |
| DEVELOPMENT | 开发 | ||
| - Analysis & Design Spec | - 需求分析 & 生成设计规格（确定要实现什么） | 10 | 10 |
| - Technical Background | - 了解技术背景（包括学习新技术） | 30 | 20 |
| - Coding Standard | - 代码规范 | 10 | 10 |
| - Design | - 具体设计（确定怎么实现） | 30 | 30 |
| - Coding | - 具体编码 | 90 | 80 |
| - Code Review | - 代码复审 | 30 | 20 |
| - Test Design | - 测试设计（确定怎么测，比如要测试哪些情景、设计哪些种类的测试用例） | 30 | 30 |
| - Test Implement | - 测试实现（设计/生成具体的测试用例、编码实现测试） | 30 | 20 |
| REPORTING | 报告 | ||
| - Quality Report | - 质量报告（评估设计、实现、测试的有效性） | 60 | 60 |
| - Size Measurement | - 计算工作量 | 5 | 5 |
| - Postmortem & Process Improvement Plan | - 事后总结和过程改进计划（总结过程中的问题和改进点） | 35 | 35 |
| TOTAL | 合计 | 360 | 320 |
2.先查阅了相关资料确定算法，然后编码实现，最后通过测试调整参数。
需求建模和算法设计
→ 📖 Q3.3(P) 请说明你们如何建模这一需求。
将蛇吃果子抽象为一个无法后退的小人向着效用最高的方向前进。将每一个果子看作势能场的中心，把其他的蛇和地图边界看作负势能场的中心，蛇会计算每一个即将到达的格子的效用，然后前往效用最高的格子。
→ 📖 Q3.4(P) 请说明针对该任务，你们采取了哪些策略来优化决策。具体而言，怎么避免死亡？怎么吃到更多果子？如何编程实现。
避免死亡：
- 向地图边界与其他蛇加负的权重，让蛇远离障碍物
- 特判边界与其他蛇的身体，避免前往“黑色区域”
- 在两条蛇进入对峙局面时，如果场上还有第三条蛇，那么蛇会选择一个其他蛇下一步无法到达的格子，从而避免蛇头相撞
吃到更多果子：
- 使用势能而非简单贪心，使得蛇可以兼顾全局，避免过分最求眼前利益
- 尽量远离其他蛇，避免竞争，可以更高效的吃果子
- 多蛇竞争，避免蛇头相撞；双蛇竞争，不防蛇头相撞
- 尽量避免死亡
软件度量
→ 📖 Q3.5(P) 请说明你们如何量度所实现的程序模块的有效性，例如：“如何说明我们的程序模块对弈能力很强？”尝试提出一些可能的定量分析方式。
1、程序有效性测定
在这个问题中，一个简易的模型是避免身体碰撞，永远吃最近果子的贪心蛇。我们实现的蛇使用了势能的概念，不妨称为势能蛇。通过课程组提供的测试程序，分别进行 100 场 势vs贪 与 势vs贪vs贪vs贪 比赛。
-
1v1
名称 胜场 胜率 势能蛇 84 84% -
4蛇乱斗
名称 得分 势能蛇 213 注：按照课程组的乱斗评分规则，前四名分别为3、2、1、0分，因此 100 场平均分为 150 分。
2、礼貌模块有效性测定
势能蛇在发生对峙时，会调用礼貌模块来避免前往另一方下一回合可能前往的区域，从而避免蛇头对撞。在4蛇乱斗中，这种安全的做法可以帮助蛇活下来，从而取得更高的分数。但在1v1中，这种礼貌谦让的行为却会导致蛇错失先机。下面通过对照试验来验证礼貌模块的有效性
图中蛇1与蛇3陷入了对峙局面
-
礼貌的势能蛇 vs 非礼貌的势能蛇（区别仅为礼貌模块）
礼貌的势能蛇 非礼貌的势能蛇 礼貌的势能蛇 47 : 53 32 : 68 -
四蛇乱斗（礼貌的势能蛇简写为礼，非礼貌的势能蛇简写为非）
礼礼礼礼 礼非非非 1号（礼貌的势能蛇）得分 143 192 注：基准分为 150 分。
从对照实验中可以看出，礼貌模块确实是有效的，在4蛇乱斗中有效提高性能，在1v1中有效降低性能。因此，应该当且仅当在场上多于两条蛇时引入礼貌模块。
总结
→ 📖 Q3.6(P) 请记录下目前的时间，并根据实际情况填写 附录A：基于 PSP 2.1 修改的 PSP 表格 的“实际耗时”栏目。
2025.04.05 ,19:37
→ 📖 Q3.7(I) 请写下本部分的心得体会。
感觉很有收获！
结对项目总结
结对过程回顾和反思
→ 📖 Q4.1(P) 提供两人在讨论的结对图像资料。
→ 📖 Q4.2(P) 回顾结对的过程，反思有哪些可以提升和改进的地方。
由于初次尝试结对编程，所以可能开始还是不太习惯，无论是时间的控制，还是思想上的讨论再到最后行动的贯彻执行，我们俩都还有很多需要磨合提升的地方。
→ 📖 Q4.3(I) 锐评一下你的搭档！并请至少列出三个优点和一个缺点。
优点：
- 资料查阅能力强
- 沟通能力不错
- 理解能力强
缺点：
- 时间控制能力有待提升
对结对编程的理解
→ 📖 Q4.4(I) 说明结对编程的优缺点、你对结对编程的理解。
优点在于能实时提升代码质量（通过即时复审减少错误）、促进知识共享（尤其利于新手成长）并增强团队协作能力；但缺点是可能增加短期人力成本（两人投入同一任务）且对开发者默契度要求较高。我认为结对编程并非适用于所有场景，但在复杂问题攻坚、关键技术传承或代码审查等情境下，它能通过“双人思维碰撞”显著降低设计盲区，长远来看反而可能提升整体效率，关键在于合理规划结对时机和人员组合。
代码实现提交
→ 📖 Q4.5(P) 请提供你们完成代码实现的代码仓库链接。
https://github.com/333sadads/PPsnake1
附录
附录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 | 合计 |
浙公网安备 33010602011771号