[P]结对项目：影蛇舞
结对项目：博客问题清单
请将本文件在代码仓库外复制一份，一边阅读和完成结对项目、一边填写入代码仓库外的版本，或采取简记、语音备忘等方式记载较复杂问题的要点之后再补充。请不要将本文档内的作答提交到代码仓库。
Chapter.0 Belua multorum es capitums.（你是多首的怪物。）
引入
→ 📖 Q0.1(P) 请记录下目前的时间。
3月26日14点
调查
→ 📖 Q0.2(I) 作为本项目的调查：请如实标注在开始项目之前对 Wasm 的熟悉程度分级，可以的话请细化具体的情况。
I. 没有听说过；
II. 仅限于听说过相关名词；
III. 听说过，且有一定了解；
IV. 听说过，且使用 Wasm 实际进行过开发（即便是玩具项目的开发）。
II. 仅限于听说过相关名词。听说过Wasm，知道可以通过C/Rust等高级语言编译成Wasm。
总结
→ 📖 Q0.3(P) 请记录下目前的时间。
3月26日14点20分
Chapter.1 不畏迷茫，只管前进。（迷子でもいい、前へ進め。）
结对过程
→ 📖 Q1.1(P) 请记录下目前的时间。
3月26日14点20分
→ 📖 Q1.2(P) 请在完成任务的同时记录，并在完成任务后整理完善：
- 浏览任务要求，参照 附录A：基于 PSP 2.1 修改的 PSP 表格，估计任务预计耗时；
- 完成编程任务期间，依次做了什么（比如查阅了什么资料，随后如何进行了开发，遇到了什么问题，又通过什么方式解决）；
- 查阅贪吃蛇游戏的策略算法，将贪吃蛇问题建模成一个图论里的两点间最短路径问题
- 为了方便解决后续引入障碍物的情况，我们使用了A*算法求解这个问题
- 在设计测试样例时，我们使用了random库来随机生成数据，但是在构建为wasm时会出现问题，排查后发现是使用了random，因此我们写了一个简单的random工具类
- 对蛇身碰撞理解有问题，在通过仓库提供的测试用例时，有两个用例我们的代码会找不到路径返回空。在打包成wasm后报错信息为访问错误地访问了某块内存，非常难调试，最后用rust跑样例才发现了问题。
测试
→ 📖 Q1.3(P) 请说明针对该任务，你们设计和实现测试的方法及过程，包括但不限于：出于对需求的哪些考虑设计了哪些测试用例、如何评估所设计测试的有效性 等等。
测试方案参考了仓库中的js代码greedy_snake_fn_checker ，通过模拟一整局游戏来进行测试，如果最后能安全吃到果子则视为通过。
在测试样例设计上，主要考虑蛇会不会发生碰撞导致死亡，因此设计了如下场景：
- 蛇初始位置在棋盘边缘，果子位置在棋盘角落
- 蛇初始位置在棋盘边缘，果子在蛇身边
- 蛇初始卷成一个田字形，果子的位置离蛇较远
→ 📖 Q1.4(I) 请说明单元测试对软件开发的作用。
单元测试是指对软件中的最小可用单元进行检查和验证，单元测试通过对软件中的最小可测试单元（如函数、方法或类）进行验证，确保每个单元的功能无误，从而在早期发现并修复代码缺陷，提高代码的质量和稳定性。此外，在敏捷开发模式下，单元测试能够提供即时反馈，缩短开发周期，通过自动化测试，开发者可以在每次提交或构建后快速验证代码变更的效果，减少人工审查和回归测试的工作量。
总结
→ 📖 Q1.5(P) 请记录下目前的时间，并根据实际情况填写 附录A：基于 PSP 2.1 修改的 PSP 表格 的“实际耗时”栏目。
3月26日18点50分
| Personal Software Process Stages | 个人软件开发流程 | 预估耗时（分钟） | 实际耗时（分钟） |
|---|---|---|---|
| PLANNING | 计划 | 5 | 5 |
| - Estimate | - 估计这个任务需要多少时间 | 5 | 5 |
| DEVELOPMENT | 开发 | 120 | 130 |
| - Analysis & Design Spec | - 需求分析 & 生成设计规格（确定要实现什么） | 10 | 10 |
| - Technical Background | - 了解技术背景（包括学习新技术） | 15 | 20 |
| - Coding Standard | - 代码规范 | 5 | 5 |
| - Design | - 具体设计（确定怎么实现） | 20 | 15 |
| - Coding | - 具体编码 | 45 | 50 |
| - Code Review | - 代码复审 | 5 | 5 |
| - Test Design | - 测试设计（确定怎么测，比如要测试哪些情景、设计哪些种类的测试用例） | 5 | 5 |
| - Test Implement | - 测试实现（设计/生成具体的测试用例、编码实现测试） | 15 | 20 |
| REPORTING | 报告 | 20 | 15 |
| - Quality Report | - 质量报告（评估设计、实现、测试的有效性） | 5 | 5 |
| - Size Measurement | - 计算工作量 | 5 | 5 |
| - Postmortem & Process Improvement Plan | - 事后总结和过程改进计划（总结过程中的问题和改进点） | 10 | 5 |
| TOTAL | 合计 | 145 | 150 |
→ 📖 Q1.6(I) 请写下本部分的心得体会。
这是结对编程的第一章，我和队友初步进入结对编程的编程模式下还有些不适应。我作为驾驶员的时候小心谨慎如履薄冰，非常怕我身边的领航员指出我写出了bug，写了一个多小时就非常红温了......作为结对项目的第一章，我和队友经过磨合进入到了结对编程的模式中，收获颇丰。
Chapter.2 即使迷茫，也要前行。（迷子でもいい、迷子でも進め。）
结对过程
→ 📖 Q2.1(P) 请记录下目前的时间。
3月26日20点
→ 📖 Q2.2(P) 请在完成任务的同时记录，并在完成任务后整理完善：
- 浏览任务要求，参照 附录A：基于 PSP 2.1 修改的 PSP 表格，估计任务预计耗时；
- 完成编程任务期间，依次做了什么（比如查阅了什么资料，随后如何进行了开发，遇到了什么问题，又通过什么方式解决）；
首先我们在第一题的基础上分析引入障碍物后寻路算法需要做出哪些改变，讨论后发现只需要修改碰撞检测代码，其他地方不需要更改，然后在T1代码的基础上对接口进行调整，专门处理输入数据，尽可能复用代码。
代码可复用性与需求变更
→ 📖 Q2.3(P) 请说明针对该任务，你们对 🧑💻 T1 中已实现的代码进行了哪些复用和修改。
相比于T1，T2需要考虑障碍物对路径规划的影响。由于T1采用的算法可以支持有障碍物的场景，因此我们只需要在碰撞检测代码colision_check加入一个参数obstacles表示障碍物，在实现时新增判断下一个移动方向会不会与障碍物重合即可。这样就完成了算法部分。
接下来是需要适配新的接口，蛇位置的传入方式发生了变化，我们希望可以尽可能减少更改，因此借鉴了设计模式中的适配器模式思想，新增一个函数process_input用来处理输入，转化成T1的形式。
→ 📖 Q2.4(I) 请说明在编码实现时，可以采取哪些设计思想、考虑哪些设计冗余，来提高既存代码适应需求变更的能力。
一些经典的设计思想：
- SOLID原则：
- 单一职责原则（SRP）：每个类/模块只负责一个功能
- 开闭原则（OCP）：允许扩展代码，不允许修改代码
- 里氏替换原则（LSP）：子类能无条件替换父类
- 接口隔离原则（ISP）：客户端不应依赖不需要的接口，减少依赖链的复杂性
- 依赖倒置原则（DIP）：高层模块不依赖底层模块
- 策略模式：将算法封装为独立类
- 工厂模式：通过工厂方法创建对象
- 分层架构设计：通过分层隔离变更影响
设计冗余：
- 可配置化冗余：参数动态化
- 接口抽象冗余：增加适配器层
- 版本控制冗余：API版本化
头脑风暴环节
**→ 📖 Q2.5(P) **只吃一个食物可满足不了贪吃蛇的欲望，请一起思考并简述以下场景中贪吃蛇的策略：
在 🧑💻 T2 的基础上，场地里不再是只有 1 个果子，而是总共有 n 个果子 (1 < n < 10 )，果子随机分布在场地中且不会刷新，保证不与障碍物重叠，保证每个果子均可达，且至少存在一条成功吃掉所有果子的路线，其余条件保持不变，请你找出一条吃完所有果子的行动路径。
枚举每个果子，作为第一次行动的目标，吃到第一颗果子后，枚举剩下的四个果子作为第二次行动的目标，重复上述过程，直到吃到果子。
过程中可能会出现有一颗果子位于死路中，也就是吃到这颗果子后就无法行动，由于必然存在一条可以吃完所有果子的路线，这样的果子至多存在一个，我们只需要把这样的果子放在最后一个吃就可以了。
总结
→ 📖 Q2.6(P) 请记录下目前的时间，并根据实际情况填写 附录A：基于 PSP 2.1 修改的 PSP 表格 的“实际耗时”栏目。
3月30日14点10分
| Personal Software Process Stages | 个人软件开发流程 | 预估耗时（分钟） | 实际耗时（分钟） |
|---|---|---|---|
| PLANNING | 计划 | 5 | 5 |
| - Estimate | - 估计这个任务需要多少时间 | 5 | 5 |
| DEVELOPMENT | 开发 | 115 | 95 |
| - Analysis & Design Spec | - 需求分析 & 生成设计规格（确定要实现什么） | 5 | 5 |
| - Technical Background | - 了解技术背景（包括学习新技术） | 5 | 5 |
| - Coding Standard | - 代码规范 | 5 | 5 |
| - Design | - 具体设计（确定怎么实现） | 10 | 5 |
| - Coding | - 具体编码 | 30 | 25 |
| - Code Review | - 代码复审 | 10 | 5 |
| - Test Design | - 测试设计（确定怎么测，比如要测试哪些情景、设计哪些种类的测试用例） | 5 | 5 |
| - Test Implement | - 测试实现（设计/生成具体的测试用例、编码实现测试） | 45 | 40 |
| REPORTING | 报告 | 15 | 15 |
| - Quality Report | - 质量报告（评估设计、实现、测试的有效性） | 5 | 5 |
| - Size Measurement | - 计算工作量 | 5 | 5 |
| - Postmortem & Process Improvement Plan | - 事后总结和过程改进计划（总结过程中的问题和改进点） | 5 | 5 |
| TOTAL | 合计 | 135 | 115 |
→ 📖 Q2.7(I) 请写下本部分的心得体会。
这是结对编程的第二章，我和队友已经对结对编程的模式轻车熟路，一个人充当领航员，一个让人充当驾驶员。这次编写代码的时间不长，我作为驾驶员写代码，领航员对我的代码进行review并补充测试用例，在轻松愉快中结束。
Chapter.3 这就是我的前进、到我出场了！！！！！（It's MyGO!!!!!）
结对过程
→ 📖 Q3.1(P) 请记录下目前的时间。
3月30日14点30分
→ 📖 Q3.2(P) 请在完成任务的同时记录，并在完成任务后整理完善：
- 浏览任务要求，参照 附录A：基于 PSP 2.1 修改的 PSP 表格，估计任务预计耗时；
- 完成编程任务期间，依次做了什么（比如查阅了什么资料，随后如何进行了开发，遇到了什么问题，又通过什么方式解决）；
首先我们在网上查找资料，考虑使用机器学习解决问题。之后搜索了在Rust上运行机器学习模型的资料，认为工作量太大无法顺利完成，决定采用朴素的算法来解决，每次优先保证不装到对方和墙壁，在此基础上贪心地吃最近的果子，这样可以高度复用T2代码，无需进行太多修改。
在初步设计完策略完成代码后进行对战，发现我们的蛇存活率不高，同时在竞争果子上也表现不佳。在分析对局后，我们重新设计了存活策略和得分策略，并编写了测试脚本，相比最初有了很大提升。
需求建模和算法设计
→ 📖 Q3.3(P) 请说明你们如何建模这一需求。
把其他蛇的蛇身去除最后一节加上蛇头可能的三个移动方向都视作障碍物处理，优先保证蛇不会相撞。如果发现无法移动，则不考虑对方蛇头的可能移动方向。最终目标是在满足以上约束条件下寻找最快吃到果子的一条路径，据此得到下一步移动方向。
→ 📖 Q3.4(P) 请说明针对该任务，你们采取了哪些策略来优化决策。具体而言，怎么避免死亡？怎么吃到更多果子？如何编程实现。
存活策略：
- 在决策时考虑两个因素：对方蛇的位置和自身到墙角的距离。
- 当蛇头到达墙角时，如果对方蛇在附近可能会无法找到存活路径死亡，在决策时需要避免过于靠近墙角
得分策略：
- 由于无法预测对方蛇的移动方向，使用贪心策略规划移动路线，并没有全局考虑吃到最多果子，每次只考虑吃到最近的果子
- 在实现上，在满足存活条件情况下，分别计算出场上吃到每个果子的最短路径，选择最短的一条作为下次移动方向
软件度量
→ 📖 Q3.5(P) 请说明你们如何量度所实现的程序模块的有效性，例如：“如何说明我们的程序模块对弈能力很强？”尝试提出一些可能的定量分析方式。
我们和其他六组交换了最后的pkg进行了对局。通过脚本进行大量对局，统计结果的获胜次数和胜率作为有效性的依据。
同时，由于我们的策略在最初存在蛇容易在墙角死亡的问题，因此我们专门准备了苹果生成在墙角的情况进行测试，以检测新的策略是否可以提高存活率。
总结
→ 📖 Q3.6(P) 请记录下目前的时间，并根据实际情况填写 附录A：基于 PSP 2.1 修改的 PSP 表格 的“实际耗时”栏目。
时间：4月3日11点
| Personal Software Process Stages | 个人软件开发流程 | 预估耗时（分钟） | 实际耗时（分钟） |
|---|---|---|---|
| PLANNING | 计划 | 10 | 10 |
| - Estimate | - 估计这个任务需要多少时间 | 10 | 10 |
| DEVELOPMENT | 开发 | 305 | 350 |
| - Analysis & Design Spec | - 需求分析 & 生成设计规格（确定要实现什么） | 10 | 15 |
| - Technical Background | - 了解技术背景（包括学习新技术） | 30 | 20 |
| - Coding Standard | - 代码规范 | 5 | 5 |
| - Design | - 具体设计（确定怎么实现） | 40 | 60 |
| - Coding | - 具体编码 | 120 | 140 |
| - Code Review | - 代码复审 | 20 | 30 |
| - Test Design | - 测试设计（确定怎么测，比如要测试哪些情景、设计哪些种类的测试用例） | 20 | 20 |
| - Test Implement | - 测试实现（设计/生成具体的测试用例、编码实现测试） | 60 | 60 |
| REPORTING | 报告 | 15 | 15 |
| - Quality Report | - 质量报告（评估设计、实现、测试的有效性） | 5 | 5 |
| - Size Measurement | - 计算工作量 | 5 | 5 |
| - Postmortem & Process Improvement Plan | - 事后总结和过程改进计划（总结过程中的问题和改进点） | 5 | 5 |
| TOTAL | 合计 | 330 | 375 |
→ 📖 Q3.7(I) 请写下本部分的心得体会。
结对项目总结
结对过程回顾和反思
→ 📖 Q4.1(P) 提供两人在讨论的结对图像资料。
→ 📖 Q4.2(P) 回顾结对的过程，反思有哪些可以提升和改进的地方。
-
在设计寻路算法时没必要担心超时，实际上不需要使用实现起来更复杂的A*算法，只需要用BFS
-
一开始就编写自动打包和测试的脚本，提高开发效率
-
在讨论时要多做记录，减少两人的沟通成本，特别是在第三题设计策略时，讨论了很多可行方案，但是没有记录下来，最后由一个人编码实现时并不顺畅
→ 📖 Q4.3(I) 锐评一下你的搭档！并请至少列出三个优点和一个缺点。
- 优点：
- 对题目理解透彻，抽象思维强
- 代码能力强，代码审核能够很快的发现问题
- 沟通能力强，超级好沟通
- 缺点：
- 似乎结对那一周在准备一些面试，时间比较少，但是都可以理解啦
对结对编程的理解
→ 📖 Q4.4(I) 说明结对编程的优缺点、你对结对编程的理解。
结对编程的模式就是驾驶员负责编写代码，领航员负责进行代码复审，这其实是代码复审的一种极限编程形式，即将代码复审发展到极致。我认为结对编程的优点是随时随地进行代码复审和沟通，在编码的早期就规避掉了一些简单的bug，有利于提升软件的正确性；缺点在于如果领航员和驾驶员之间配合不融洽可能会造成1+1<1的实际效果。
【推荐】国内首个AI IDE，深度理解中文开发场景，立即下载体验Trae
【推荐】凌霞软件回馈社区，携手博客园推出1Panel与Halo联合会员
【推荐】轻量又高性能的 SSH 工具 IShell：AI 加持，快人一步