[P] 结对项目：影蛇舞
结对项目：影蛇舞
Chapter.0 Belua multorum es capitums.（你是多首的怪物。）
引入
*→* *📖* *Q0.1(P) 请记录下目前的时间。*
2025/3/20 14：15
调查
*→* *📖* *Q0.2(I) 作为本项目的调查：请如实标注在开始项目之前对 Wasm 的熟悉程度分级，可以的话请细化具体的情况。*
I. 没有听说过；
II. 仅限于听说过相关名词；
III. 听说过，且有一定了解；
IV. 听说过，且使用 Wasm 实际进行过开发（即便是玩具项目的开发）。
I. 没有听说过；
总结
wasm-pack build --target nodejs打包时遇到了诸多问题
Error: failed to download from https://github.com/WebAssembly/binaryen/releases/download/version_111/binaryen-version_111-x86_64-windows.tar.gz
需要自行下载binaryen并加入到环境变量path。（https://juejin.cn/post/7327937033321070604）。
error occurred in cc-rs: failed to find tool "gcc.exe": program not found (see https://docs.rs/cc/latest/cc/#compile-time-requirements for help)
需要配置mingw64环境。等等
Installing wasm-bindgen...处卡住
需要下载wasm-bindgen-cli，需要管理员权限运行命令行等
思考题R1：cdylib 表示生成一个 *C兼容的动态链接库*，其核心目的是让编译后的代码能够通过 *C ABI（应用二进制接口）* 被其他语言（如C/C++、Python、Node.js等）调用。
思考题R2：发现删去注释之后缺少函数信息，推测添加注释#[wasm_bindgen]能生成对应的JavaScript接口，使其能调用rust中的函数
*→* *📖* *Q0.3(P) 请记录下目前的时间。*
2025/3/20 16:01
Chapter.1 不畏迷茫，只管前进。（迷子でもいい、前へ進め。）
结对过程
*→* *📖* *Q1.1(P) 请记录下目前的时间。*
2025/3/20 16：17 开始
*→* *📖* *Q1.2(P) 请在完成任务的同时记录，并在完成任务后整理完善：*
浏览任务要求，参照 *附录A：基于 PSP 2.1 修改的 PSP 表格*，估计任务预计耗时；
完成编程任务期间，依次做了什么（比如查阅了什么资料，随后如何进行了开发，遇到了什么问题，又通过什么方式解决）；
| *Personal Software Process Stages* | *个人软件开发流程* | *预估耗时（分钟）* | *实际耗时（分钟）* |
|---|---|---|---|
| *PLANNING* | *计划* | ||
| - Estimate | - 估计这个任务需要多少时间 | 2 | 2 |
| *DEVELOPMENT* | *开发* | ||
| - Analysis & Design Spec | - 需求分析 & 生成设计规格（确定要实现什么） | 5 | 5 |
| - Technical Background | - 了解技术背景（包括学习新技术） | 40 | 20 |
| - Coding Standard | - 代码规范 | 5 | 5 |
| - Design | - 具体设计（确定怎么实现） | 10 | 10 |
| - Coding | - 具体编码 | 40 | 43 |
| - Code Review | - 代码复审 | 5 | 5 |
| - Test Design | - 测试设计（确定怎么测，比如要测试哪些情景、设计哪些种类的测试用例） | 5 | 5 |
| - Test Implement | - 测试实现（设计/生成具体的测试用例、编码实现测试） | 10 | 10 |
| *REPORTING* | *报告* | ||
| - Quality Report | - 质量报告（评估设计、实现、测试的有效性） | 3 | 3 |
| - Size Measurement | - 计算工作量 | 5 | 5 |
| - Postmortem & Process Improvement Plan | - 事后总结和过程改进计划（总结过程中的问题和改进点） | 10 | 13 |
| *TOTAL* | *合计* | 140 | 124 |
- 我们仔细阅读了课程组给出的题目要求，经过讨论完成了程序设计；
- 参考rust菜鸟教程、rust官方文档和网上的若干rust资料，完成了程序实现；
- 在程序编译过程中，一开始忘记添加
#[wasm_bidgen]导致没有成功导出greedy_snake_move()函数； - 忽略了rust的基于表达式特性，导致函数返回值部分逻辑有问题，编译报错，查阅资料后修改正确；
- 最后编写了单元测试函数。
测试
*→* *📖* *Q1.3(P) 请说明针对该任务，你们设计和实现测试的方法及过程，包括但不限于：出于对需求的哪些考虑设计了哪些测试用例、如何评估所设计测试的有效性 等等。*
主要考虑碰撞检测（即，移动后不能出现碰到蛇身/边界），设计了三个测试用例。具体实现上使用了rust中的测试函数，即通过#[test]属性和宏assert_ne！完成测试
*→* *📖* *Q1.4(I) 请说明 单元测试 对软件开发的作用。*
- 单元测试可以帮助我们在早期以较低的代价发现bug；
- 单元测试保证了代码在迭代过程中正确性：在每次修改代码后，都可以随时通过单元测试验证正确性，并迅速定位bug位置；
- 单元测试从另一个角度督促开发者遵循良好的设计原则，使代码的耦合程度低。
总结
*→* *📖* *Q1.5(P) 请记录下目前的时间，并根据实际情况填写 附录A：基于 PSP 2.1 修改的 PSP 表格 的“实际耗时”栏目。*
2025/3/20 18：00
*→* *📖* *Q1.6(I) 请写下本部分的心得体会。*
非常好结对提高工作效率！通过讨论可以规避大部分对题意理解不正确的地方，也避免了阅读的遗漏；在编程时，领航员和代码手实现了“手”和“脑”的分离，领航员口述思路、实时复审代码、帮助查找资料，让代码手能够集中精力完成代码实现（充分解决了一遍写一遍想cpu不够的问题）
Chapter.2 即使迷茫，也要前行。（迷子でもいい、迷子でも進め。）
结对过程
*→* *📖* *Q2.1(P) 请记录下目前的时间。*
2025/4/1 14：50
*→* *📖* *Q2.2(P) 请在完成任务的同时记录，并在完成任务后整理完善：*
浏览任务要求，参照 *附录A：基于 PSP 2.1 修改的 PSP 表格*，估计任务预计耗时；
完成编程任务期间，依次做了什么（比如查阅了什么资料，随后如何进行了开发，遇到了什么问题，又通过什么方式解决）；
| *Personal Software Process Stages* | *个人软件开发流程* | *预估耗时（分钟）* | *实际耗时（分钟）* |
|---|---|---|---|
| *PLANNING* | *计划* | ||
| - Estimate | - 估计这个任务需要多少时间 | 5 | 5 |
| *DEVELOPMENT* | *开发* | ||
| - Analysis & Design Spec | - 需求分析 & 生成设计规格（确定要实现什么） | 10 | 10 |
| - Technical Background | - 了解技术背景（包括学习新技术） | 10 | 10 |
| - Coding Standard | - 代码规范 | 0 | 0 |
| - Design | - 具体设计（确定怎么实现） | 30 | 120 |
| - Coding | - 具体编码 | 120 | 112 |
| - Code Review | - 代码复审 | 10 | 110 |
| - Test Design | - 测试设计（确定怎么测，比如要测试哪些情景、设计哪些种类的测试用例） | 10 | 10 |
| - Test Implement | - 测试实现（设计/生成具体的测试用例、编码实现测试） | 5 | 5 |
| *REPORTING* | *报告* | ||
| - Quality Report | - 质量报告（评估设计、实现、测试的有效性） | 2 | 2 |
| - Size Measurement | - 计算工作量 | 2 | 2 |
| - Postmortem & Process Improvement Plan | - 事后总结和过程改进计划（总结过程中的问题和改进点） | 5 | 5 |
| *TOTAL* | *合计* | 209 | 391 |
- 阅读题目需求，明确在T1基础上增加了障碍物，由此引发对果子可获得性的判定；
- 将该问题转化为迷宫问题，通过bfs搜索最短路径进行求解，完成了基础版不能掉头的蛇；
- 构建测试样例时发现，基础的bfs搜索忽视了蛇转身的情况，使得蛇通过重复路径后转身吃到果子这一情况不能被bfs搜索。后续对该情况进行修正，即首选bfs搜索到的路径，当无法搜索到时，选择一个最大自由度（即后续可走路最多）的方向乱爬，并限制最大步数，每一步模拟后均检查是否存在bfs路径；若仍无法找到路径，则返回-1
- 在构建特殊测试样例报错时，发现了对题目理解上的错误。蛇是可以一直原地打转绕行的，也就是说对蛇身的判定，只要不向第一截蛇身的方向爬行即可。由于这个理解错误，前面的设计实际上过于复杂和没有必要了（）但是由于时间问题，我们仅针对正确性做了修改，没有精力再优化算法了TT
代码可复用性与需求变更
*→* *📖* *Q2.3(P) 请说明针对该任务，你们对* ***\*🧑💻\****`` ***\*T2\**** *中已实现的代码进行了哪些复用和修改。*
复用了T1中对场地边界和蛇身的碰撞检测
T1中的输入保障了蛇对果子的可获得性，而由于T2中增加了障碍物需要判断蛇是否吃到果子。因此先使用考虑蛇身为障碍物的bfs搜索查找bfs路径，如果不存在，再运行最大步数为50的模拟，每一步模拟后均检查是否存在bfs路径，存在则认为可达，返回记录的第一步方向；若50步后（或者进入死胡同）仍无法找到路径则返回-1。
*→* *📖* *Q2.4(I) 请说明在编码实现时，可以采取哪些 设计思想 、考虑哪些 设计冗余 ，来提高既存代码适应需求变更的能力。*
设计思想：可以通过分层设计（如蛇的生存逻辑和得分逻辑分离）封装易变逻辑，将可能调整的部分限制在独立模块中，降低改动波及范围。
设计冗余：可以考虑后续可能新增的部分，设计一些适配性方面的冗余，例如对函数的参数输入做冗余设计，增强可拓展性，降低后续迭代的难度。
头脑风暴环节
**→ 📖 Q2.5(P) **只吃一个食物可满足不了贪吃蛇的欲望，请一起思考并简述以下场景中贪吃蛇的策略：
*在* 🧑💻 T2 *的基础上，场地里不再是只有 1 个果子，而是总共有 n 个果子 (1 < n < 10 )，果子随机分布在场地中且不会刷新，保证不与障碍物重叠，保证每个果子均可达，且至少存在一条成功吃掉所有果子的路线，其余条件保持不变，请你找出一条吃完所有果子的行动路径。*
或许可以使用多目标点路径规划的蚁群+A*算法。（或者邀请美团外卖骑手口述一下外卖算法罢）
总结
*→* *📖* *Q2.6(P) 请记录下目前的时间，并根据实际情况填写 附录A：基于 PSP 2.1 修改的 PSP 表格 的“实际耗时”栏目。*
2025/4/1 2025/4/1 14：50 ~ 17：42 第一次（基础的不能掉头的bfs蛇）
2025/4/2 09：00开始 ~10：36 结束第二次（实现了蛇的掉头）（修复了关于蛇不能原地打转的错误认知）
2025/4/2 10：40测试时发现新bug ~11：24 结束debug
*→* *📖* *Q2.7(I) 请写下本部分的心得体会。*
虽然知道应当是有更优雅算法的，但是乱爬也不失为一种解决方案
Chapter.3 这就是我的前进、到我出场了！！！！！（It's MyGO!!!!!）
结对过程
*→* *📖* *Q3.1(P) 请记录下目前的时间。*
2025/4/2 11：40 绝望开始
2025/4/2 12：20 看完题目，第一轮策略讨论结束
2025/4/2 14：30-15：00 进行了一些可能的实现方案调研
2025/4/2 18：30 开始实现
2025/4/2 21：00 开始测试，尝试改进
2025/4/2 22：35 结束
*→* *📖* *Q3.2(P) 请在完成任务的同时记录，并在完成任务后整理完善：*
浏览任务要求，参照 *附录A：基于 PSP 2.1 修改的 PSP 表格*，估计任务预计耗时；
完成编程任务期间，依次做了什么（比如查阅了什么资料，随后如何进行了开发，遇到了什么问题，又通过什么方式解决）；
| *Personal Software Process Stages* | *个人软件开发流程* | *预估耗时（分钟）* | *实际耗时（分钟）* |
|---|---|---|---|
| *PLANNING* | *计划* | ||
| - Estimate | - 估计这个任务需要多少时间 | 5 | 5 |
| *DEVELOPMENT* | *开发* | ||
| - Analysis & Design Spec | - 需求分析 & 生成设计规格（确定要实现什么） | 30 | 40 |
| - Technical Background | - 了解技术背景（包括学习新技术） | 10 | 10 |
| - Coding Standard | - 代码规范 | 0 | 0 |
| - Design | - 具体设计（确定怎么实现） | 40 | 60 |
| - Coding | - 具体编码 | 120 | 110 |
| - Code Review | - 代码复审 | 80 | 90 |
| - Test Design | - 测试设计（确定怎么测，比如要测试哪些情景、设计哪些种类的测试用例） | 30 | 0 |
| - Test Implement | - 测试实现（设计/生成具体的测试用例、编码实现测试） | 30 | 0 |
| *REPORTING* | *报告* | ||
| - Quality Report | - 质量报告（评估设计、实现、测试的有效性） | 5 | 5 |
| - Size Measurement | - 计算工作量 | 5 | 0 |
| - Postmortem & Process Improvement Plan | - 事后总结和过程改进计划（总结过程中的问题和改进点） | 5 | 5 |
| *TOTAL* | *合计* | 360 | 315 |
- 查阅资料发现A*算法
- 口头讨论了一些改进策略并实现了代码
- 改进了障碍检测（因为发现我们的蛇常常提前暴死）
需求建模和算法设计
*→* *📖* *Q3.3(P) 请说明你们如何 建模 这一需求。*
我们认为需求可以概括为：综合考虑得分（果子位置）和生存（它蛇位置），完成蛇的单回合方向决策，以达到最大化该局游戏得分的目的。
该需求可以分为两部分：得分和生存。我们考虑到：如果一味的采取避让策略，尽管存在生存优势但可能无法在得分上胜出；如果一味的冒风险争取果子，则可能过早死亡导致得分时间被压缩。因此，我们认为应当综合考虑这些因素，采取根据当前状况打分的方式，实现更为灵活的决策。
*→* *📖* *Q3.4(P) 请说明针对该任务，你们采取了 哪些策略 来优化决策。具体而言，怎么避免死亡？怎么吃到更多果子？如何编程实现。*
- 避免死亡：最基础的单步碰撞检测（若碰撞直接否决方向） + 动态障碍物预测+洪水填充算法评估方向的安全系数
- 吃到更多果子：首先考虑是否存在果子，在多蛇对这个果子的竞争上自己有绝对优势（绝对最近，在其它蛇不可能过来的时候就能吃到），如果存在直接确定方向；然后综合评估该方向最近的果子距离（往这里走可能最快吃到这个果子） + 附近果子个数（往这里走吃完果子之后可以少绕路）
编程实现上，我们注意到A路径规划算法中存在路径的代价评估机制，因此考虑在A算法的基础上对评估机制进行改进实现我们的程序。
软件度量
*→* *📖* *Q3.5(P) 请说明你们如何量度所实现的程序模块的有效性，例如：“如何说明我们的程序模块对弈能力很强？”尝试提出一些可能的定量分析方式。*
我们写了两个版本的蛇，分别命名为简单蛇（只考虑吃最近果子和基础碰撞）和复杂蛇（按照上述策略），在4蛇游戏中统计了得分，具体得分如下：
| 轮次 | 复杂蛇1 | 复杂蛇2 | 简单蛇2 | 简单蛇2 |
|---|---|---|---|---|
| 1 | 18 | 28 | 1 | 10 |
| 2 | 3 | 18 | 4 | 6 |
| 3 | 8 | 6 | 2 | 1 |
| 4 | 12 | 27 | 1 | 15 |
| 5 | 32 | 17 | 13 | 6 |
| 6 | 4 | 1 | 4 | 1 |
| 7 | 9 | 15 | 2 | 5 |
| 8 | 54 | 21 | 4 | 10 |
| 均分 | 17.5 | 16.625 | 3.5 | 6.75 |
最终选择了复杂蛇，并证明复杂蛇的对弈能力更强
总结
*→* *📖* *Q3.6(P) 请记录下目前的时间，并根据实际情况填写 附录A：基于 PSP 2.1 修改的 PSP 表格 的“实际耗时”栏目。*
2025/4/2 22：35
*→* *📖* *Q3.7(I) 请写下本部分的心得体会。*
非常好题目使我大脑爆炸（bushi
在这部分其实最大的体会是：过于复杂的软件设计往往不利于软件实现。关于这部分题目，我们在最初的讨论过程中设想了很多策略，例如：我们构想了激进蛇，在两蛇对战时适当采取同归于尽策略；构想了非常复杂的打分策略，但是最终没有实现（x）
另一个体会是结对编程确实很能提高效率；如果是自己单独做这个题目的话可能就在过程中淡淡的崩溃了，或者常常摸鱼休息导致巨大拖延，但是搭子的互相支持和督促能提供更多的动力和专注
结对项目总结
结对过程回顾和反思
*→* *📖* *Q4.1(P) 提供两人在讨论的结对图像资料。*
*→* *📖* *Q4.2(P) 回顾结对的过程，反思有哪些可以提升和改进的地方。*
- 两个人都不熟悉wasm和rust，而查阅菜鸟教程和官方文档等往往耗时过多，编译也出现很多问题和bug，在t1和t2开始之后因为效率原因还是投入了deepseek老师的怀抱。
- 由于没有准备private远程仓库，我们的所有代码编写都在一台机器上完成，导致领航员和编程手的角色转换上存在一些障碍（用不习惯对方的电脑键盘）
- 实际上后期还是出现了许多微信发文件的原始操作（x）
- 接上文，由于没有采用git的优雅合作，我们的版本管理变得十分复杂，特别是在t3评测多蛇对战的时候，经常分不清楚哪个文件是什么版本，给测试带来了麻烦
*→* *📖* *Q4.3(I) 锐评一下你的搭档！并请至少列出三个优点和一个缺点。*
优点
- 很细心！阅读材料的时候很细致
- 情绪很稳定，沟通能力强
- 能在双方意见不一致/有不理解问题的时候耐心解释清楚
缺点
- 那就只有对rust不熟练了
对结对编程的理解
*→* *📖* *Q4.4(I) 说明结对编程的优缺点、你对结对编程的理解。*
优点：随时复审，手脑分离，提高效率的同时避免了很多bug的出现
缺点：对场地和沟通能力要求高，需要两个人都能清晰表达和耐心倾听，出现问题不甩锅，互相理解共同解决
我的理解：双剑合璧！在迷茫中也能坚持前行
浙公网安备 33010602011771号