[P]结对项目：影蛇舞
结对项目：影蛇舞
Chapter.0 Belua multorum es capitums.（你是多首的怪物。）
引入
→ 📖 Q0.1(P) 请记录下目前的时间。
2025-03-25-14:45
调查
→ 📖 Q0.2(I) 作为本项目的调查：请如实标注在开始项目之前对 Wasm 的熟悉程度分级，可以的话请细化具体的情况。
I
I. 没有听说过；
II. 仅限于听说过相关名词；
III. 听说过，且有一定了解；
IV. 听说过，且使用 Wasm 实际进行过开发（即便是玩具项目的开发）。
总结
→ 📖 Q0.3(P) 请记录下目前的时间。
2025-03-25-16:18
Chapter.1 不畏迷茫，只管前进。（迷子でもいい、前へ進め。）
结对过程
→ 📖 Q1.1(P) 请记录下目前的时间。
2025-03-25-17：00
→ 📖 Q1.2(P) 请在完成任务的同时记录，并在完成任务后整理完善：
- 浏览任务要求，参照 附录A：基于 PSP 2.1 修改的 PSP 表格，估计任务预计耗时；
| Personal Software Process Stages | 个人软件开发流程 | 预估耗时（分钟） | 实际耗时（分钟） |
|---|---|---|---|
| PLANNING | 计划 | ||
| - Estimate | - 估计这个任务需要多少时间 | 5 | 5 |
| DEVELOPMENT | 开发 | ||
| - Analysis & Design Spec | - 需求分析 & 生成设计规格（确定要实现什么） | 10 | 12 |
| - Technical Background | - 了解技术背景（包括学习新技术） | 10 | 15 |
| - Coding Standard | - 代码规范 | 5 | 3 |
| - Design | - 具体设计（确定怎么实现） | 10 | 15 |
| - Coding | - 具体编码 | 30 | 25 |
| - Code Review | - 代码复审 | 5 | 6 |
| - Test Design | - 测试设计（确定怎么测，比如要测试哪些情景、设计哪些种类的测试用例） | 10 | 12 |
| - Test Implement | - 测试实现（设计/生成具体的测试用例、编码实现测试） | 20 | 10 |
| REPORTING | 报告 | ||
| - Quality Report | - 质量报告（评估设计、实现、测试的有效性） | 5 | 8 |
| - Size Measurement | - 计算工作量 | 5 | 3 |
| - Postmortem & Process Improvement Plan | - 事后总结和过程改进计划（总结过程中的问题和改进点） | 10 | 10 |
| TOTAL | 合计 | 125 | 124 |
- 完成编程任务期间，依次做了什么（比如查阅了什么资料，随后如何进行了开发，遇到了什么问题，又通过什么方式解决）；
了解Rust基本语法，阅读指导书相关需求，双方探讨是否对题目要求存在歧义（通过excel等工具模拟贪吃蛇一次移动，确认我们需要做的是给出较优的移动方向），达成编程共识，讨论具体实现方式，查询资料，了解贪吃蛇碰撞检测（主要是与自身身体碰撞检测）规则，随后对Rust函数设计与循环相关语法进行了解，开始正式结对编程流程。
在我们编写greedy_snake_move这一核心函数时，先是遇到的问题是，在防超界、防碰撞后找到可行移动策略后，如何寻找最优移动策略的。经过共同商讨，我们决定以移动策略是否能使小蛇靠近食物，作为判定最优策略的依据。
构建rust项目过程中，我们遇到了语法错误：bool类型和i32类型无法直接相加，我们通过i32::from()方式解决。
自行测试和提交测试过程中，我们发现自己的函数存在逻辑问题，即当小蛇受限制无法靠近食物时，会因为不存在”最优解“而错误输出，我们采用default默认值的方法，先找到一个可行解保底，再去探寻最优解。最后顺利通过了自行测试和提交测试
测试
→ 📖 Q1.3(P) 请说明针对该任务，你们设计和实现测试的方法及过程，包括但不限于：出于对需求的哪些考虑设计了哪些测试用例、如何评估所设计测试的有效性 等等。
设计测试，主要考虑边界问题和自身碰撞情况，在编写测试样例时，设计了头坐标位于方格四个顶角之一的位置，测试是否会出现超界现象，此外还设计目标果子位于头部不同方位（左上，左下，右上，右下），测试是否能做出正确的决断，在上述测试的基础上，通过改变初始身体位置坐标，测试若向预期方向移动会自身碰撞，是否能正确避开。
对于如何评估测试的有效性，我们是这样认为的，若测试程序可以覆盖全部代码分支，且样例运行结果合理，在移动方案合理的基础上，这样的测试设计是较为有效的。
比如在lib.rs的测试模块中，我们编造了五组数据，分别为正常情况、测试超界情况、测试首身碰撞情况、环形情况能否找到最优策略、环形情况能否避免首身碰撞。其中，环形的首尾衔接情况是比较特殊的情形，我们特意测试了这种特殊情况下能否找到移动的可行策略和最优策略。
→ 📖 Q1.4(I) 请说明单元测试对软件开发的作用。
单元测试是对最小单元的正确性进行检查，我认为它在软件开发中的作用主要是：
- 提升代码的整体质量，确保在构建过程中有阶段性检查，每个单元的正确性保证是提高代码整体质量的基础；
- 避免出现在开发中后期出现难以定位的bug，节省不必要的漏洞审查时间，提高开发的效率。
总结
→ 📖 Q1.5(P) 请记录下目前的时间，并根据实际情况填写 附录A：基于 PSP 2.1 修改的 PSP 表格 的“实际耗时”栏目。
2025-03-25-20：19
(项目在18：35-19：50期间暂停)
→ 📖 Q1.6(I) 请写下本部分的心得体会。
本阶段开始结对编程的正式尝试，我们正在逐步摸索和搭档交流与工作的合理模式，在初期还是习惯于“自己看自己想”，但是在正式编程前，因为是“两个人的代码”，需要先达成共识，我们很自然地开始分享自己对指导书要求的理解，出现差异后，我们也必须先找到一种方式表达清楚自己的看法、理解对方的想法，随后选择出我们都认可的方案并开始进一步执行。
在经过初期破冰之后，后面的交流就更加自然和密切，双方主动推进流程，同时提出建议（例如现在是不是应该先确定哪些情况是非法的？函数这样写会不会出现问题？），当然，建议也不是总会被采纳，这也是独立编程和结对编程的差异，在独立编程中，我"想什么"我就能"做什么"，然而在结对编程中，只有两个人都想做某件事，那么它才会被执行，我认为这是一种新奇的体验与收获，这让我学会如何在编程的过程中也实现“求同存异”，我觉得这对于我的能力是有帮助的。
总的来说，第一次的结对编程体验还是不错的，希望后面也一切顺利。
Chapter.2 即使迷茫，也要前行。（迷子でもいい、迷子でも進め。）
结对过程
→ 📖 Q2.1(P) 请记录下目前的时间。
2025-03-29-9：50
→ 📖 Q2.2(P) 请在完成任务的同时记录，并在完成任务后整理完善：
- 浏览任务要求，参照 附录A：基于 PSP 2.1 修改的 PSP 表格，估计任务预计耗时；
- 完成编程任务期间，依次做了什么（比如查阅了什么资料，随后如何进行了开发，遇到了什么问题，又通过什么方式解决）；
| Personal Software Process Stages | 个人软件开发流程 | 预估耗时（分钟） | 实际耗时（分钟） |
|---|---|---|---|
| PLANNING | 计划 | ||
| - Estimate | - 估计这个任务需要多少时间 | 5 | 3 |
| DEVELOPMENT | 开发 | ||
| - Analysis & Design Spec | - 需求分析 & 生成设计规格（确定要实现什么） | 15 | 20 |
| - Technical Background | - 了解技术背景（包括学习新技术） | 5 | 8 |
| - Coding Standard | - 代码规范 | 5 | 5 |
| - Design | - 具体设计（确定怎么实现） | 20 | 20 |
| - Coding | - 具体编码 | 40 | 80 |
| - Code Review | - 代码复审 | 15 | 10 |
| - Test Design | - 测试设计（确定怎么测，比如要测试哪些情景、设计哪些种类的测试用例） | 5 | 5 |
| - Test Implement | - 测试实现（设计/生成具体的测试用例、编码实现测试） | 15 | 15 |
| REPORTING | 报告 | ||
| - Quality Report | - 质量报告（评估设计、实现、测试的有效性） | 5 | 5 |
| - Size Measurement | - 计算工作量 | 5 | 5 |
| - Postmortem & Process Improvement Plan | - 事后总结和过程改进计划（总结过程中的问题和改进点） | 15 | 10 |
| TOTAL | 合计 | 150 | 188 |
2.首先，结对搭档阅读指导书，通过模拟游戏熟悉本次任务可能需要解决的问题，确保理解上不存在差异，随后认为了解迷宫问题算法对本次作业有帮助，所以对该算法进行了回顾，并且讨论该算法应用到本次任务中需要注意哪些问题、做哪些调整（例如起终点不是固定的，可能存在不可达情况等），在做完上述准备工作后，开始搭建算法框架，尝试实现。
开发过程中出现的主要问题是数据类型使用错误，特别是i32和usize的使用场景，出现报错，通过查询网络资料，我们得知wasm_bindgen不能直接处理固定大小的二维数组等限制，修改了相关代码，解决了问题。
其次，我们发现在考虑可行路径时，忽视了身体对于蛇的阻挡作用，于是对相关部分进行修改，我们认为，在合理移动的情况下，蛇头不能向第二节身体的方向移动，所以对移动方向进一步限制，解决了该问题。
代码可复用性与需求变更
→ 📖 Q2.3(P) 请说明针对该任务，你们对 🧑💻 T1 中已实现的代码进行了哪些复用和修改。
针对该任务，T1任务代码的可复用性并不高，在T1任务中，需要给出可移动的方向，我们主要是通过检测每个移动方向是否出现碰撞，是从排除非法的各种情况实现，而在该任务中，我们尝试找出一条可行的路径验证是否“可达”，我们是从考虑合法的情况入手，如果符合要求，才进行下一步移动。
→ 📖 Q2.4(I) 请说明在编码实现时，可以采取哪些设计思想、考虑哪些设计冗余，来提高既存代码适应需求变更的能力。
本次编码实现时，为提高既存代码适应需求变更的能力，运用到的最主要的方式是“参数化设计”，例如场地大小、障碍物个数等参数不采取硬编码的方式，而是通过参数化的方式配置，以适应可能存在的变更需求。此外，我们还做了必要的解耦，对逻辑独立、复用可能高的部分进行独立封装，预留合理接口，确保在需求变更时减少不必要的重复工作。
头脑风暴环节
**→ 📖 Q2.5(P) **只吃一个食物可满足不了贪吃蛇的欲望，请一起思考并简述以下场景中贪吃蛇的策略：
在 🧑💻 T2 的基础上，场地里不再是只有 1 个果子，而是总共有 n 个果子 (1 < n < 10 )，果子随机分布在场地中且不会刷新，保证不与障碍物重叠，保证每个果子均可达，且至少存在一条成功吃掉所有果子的路线，其余条件保持不变，请你找出一条吃完所有果子的行动路径。
对于多个果子的问题，bfs依旧可以找到可行路径，但需要改变：
-
吃到果子时不能立即返回，而是需要等所有果子都吃完后再返回。
-
visit数组维数需要增加，原本是相同位置的格子只能到达一次，现在应改成相同位置+相同果子状态的位置只能到达一次，即需要新增一维表示已经吃掉的果子集合。同时，bfs的队列也需要增加维数，原本的
(x, y, first_move, snake_body)需要增加已经吃掉的果子集合。
总结
→ 📖 Q2.6(P) 请记录下目前的时间，并根据实际情况填写 附录A：基于 PSP 2.1 修改的 PSP 表格 的“实际耗时”栏目。
2025-04-01-10：40
(项目的编程阶段在2025-03-29-9：50到12：18，项目的测试阶段在2025-04-01-10：00到10：40)
补充：2025-04-01-19：52，发现一个小bug在之前的测试中未测到，大概花了10分钟修复。今天是愚人节qaq程序大人不要跟我开玩笑了。
→ 📖 Q2.7(I) 请写下本部分的心得体会。
本部分的任务推进就没有那么顺利，我认为主要的问题是我们在“具体设计”上花的时间不足，导致在“具体编码”上花费的时间成倍增加，在独立编程时，我们只需要自我负责，而由于这次是结对编程，这样的失误给两个人带来的损失会更多，甚至会影响双方的情绪和信心，所以我认识到，既然是合作工作，那么在发现问题的苗头时（哪怕是不成熟的担忧）都要及时地提出，花一点时间讨论，在解决问题的同时加深我们对项目的理解共识。所以虽然项目并没有那么顺利地进行，但是还是让我们发现了结对编程中的一些问题，我认为这样的收获也是很有帮助的！
Chapter.3 这就是我的前进、到我出场了！！！！！（It's MyGO!!!!!）
结对过程
→ 📖 Q3.1(P) 请记录下目前的时间。
2025-04-05-10：40
→ 📖 Q3.2(P) 请在完成任务的同时记录，并在完成任务后整理完善：
- 浏览任务要求，参照 附录A：基于 PSP 2.1 修改的 PSP 表格，估计任务预计耗时；
- 完成编程任务期间，依次做了什么（比如查阅了什么资料，随后如何进行了开发，遇到了什么问题，又通过什么方式解决）；
| Personal Software Process Stages | 个人软件开发流程 | 预估耗时（分钟） | 实际耗时（分钟） |
|---|---|---|---|
| PLANNING | 计划 | ||
| - Estimate | - 估计这个任务需要多少时间 | 5 | 3 |
| DEVELOPMENT | 开发 | ||
| - Analysis & Design Spec | - 需求分析 & 生成设计规格（确定要实现什么） | 15 | 8 |
| - Technical Background | - 了解技术背景（包括学习新技术） | 10 | 0 |
| - Coding Standard | - 代码规范 | 5 | 4 |
| - Design | - 具体设计（确定怎么实现） | 40 | 20 |
| - Coding | - 具体编码 | 120 | 180 |
| - Code Review | - 代码复审 | 50 | 20 |
| - Test Design | - 测试设计（确定怎么测，比如要测试哪些情景、设计哪些种类的测试用例） | 15 | 5 |
| - Test Implement | - 测试实现（设计/生成具体的测试用例、编码实现测试） | 60 | 90 |
| REPORTING | 报告 | ||
| - Quality Report | - 质量报告（评估设计、实现、测试的有效性） | 10 | 8 |
| - Size Measurement | - 计算工作量 | 5 | 2 |
| - Postmortem & Process Improvement Plan | - 事后总结和过程改进计划（总结过程中的问题和改进点） | 5 | 5 |
| TOTAL | 合计 | 340 | 345 |
2.首先一起阅读了指导书关于Chapter3的内容，对于存活策略，我们先讨论了是得分重要还是活得久重要，形成了一个根据场上剩余蛇的数量调整策略的思想，但我们发现仅靠蛇的数目难以评估场上状况且最终需要以分数作为获胜依据，所以该策略的可使用性并不高，后续我们根据可选的方向数量有限且较少，认为可以给每个方向进行赋分（例如存在碰撞障碍物减100分，靠近果子则加分等），最终选取得分最高的方向进行返回，确定使用该方案后我们进行了较为详细的赋分讨论，得出了初步的较为完善的方案，开始进行代码的编写。开发过程中遇到的主要过程是对于输入参数的格式没有特别清楚，导致对数据的处理出现问题，产生报错，但通过查找相关说明，修改成了合理的方式。对于具体参数的确定上我们存在一些纠结，采取了不同参数的蛇进行对弈，选取了在30轮左右的比赛中表现较好的。
需求建模和算法设计
→ 📖 Q3.3(P) 请说明你们如何建模这一需求。
对于蛇蛇大作战这一问题，我们首先明确了各实体及其行为。比如蛇的属性包括坐标、存活状态，其行为是移动决策。果子的属性是坐标，其行为是被吃掉后每回合重置。场地的属性是大小和边界。接着，我们建模了游戏规则，包括碰撞规则（边界碰撞、自身碰撞、其他蛇碰撞），得分规则（吃果子），决策规则（上下左右移动方向）。最后，我们把实体的属性转换为编程中具体的状态，并用合适的数据结构存储，行为则会导致状态的转移更新。自此，我们建模完成，并在该模型基础上思考我们的算法。
→ 📖 Q3.4(P) 请说明针对该任务，你们采取了哪些策略来优化决策。具体而言，怎么避免死亡？怎么吃到更多果子？如何编程实现。
我们对蛇头可能行进的四个方向进行打分，最终选取了得分最高的方向作为我们选取的方向，具体来说：
对于踏入边界的方向-100=>避免死亡
对于会和自身/其他蛇碰撞的方向-100=>避免死亡
对于其他蛇可能行进的方向，我们根据其他蛇可选择的方向数（排除掉一定发生碰撞的方向后剩余的方向总数）进行适当减分，例如，如果该方向是其他蛇唯一可选的行进方向，则该方向-100，若其他蛇有更多可选择的行进方向，则减掉的分数会适当减小=>避免死亡
如果移动后两条蛇蛇头的距离过近，进行适当减分，避免后续移动可能发生的碰撞=>避免死亡
如果往该方向走会靠近某个果子，我们以果子为单位进行加分=>吃到更多果子
如果该方向附近有很近的果子，对该方向根据距离远近进行加分，防止出现抛弃了近处的少数果子，而往远处较多果子的方向移动=>吃到更多果子
编程实现：对于四个方向，计算朝该方向移动后新蛇头的位置，初始化分数为0分，随后通过简单的if函数检测是否发生绝对碰撞，加减分数，对于是否靠近果子，我们是通过比较移动前后相对于果子的距离实现的。
软件度量
→ 📖 Q3.5(P) 请说明你们如何量度所实现的程序模块的有效性，例如：“如何说明我们的程序模块对弈能力很强？”尝试提出一些可能的定量分析方式。
首先比较直观的衡量方式是胜率、平均得分、存活率。我们通过和别的组的蛇蛇进行1v1或4蛇大乱斗，观察我们组的胜率（获胜次数/总对弈次数）、平均得分（总得分/总对弈次数）、存活率（存货次数/总对弈次数），以此为依据考察模块的对弈能力，修改我们的赋分数值，在吃到果子和存活下来这两个目标中找到更合适的临界点数值。
其次我们也进行了鲁棒性测试，在不同的初始条件和随机种子下，测试我们的模块性能是否稳定。具体也是体现在胜率、平均得分、存活率等上是否有较大变化，定量的可以通过标准差和方差来衡量。
最后，我们考虑到决策时间也是对弈能力较为重要的一环，因此计算了每回合平均决策时间（总决策时间/总回合数），较短的决策时间表明模块效率较高，能够在短时间内做出合理的决策。
总结
→ 📖 Q3.6(P) 请记录下目前的时间，并根据实际情况填写 附录A：基于 PSP 2.1 修改的 PSP 表格 的“实际耗时”栏目。
2025/4/5 22：15
具体说明：我们结对时间分为三段，2025/4/5 10：40-12:50，2025/4/5 15：35-17：40，2025/4/5 8：45-22：15
→ 📖 Q3.7(I) 请写下本部分的心得体会。
虽然本部分的工作量更大一些，但是进展也算是比较顺利，可以说是充分吸取了第二次作业的教训，分析到比较成熟的情况才开始动手构建，所以没有出现很大的差错，到后期的配合也越来越默契。可以说，在这个阶段，慢慢体会到相较于一个人独立编程，结对编程独特的乐趣，也不同于大团体下大家各司其职，结对编程确实像主、副机长，虽然操作行为上略有区别，但共同对全机舱人员的生命负责。所以，本部分收获了很不错的结对体验，双方能够及时查缺补漏、提出建议、高效推进，最终圆满完结~
结对项目总结
结对过程回顾和反思
→ 📖 Q4.1(P) 提供两人在讨论的结对图像资料。
→ 📖 Q4.2(P) 回顾结对的过程，反思有哪些可以提升和改进的地方。
在结对过程中，我们认为在代码实现前先形成统一清晰的思路是很重要的。在Chapter2中我们没有完全想清楚算法思路，就匆忙开始编程，导致后面测试环节频繁出现逻辑上的问题，大大降低了结对效率。因此我们认识到先讨论，形成优质的、清晰的思路，再编程会事半功倍，这也是结对编程的优势所在。
→ 📖 Q4.3(I) 锐评一下你的搭档！并请至少列出三个优点和一个缺点。
在整个结对编程的过程中，我和我的搭档慢慢变得熟悉，我认为我的搭档非常负责，对于我们的作业都很上心，在沟通上也很积极，会想到很多代码可能存在的问题，包括这段时间我在时间上比较紧张，身体上也出现一些小状况，我的搭档也一直非常理解，在照顾了我的时间安排的情况下合理组织了我们的结对任务，只能说非常感谢！
如果硬要说缺点的话，那可能是我们俩都无法支撑长时间的思考与工作，导致每一部分的时间都不是整块的，人之常情，人之常情。
对结对编程的理解
→ 📖 Q4.4(I) 说明结对编程的优缺点、你对结对编程的理解。
结对编程让思考的头脑从一个变成了两个，但是，1+1的结果是大于/等于/小于2则取决于不同的合作模式。如果两个人能够互补共进，那么结对编程会是一件高效率、优体验的事情，但是两个人总是争锋相对、以自我为主，那么多一个搭档反而会成为累赘。所以，我认为结对编程需要你充分相信、认可你的搭档，一定没有两个人是完美合适的，只有建立在沟通和理解上，结对编程才能够发挥它的优势。
浙公网安备 33010602011771号