[p] 结对项目：影蛇舞
| 项目 | 内容 |
|---|---|
| 这个作业属于哪个课程 | 2025年春季软件工程（罗杰、任健） |
| 这个作业的要求在哪里 | [P] 结对项目：影蛇舞 |
| 我在这个课程的目标是 | 深入学习软件工程，掌握其核心思想，增强自身团队合作能力，学会敏捷开发 |
| 这个作业在哪个具体方面帮助我实现目标 | 提高自己和队友的沟通能力和代码开发能力，在实践中提高软件开发能力，体会结对编程的魅力 |
Chapter.0 Belua multorum es capitums.（你是多首的怪物。）
引入
→ 📖 Q0.1(P) 请记录下目前的时间。
4月3日13：01
调查
→ 📖 Q0.2(I) 作为本项目的调查：请如实标注在开始项目之前对 Wasm 的熟悉程度分级，可以的话请细化具体的情况。
I. 没有听说过；
II. 仅限于听说过相关名词；
III. 听说过，且有一定了解；
IV. 听说过，且使用 Wasm 实际进行过开发（即便是玩具项目的开发）。
I. 没有听说过
总结
→ 📖 Q0.3(P) 请记录下目前的时间。
4月3日13：30
Chapter.1 不畏迷茫，只管前进。（迷子でもいい、前へ進め。）
结对过程
→ 📖 Q1.1(P) 请记录下目前的时间。
4月3日13：31
→ 📖 Q1.2(P) 请在完成任务的同时记录，并在完成任务后整理完善：
- 浏览任务要求，参照 附录A：基于 PSP 2.1 修改的 PSP 表格，估计任务预计耗时；
- 完成编程任务期间，依次做了什么（比如查阅了什么资料，随后如何进行了开发，遇到了什么问题，又通过什么方式解决）；
| Personal Software Process Stages | 个人软件开发流程 | 预估耗时（分钟） | 实际耗时（分钟） |
|---|---|---|---|
| PLANNING | 计划 | 3 | 2 |
| - Estimate | - 估计这个任务需要多少时间 | 3 | 2 |
| DEVELOPMENT | 开发 | 65 | 56 |
| - Analysis & Design Spec | - 需求分析 & 生成设计规格（确定要实现什么） | 10 | 8 |
| - Technical Background | - 了解技术背景（包括学习新技术） | 15 | 13 |
| - Coding Standard | - 代码规范 | 3 | 2 |
| - Design | - 具体设计（确定怎么实现） | 7 | 8 |
| - Coding | - 具体编码 | 10 | 9 |
| - Code Review | - 代码复审 | 5 | 3 |
| - Test Design | - 测试设计（确定怎么测，比如要测试哪些情景、设计哪些种类的测试用例） | 5 | 5 |
| - Test Implement | - 测试实现（设计/生成具体的测试用例、编码实现测试） | 10 | 8 |
| REPORTING | 报告 | 15 | 13 |
| - Quality Report | - 质量报告（评估设计、实现、测试的有效性） | 5 | 3 |
| - Size Measurement | - 计算工作量 | 5 | 3 |
| - Postmortem & Process Improvement Plan | - 事后总结和过程改进计划（总结过程中的问题和改进点） | 5 | 7 |
| TOTAL | 合计 | 83 | 71 |
在整个编程流程中，我们首先查阅了Rust官方手册，对Rust语法有了一定的了解，然后进行了开发。由于第一题任务较为简单，在整体设计方面我们并未遇到问题，最大的问题是初次接触Rust导致的对语法的不熟悉，这些问题都可以通过阅读官方手册解决。
测试
→ 📖 Q1.3(P) 请说明针对该任务，你们设计和实现测试的方法及过程，包括但不限于：出于对需求的哪些考虑设计了哪些测试用例、如何评估所设计测试的有效性 等等。
- 测试目标：确保所实现函数在不同棋盘状态下能正确返回 0、1、2、3 之一的合法方向，同时检验检验算法在极端情况下(如封闭空间、果子在角落等)的表现。
- 测试用例设计：
- 基本功能部分：涉及到大多数情况，包括果子在蛇的正前方，左前方，左后方等普通位置，可以用随机生成的策略来实现。
- 特殊测试点部分：考虑一些极端情况，例如到果子的最短路径被蛇的身体阻挡，果子在边界等情况。
- 测试评估标准：
- 所有测试结果中，蛇不会死亡，且能在200回合内吃到果子。
- 算法执行时间不超过500ms。
→ 📖 Q1.4(I) 请说明单元测试对软件开发的作用。
- 单元测试可以帮助开发者在编写代码的同时验证功能是否正确，从而及时发现和修复错误，减少 bug 的数量，提升整体质量。
- 编写单元测试要求代码具有良好的可测试性，从而推动开发者写出结构清晰、职责单一、耦合度低的模块化代码。
总结
→ 📖 Q1.5(P) 请记录下目前的时间，并根据实际情况填写 附录A：基于 PSP 2.1 修改的 PSP 表格 的“实际耗时”栏目。
4月3日14：42，实际耗时见Q1.2。
→ 📖 Q1.6(I) 请写下本部分的心得体会。
在本次任务中，我们初步了解了wasm工作过程，同时也进一步了解了rust，并且对单元测试有了深入的理解。
Chapter.2 即使迷茫，也要前行。（迷子でもいい、迷子でも進め。）
结对过程
→ 📖 Q2.1(P) 请记录下目前的时间。
4月3日14：50
→ 📖 Q2.2(P) 请在完成任务的同时记录，并在完成任务后整理完善：
- 浏览任务要求，参照 附录A：基于 PSP 2.1 修改的 PSP 表格，估计任务预计耗时；
- 完成编程任务期间，依次做了什么（比如查阅了什么资料，随后如何进行了开发，遇到了什么问题，又通过什么方式解决）；
| Personal Software Process Stages | 个人软件开发流程 | 预估耗时（分钟） | 实际耗时（分钟） |
|---|---|---|---|
| PLANNING | 计划 | 5 | 4 |
| - Estimate | - 估计这个任务需要多少时间 | 5 | 4 |
| DEVELOPMENT | 开发 | 105 | 117 |
| - Analysis & Design Spec | - 需求分析 & 生成设计规格（确定要实现什么） | 15 | 20 |
| - Technical Background | - 了解技术背景（包括学习新技术） | 10 | 12 |
| - Coding Standard | - 代码规范 | 5 | 4 |
| - Design | - 具体设计（确定怎么实现） | 15 | 12 |
| - Coding | - 具体编码 | 25 | 30 |
| - Code Review | - 代码复审 | 10 | 9 |
| - Test Design | - 测试设计（确定怎么测，比如要测试哪些情景、设计哪些种类的测试用例） | 10 | 10 |
| - Test Implement | - 测试实现（设计/生成具体的测试用例、编码实现测试） | 15 | 20 |
| REPORTING | 报告 | 20 | 18 |
| - Quality Report | - 质量报告（评估设计、实现、测试的有效性） | 8 | 7 |
| - Size Measurement | - 计算工作量 | 4 | 3 |
| - Postmortem & Process Improvement Plan | - 事后总结和过程改进计划（总结过程中的问题和改进点） | 8 | 8 |
| TOTAL | 合计 | 130 | 139 |
在完成编程任务时，我们先查阅了搜索最短路径的相关算法，考虑到场地特征，我们决定采用BFS策略。在实现时，难点在于如何将BFS转化为我们并不熟悉的rust代码，不过通过查阅官方手册，我们最终克服了这一难点。
代码可复用性与需求变更
→ 📖 Q2.3(P) 请说明针对该任务，你们对 🧑💻 T1 中已实现的代码进行了哪些复用和修改。
本次任务相较于上次任务做出了较大的修改，采用了完全不同的策略：
- 在T1中，由于不存在障碍物，蛇头一定可以到达果子，且最短路径长度可以直接计算出来。因此可以采用贪心策略，检查蛇头的四个相邻位置，如果到果子的最短路径长度最小且不与身体重合，则向这一方向移动。
- 在T2中，由于障碍物的存在，我们采用了BFS的思路，从蛇头位置开始BFS，直到搜索到一条到达果子的最短路径，或者发现果子不可达。
→ 📖 Q2.4(I) 请说明在编码实现时，可以采取哪些设计思想、考虑哪些设计冗余，来提高既存代码适应需求变更的能力。
设计思想：
面向接口编程，高内聚、低耦合，开闭原则（OCP）
设计冗余：
适度的参数化，预留接口和扩展点，使用中间层封装外部依赖，编写单元测试和接口测试
头脑风暴环节
**→ 📖 Q2.5(P) **只吃一个食物可满足不了贪吃蛇的欲望，请一起思考并简述以下场景中贪吃蛇的策略：
在 🧑💻 T2 的基础上，场地里不再是只有 1 个果子，而是总共有 n 个果子 (1 < n < 10 )，果子随机分布在场地中且不会刷新，保证不与障碍物重叠，保证每个果子均可达，且至少存在一条成功吃掉所有果子的路线，其余条件保持不变，请你找出一条吃完所有果子的行动路径。
考虑到果子数目小于10，因此可以分别判断果子之间的可达性，将其转换为无向图G。然后寻找蛇可以到达的果子，以这一点为起点搜索无向图G中的哈密顿路径，如果找到则说明找到了一条可以吃完所有果子的行动路径。
总结
→ 📖 Q2.6(P) 请记录下目前的时间，并根据实际情况填写 附录A：基于 PSP 2.1 修改的 PSP 表格 的“实际耗时”栏目。
3月29日17：09，实际耗时见Q2.2
→ 📖 Q2.7(I) 请写下本部分的心得体会。
在第二次任务中，我们运用BFS对路径进行相关的搜索。在这次任务中，认识到在开发过程中要适度保持代码的可扩展性。
Chapter.3 这就是我的前进、到我出场了！！！！！（It's MyGO!!!!!）
结对过程
→ 📖 Q3.1(P) 请记录下目前的时间。
4月5日13：43
→ 📖 Q3.2(P) 请在完成任务的同时记录，并在完成任务后整理完善：
- 浏览任务要求，参照 附录A：基于 PSP 2.1 修改的 PSP 表格，估计任务预计耗时；
- 完成编程任务期间，依次做了什么（比如查阅了什么资料，随后如何进行了开发，遇到了什么问题，又通过什么方式解决）；
任务耗时：
| Personal Software Process Stages | 个人软件开发流程 | 预估耗时（分钟） | 实际耗时（分钟） |
|---|---|---|---|
| PLANNING | 计划 | 15 | 10 |
| - Estimate | - 估计这个任务需要多少时间 | 15 | 10 |
| DEVELOPMENT | 开发 | 200 | 184 |
| - Analysis & Design Spec | - 需求分析 & 生成设计规格（确定要实现什么） | 25 | 15 |
| - Technical Background | - 了解技术背景（包括学习新技术） | 15 | 20 |
| - Coding Standard | - 代码规范 | 10 | 5 |
| - Design | - 具体设计（确定怎么实现） | 35 | 26 |
| - Coding | - 具体编码 | 60 | 54 |
| - Code Review | - 代码复审 | 15 | 12 |
| - Test Design | - 测试设计（确定怎么测，比如要测试哪些情景、设计哪些种类的测试用例） | 15 | 22 |
| - Test Implement | - 测试实现（设计/生成具体的测试用例、编码实现测试） | 25 | 30 |
| REPORTING | 报告 | 55 | 48 |
| - Quality Report | - 质量报告（评估设计、实现、测试的有效性） | 20 | 17 |
| - Size Measurement | - 计算工作量 | 10 | 12 |
| - Postmortem & Process Improvement Plan | - 事后总结和过程改进计划（总结过程中的问题和改进点） | 25 | 19 |
| TOTAL | 合计 | 270 | 242 |
在完成本次任务时，我们首先阅读了任务描述，明确了需求与关键点，然后我们搜索了其他更优秀的寻路算法与对抗策略，然后确定了蛇的两种前进策略并将其转化为代码，最后让不同策略进行对抗并优化得到最终结果
需求建模和算法设计
→ 📖 Q3.3(P) 请说明你们如何建模这一需求。
需求建模：给定场地，果子的位置，其他蛇的位置，需要保证自己的蛇能检索到最近可以到达的果子，并避免与其他蛇相撞。同时在不存在可到达果子时，需要控制蛇向安全位置移动。
→ 📖 Q3.4(P) 请说明针对该任务，你们采取了哪些策略来优化决策。具体而言，怎么避免死亡？怎么吃到更多果子？如何编程实现。
我们首先考虑了两种可行的策略并加以实现，然后筛选出更优秀的策略。
策略一：
- 利用A*算法搜索最近的可达果子，并向果子移动
- 如果不存在可达果子，则向一个安全位置移动
策略二： - 对四个方向进行评分，细则如下:
- 在不考虑其他蛇的情况下，越靠近最近的果子，评分越高，若吃到果子，获得极高的加分
- 移动之后，远离其他蛇加分，过于靠近其他蛇扣分。
- 为避免被包围，移动之后，下次移动可选方向越多，评分越高。
- 离边缘越远，分数越低。
- 对于与其他蛇抢果子的情况，我们先进行躲避，并将这一方向移入待考虑方向。
- 选择分数最高的方向移动，如果不存在，则从待考虑方向中选择分数最高的方向。
经过反复比较，我们发现策略二在大多数情况下有更优秀的表现
软件度量
→ 📖 Q3.5(P) 请说明你们如何量度所实现的程序模块的有效性，例如：“如何说明我们的程序模块对弈能力很强？”尝试提出一些可能的定量分析方式。
让不同策略互相对战，统计以下指标：
| 指标 | 定义 | 解释 |
|---|---|---|
| 存活回合数 | 蛇在游戏中的存活回合数 | 存活时间越长，说明策略越稳健 |
| 平均得分 | 每局游戏最终吃到的果子数 | 高得分表示能够有效获取果子 |
| 果子采集速率 | 得分 / 存活回合 |
代表每回合的得分效率 |
总结
→ 📖 Q3.6(P) 请记录下目前的时间，并根据实际情况填写 附录A：基于 PSP 2.1 修改的 PSP 表格 的“实际耗时”栏目。
4月5日17：45，实际时间见Q3.2
→ 📖 Q3.7(I) 请写下本部分的心得体会。
本次任务是最为复杂的任务，我们需要找出一个尽可能优的策略来保证在与其他蛇对抗的过程中迟到尽可能多的果子，我们讨论了很多策略，发现各种策略都存在优点和缺点，我们选择了一个尽可能优的策略来保证我们该部分代码的“性能”。
结对项目总结
结对过程回顾和反思
→ 📖 Q4.1(P) 提供两人在讨论的结对图像资料。
→ 📖 Q4.2(P) 回顾结对的过程，反思有哪些可以提升和改进的地方。
以下部分需要提升和改进：
- 协作能力不足：在任务初期未能进行充分讨论，对对方的意图不够了解，导致进度较慢。
- 最初代码结构比较混乱：代码耦合度较高，未进行模块化处理，导致迭代开发过程出现困难。
- 策略未得到充分优化：最后一次任务的执行策略较为简单，没有在决策中加入对其他蛇策略的思考。
→ 📖 Q4.3(I) 锐评一下你的搭档！并请至少列出三个优点和一个缺点。
优点
1、细心，考虑得很全面。
2、编程能力强。
3、幽默有趣，提供了很多情绪价值。
缺点：
节奏不同步，容易“精神内耗”
对结对编程的理解
→ 📖 Q4.4(I) 说明结对编程的优缺点、你对结对编程的理解。
优点：
1. 代码质量更高
- 实时审查机制，能及时发现并修正 bug。
- 编程风格更一致，设计更清晰。
2. 知识共享，促进成长
- 高效的“边做边学”，有经验的程序员可以带动新手。
- 增强对整个项目的理解，打破“知识孤岛”。
3. 思维互补，提升设计
- 两个人讨论问题时更容易跳出惯性思维，做出更合理的决策。
- 有助于权衡设计权衡点，而不是凭直觉编码。
缺点：
1.效率短期内可能下降
- 两个人做一个人的事，可能会觉得“人力浪费”。
- 特别在熟悉度低或性格差异大时，容易争论或卡顿。
2. 对沟通能力要求高
- 如果搭档之间不擅长倾听或表达，很容易合作失败。
- 性格内向或自尊心强的程序员可能不适应这种模式。
3. 容易造成疲劳
- 长时间高强度集中协作对心理、注意力是种消耗。
- 需要合理安排结对时间，穿插独立开发段落。
对结对编程的理解:
结对编程不是效率工具，而是质量工具。
它的价值不在于加快写代码的速度，而在于减少返工、提升质量、沉淀团队知识。
我认为结对编程最适合以下场景：新手学习、熟悉代码库，攻克复杂逻辑、架构设计，高风险模块开发，团队协作训练
浙公网安备 33010602011771号