[P] 结对项目：影蛇舞
结对项目：博客问题清单
请将本文件在代码仓库外复制一份，一边阅读和完成结对项目、一边填写入代码仓库外的版本，或采取简记、语音备忘等方式记载较复杂问题的要点之后再补充。请不要将本文档内的作答提交到代码仓库。
Chapter.0 Belua multorum es capitums.（你是多首的怪物。）
引入
→ 📖 Q0.1(P) 请记录下目前的时间。
2025.3.25 19：33
调查
→ 📖 Q0.2(I) 作为本项目的调查：请如实标注在开始项目之前对 Wasm 的熟悉程度分级，可以的话请细化具体的情况。
I. 没有听说过；
II. 仅限于听说过相关名词；
III. 听说过，且有一定了解；
IV. 听说过，且使用 Wasm 实际进行过开发（即便是玩具项目的开发）。
II. 仅限于听说过相关名词；
总结
→ 📖 Q0.3(P) 请记录下目前的时间。
2025.3.25 19：49
Chapter.1 不畏迷茫，只管前进。（迷子でもいい、前へ進め。）
结对过程
→ 📖 Q1.1(P) 请记录下目前的时间。
2025.3.25 20：03
→ 📖 Q1.2(P) 请在完成任务的同时记录，并在完成任务后整理完善：
- 浏览任务要求，参照 附录A：基于 PSP 2.1 修改的 PSP 表格，估计任务预计耗时；
- 完成编程任务期间，依次做了什么（比如查阅了什么资料，随后如何进行了开发，遇到了什么问题，又通过什么方式解决）；
2.查阅了关于AssemblyScript 和Rust 的资料，确定了使用AS进行开发；
根据题目所给信息编写了目标函数，并使用ai生成测试样例进行测试；
测试过程中遇到问题：函数缺少“不允许蛇头直接转向第一节身体方向”的限制，导致没有通过测试；
根据题目逻辑编写了关于蛇头方向限制的辅助函数，在主函数中调用辅助函数避免了上述问题。
此外，还遇到了没有可视化分析的问题，解决方法是，使用ai生成了一个简单html的贪吃蛇可视化界面，通过可视化界面，对蛇的运动进行可视化地调试。
测试
→ 📖 Q1.3(P) 请说明针对该任务，你们设计和实现测试的方法及过程，包括但不限于：出于对需求的哪些考虑设计了哪些测试用例、如何评估所设计测试的有效性 等等。
1.基础移动逻辑
- 需求：蛇应根据当前方向和食物位置选择合理移动方向（如向食物靠近）。
- 对应的测试用例：
- 案例1：蛇头朝右，食物在右侧 → 预期方向为“右”（直接向食物移动）。
- 案例2：蛇头朝右，食物在左侧 → 预期方向为“上”（需转向避开自身或障碍）。
- 复杂路径场景
- 需求：蛇在复杂路径（如回字形）中仍能规划合理路径。
- 对应的测试用例：
- 案例3：蛇头在左上角，食物在右下方 → 预期方向为“右”（需绕过蛇身）。
- 案例4：蛇在左下角回字形，食物在右上方 → 预期方向为“上”（需突破回字形路径）。
- 案例5：蛇在右上角回字形，食物在左下方 → 预期方向为“左”（需绕开自身）。
3.边界条件
- 需求：蛇在边界（如角落）或极端位置时仍能正确移动。
- 对应的测试用例：
- 案例3：蛇头在左上角（坐标4,2），需向右移动。
- 案例4：蛇在左下角回字形（坐标1,1），需向上移动。
- 案例5：蛇在右上角回字形（坐标8,7），需向左移动。
4.方向优先级
- 需求：蛇应优先选择向食物移动的方向，同时避免碰撞自身或墙壁。
- 对应的测试用例：
- 案例2：蛇头朝右，但食物在左侧 → 预期方向为“上”（可能因右侧无空间，需转向）。。
→ 📖 Q1.4(I) 请说明单元测试对软件开发的作用。
单元测试是软件开发中针对代码最小可执行单元（如函数、方法、类）的测试，旨在验证其功能和性能是否符合预期。在软件开发过程中，单元测试起到以下作用：
- 提高代码质量，确保代码的正确性和稳定性，减少bug的出现。
- 减少调试成本，通过自动化测试，快速定位问题，节省开发时间。
- 促进代码重构，提供了安全的回归测试，能够允许开发者在不破坏现有功能的情况下进行代码优化。
- 促进团队协作，提供清晰的接口和预期行为，帮助团队成员理解代码逻辑。
总结
→ 📖 Q1.5(P) 请记录下目前的时间，并根据实际情况填写 附录A：基于 PSP 2.1 修改的 PSP 表格 的“实际耗时”栏目。
2025.3.25 21：46
| Personal Software Process Stages | 个人软件开发流程 | 预估耗时（分钟） | 实际耗时（分钟） |
|---|---|---|---|
| PLANNING | 计划 | ||
| - Estimate | - 估计这个任务需要多少时间 | 2 | 2 |
| DEVELOPMENT | 开发 | ||
| - Analysis & Design Spec | - 需求分析 & 生成设计规格（确定要实现什么） | 5 | 5 |
| - Technical Background | - 了解技术背景（包括学习新技术） | 20 | 10 |
| - Coding Standard | - 代码规范 | 5 | 3 |
| - Design | - 具体设计（确定怎么实现） | 10 | 5 |
| - Coding | - 具体编码 | 10 | 55 |
| - Code Review | - 代码复审 | 10（并行） | 55(并行) |
| - Test Design | - 测试设计（确定怎么测，比如要测试哪些情景、设计哪些种类的测试用例） | 5 | 5 |
| - Test Implement | - 测试实现（设计/生成具体的测试用例、编码实现测试） | 5 | 5 |
| REPORTING | 报告 | ||
| - Quality Report | - 质量报告（评估设计、实现、测试的有效性） | 5 | 2 |
| - Size Measurement | - 计算工作量 | 1 | 1 |
| - Postmortem & Process Improvement Plan | - 事后总结和过程改进计划（总结过程中的问题和改进点） | 10 | 10 |
| TOTAL | 合计 | 76 | 103 |
→ 📖 Q1.6(I) 请写下本部分的心得体会。
在本次结对编程中，初次参与结对编程和AssemblyScript的开发。虽然作为观察者的身份，但也参与了一下assemblyScript的学习和调试，发现几乎无缝兼容typescript的语法，上手比想象地简单很多。
同时观察队友编码，在调试过程中检查代码逻辑，是一个很好的学习机会。
Chapter.2 即使迷茫，也要前行。（迷子でもいい、迷子でも進め。）
结对过程
→ 📖 Q2.1(P) 请记录下目前的时间。
2025.3.26 9:26
→ 📖 Q2.2(P) 请在完成任务的同时记录，并在完成任务后整理完善：
- 浏览任务要求，参照 附录A：基于 PSP 2.1 修改的 PSP 表格，估计任务预计耗时；
- 完成编程任务期间，依次做了什么（比如查阅了什么资料，随后如何进行了开发，遇到了什么问题，又通过什么方式解决）；
首先，阅读了题目要求，了解了贪吃蛇的基本规则和目标函数的要求。
根据题目要求，讨论、编写了bfs移动的基本逻辑。在过程中，查找了有关map和set的相关资料。
遇到了问题：在使用map和set时，使用自定义的类型，会出现重复添加的问题。
在ai的指导下，将自定义类型编码为字符串，解决了上述问题。
此外，针对AssemblyScript难以调试的问题，改写了之前T1中的可视化界面，以支持TypeScript，使用编译前的ts代码进行可视化调试。
另外，设计了一点测试用例，测试了蛇头运动的正确性。
代码可复用性与需求变更
→ 📖 Q2.3(P) 请说明针对该任务，你们对 🧑💻 T2 中已实现的代码进行了哪些复用和修改。
复用了一些辅助函数，如getCurrentDirection获取当前蛇头方向。
放弃了之前使用的贪心策略，改为利用BFS搜索并记录路径，直接令贪吃蛇沿着该路径移动。
→ 📖 Q2.4(I) 请说明在编码实现时，可以采取哪些设计思想、考虑哪些设计冗余，来提高既存代码适应需求变更的能力。
可以使用模块化的思想，将代码分为不同的模块，每个模块负责特定的功能，减少模块之间的耦合度。来提高代码的可复用性和可维护性。
同时减少使用全局变量和硬编码的数值，使用参数传递和配置文件来提高代码的灵活性，也方便测试用例的编写。
头脑风暴环节
**→ 📖 Q2.5(P) **只吃一个食物可满足不了贪吃蛇的欲望，请一起思考并简述以下场景中贪吃蛇的策略：
在 🧑💻 T2 的基础上，场地里不再是只有 1 个果子，而是总共有 n 个果子 (1 < n < 10 )，果子随机分布在场地中且不会刷新，保证不与障碍物重叠，保证每个果子均可达，且至少存在一条成功吃掉所有果子的路线，其余条件保持不变，请你找出一条吃完所有果子的行动路径。
由于蛇不会撞自己，因此，蛇的状态可以使用蛇头位置和朝向表示。通过对（每个果子*4个方向 + 初始位置）分别进行bfs搜索，判断每个果子之间的可达性。对于可以到达的果子之间，连一条有向边。
之后，在这张图上做dfs搜索，求得经过所有果子的一条吃果子顺序。
再根据这个顺序，求得一条所求的路径。
总结
→ 📖 Q2.6(P) 请记录下目前的时间，并根据实际情况填写 附录A：基于 PSP 2.1 修改的 PSP 表格 的“实际耗时”栏目。
2025.3.26 12:02
| Personal Software Process Stages | 个人软件开发流程 | 预估耗时（分钟） | 实际耗时（分钟） |
|---|---|---|---|
| PLANNING | 计划 | ||
| - Estimate | - 估计这个任务需要多少时间 | 3 | 3 |
| DEVELOPMENT | 开发 | ||
| - Analysis & Design Spec | - 需求分析 & 生成设计规格（确定要实现什么） | 5 | 5 |
| - Technical Background | - 了解技术背景（包括学习新技术） | 0 | 0 |
| - Coding Standard | - 代码规范 | 0 | 0 |
| - Design | - 具体设计（确定怎么实现） | 20 | 10 |
| - Coding | - 具体编码 | 60 | 90 |
| - Code Review | - 代码复审 | ||
| - Test Design | - 测试设计（确定怎么测，比如要测试哪些情景、设计哪些种类的测试用例） | 5 | 10 |
| - Test Implement | - 测试实现（设计/生成具体的测试用例、编码实现测试） | 10 | 20 |
| REPORTING | 报告 | ||
| - Quality Report | - 质量报告（评估设计、实现、测试的有效性） | 5 | 5 |
| - Size Measurement | - 计算工作量 | 2 | 2 |
| - Postmortem & Process Improvement Plan | - 事后总结和过程改进计划（总结过程中的问题和改进点） | 10 | 10 |
| TOTAL | 合计 | 120 | 155 |
→ 📖 Q2.7(I) 请写下本部分的心得体会。
在本次结对编程中，使用bfs搜索，虽然代码本身并不复杂，但是部分逻辑，尤其是坐标系的上下左右的问题，导致debug的时间比较长。而且如map和set的使用问题，只能说js的经验还是太少了，但是搜索引擎上也难找到更详细的解释，幸亏有ai的帮助。
此外，感觉自己在结对编程中不够主动，虽然有提出问题，但是没有主动去检查代码逻辑，在感觉能行和简单的测试通过后就没管，尤其导致后面T3回过头来改T2的逻辑时，发现了很多问题。
Chapter.3 这就是我的前进、到我出场了！！！！！（It's MyGO!!!!!）
结对过程
→ 📖 Q3.1(P) 请记录下目前的时间。
2025.4.2 19:00
→ 📖 Q3.2(P) 请在完成任务的同时记录，并在完成任务后整理完善：
- 浏览任务要求，参照 附录A：基于 PSP 2.1 修改的 PSP 表格，估计任务预计耗时；
- 完成编程任务期间，依次做了什么（比如查阅了什么资料，随后如何进行了开发，遇到了什么问题，又通过什么方式解决）；
首先，根据题目需求，大体上设计了贪吃蛇的基本逻辑。即根据果子，其他蛇的位置信息，为某个运动方向打分，选择分数最高的方向。
然后，根据需求分析，大致实现了贪吃蛇运动的基本逻辑。
在编码过程中我们通过反复交流，讨论关于打分的细节问题。
主要遇到的问题是，调试过程中，反复出现数组越界的问题，在仔细检查代码后，将各种硬编码的数值改为变量，解决了上述问题。
同时，发现之前的T2中的逻辑有些问题，花了一些时间，修改T2中bfs的逻辑，添加了更多测试。
需求建模和算法设计
→ 📖 Q3.3(P) 请说明你们如何建模这一需求。
首先，我们仔细阅读了题目需求，了解了贪吃蛇的基本规则和目标函数的要求。将输入的蛇头位置、食物位置、障碍物位置等信息进行建模。
然后，我们了解到一些游戏ai, 仿生编程中，会使用打分的方式，代替实际的寻路搜索。基于这一思想，我们也设计了类似的打分逻辑，通过食物->奖励，障碍物（即其他蛇）-> 惩罚的方式，来设计蛇的运动方向。
→ 📖 Q3.4(P) 请说明针对该任务，你们采取了哪些策略来优化决策。具体而言，怎么避免死亡？怎么吃到更多果子？如何编程实现。
- 存活策略
- 确保选择不会立即死亡，根据不能反向，不能直接撞墙/其他蛇的规则，利用T1中的实现，先筛选出合法方向。
- 对于其他蛇，使用bfs计算他们接下来若干步的可能位置，为可能到的方向打分（称为危险分数），避免选择可能被其他蛇撞到的方向。
- 针对可能会被挤到角落的情况，利用dfs计算走之后的自由度（可能剩余的空间），为该方向打分（称为自由度分数），避免被挤到角落。
- 得分策略
- 对于食物，根据距离，为每个方向打分，越近的方向分数越高，以引导蛇朝食物方向移动。
根据以上策略，合理选择参数，从而实现合理的运动方向。
软件度量
→ 📖 Q3.5(P) 请说明你们如何量度所实现的程序模块的有效性，例如：“如何说明我们的程序模块对弈能力很强？”尝试提出一些可能的定量分析方式。
通过在迭代过程中，与不同参数，不同版本的蛇进行对战，并将T2中的蛇简单改写到T3中，参与对战。
对课程组提供的运行程序进行简单改造，反复多次执行，在200次对战中，统计平均得分。根据平均得分的高低，来评估蛇的对战能力。
总结
→ 📖 Q3.6(P) 请记录下目前的时间，并根据实际情况填写 附录A：基于 PSP 2.1 修改的 PSP 表格 的“实际耗时”栏目。
2025.4.2 23:15
此外，在2025.4.5 14:50 - 15:15 期间对蛇的对战能力进行了测试。
| Personal Software Process Stages | 个人软件开发流程 | 预估耗时（分钟） | 实际耗时（分钟） |
|---|---|---|---|
| PLANNING | 计划 | ||
| - Estimate | - 估计这个任务需要多少时间 | 3 | 3 |
| DEVELOPMENT | 开发 | ||
| - Analysis & Design Spec | - 需求分析 & 生成设计规格（确定要实现什么） | 10 | 10 |
| - Technical Background | - 了解技术背景（包括学习新技术） | 10 | 10 |
| - Coding Standard | - 代码规范 | 0 | 0 |
| - Design | - 具体设计（确定怎么实现） | 20 | 20 |
| - Coding | - 具体编码 | 100 | 195 |
| - Code Review | - 代码复审 | ||
| - Test Design | - 测试设计（确定怎么测，比如要测试哪些情景、设计哪些种类的测试用例） | 10 | 5 |
| - Test Implement | - 测试实现（设计/生成具体的测试用例、编码实现测试） | 20 | 10 |
| REPORTING | 报告 | ||
| - Quality Report | - 质量报告（评估设计、实现、测试的有效性） | 5 | 5 |
| - Size Measurement | - 计算工作量 | 2 | 2 |
| - Postmortem & Process Improvement Plan | - 事后总结和过程改进计划（总结过程中的问题和改进点） | 10 | 10 |
| TOTAL | 合计 | 190 | 270 |
→ 📖 Q3.7(I) 请写下本部分的心得体会。
在本阶段中，作为驾驶员的身份完成了任务。在编码过程中，其实最大的难点还是在于如何设计合理的逻辑，在交流过程中，获得了很多启发。但是感觉策略还是不够完善，也没能和其他队伍的蛇进行对战，感觉对战能力还是不够强。
结对项目总结
结对过程回顾和反思
→ 📖 Q4.1(P) 提供两人在讨论的结对图像资料。
→ 📖 Q4.2(P) 回顾结对的过程，反思有哪些可以提升和改进的地方。
- 沟通与同步不足
- 问题：双方对需求或代码逻辑的理解存在偏差，导致设计与实际编写代码的不一致。
- 改进：两人合理地参与交流，确保信息共享的一致性。同时需要更加主动地复审与指出问题。
- 测试用例覆盖不全面
- 问题：测试用例集中在简单场景，可能存在未覆盖的极端情况。
- 改进：一人负责设计用例，另一人通过ai等工具补充遗漏场景。
- 代码审查流于形式
- 问题：急于推进代码实现，未仔细检查彼此的代码。导致花费大量时间返工修bug。
- 改进：交替担任“编码者”和“审查者”；使用ai工具辅助检查。
- 时间管理不灵活
- 问题：固守预设时间分配，导致某些复杂问题的处理较为粗糙。
- 改进：遇到难点时先暂停，集中力量优先解决核心矛盾；优化分工，提升工作效率。
→ 📖 Q4.3(I) 锐评一下你的搭档！并请至少列出三个优点和一个缺点。
优点：
- 有着不错的编码规范，代码可读性好。
- 为人友善，可以积极沟通。
- 认真负责
缺点：
- debug能力不足，容易忽略一些细节问题。
对结对编程的理解
→ 📖 Q4.4(I) 说明结对编程的优缺点、你对结对编程的理解。
结对编程，通过两个人共同协作，不断交流与复审代码，能够有效提高代码质量和开发效率。在结对编程中，双方可以互相学习、互相帮助，能够更快地发现问题和解决问题。也能促进团队成员之间的沟通与协作，增强团队凝聚力。
但是需要两个人高度配合并专注与任务，会降低完成任务的效率。同时，结对编程需要双方都具备一定的技术水平和沟通能力，否则可能会导致效率低下或沟通不畅。
我认为结对编程是一种有效的开发方式，在写代码的过程中，有实时的反馈，能够提高代码质量。但需要合理安排时间和保证交流的有效性，才能发挥出结对编程的优势。
浙公网安备 33010602011771号