结对项目：影蛇舞

结对项目：影蛇舞

Chapter.0 Belua multorum es capitums.（你是多首的怪物。）

引入

→ 📖 Q0.1(P) 请记录下目前的时间。

2025/3/29 15:20

调查

→ 📖 Q0.2(I) 作为本项目的调查：请如实标注在开始项目之前对 Wasm 的熟悉程度分级，可以的话请细化具体的情况。

I. 没有听说过；

II. 仅限于听说过相关名词；

III. 听说过，且有一定了解；

IV. 听说过，且使用 Wasm 实际进行过开发（即便是玩具项目的开发）。

I. 没有听说过；

总结

→ 📖 Q0.3(P) 请记录下目前的时间。

2025/3/29 16:14

Chapter.1 不畏迷茫，只管前进。（迷子でもいい、前へ進め。）

结对过程

→ 📖 Q1.1(P) 请记录下目前的时间。

2025/3/30 15:54

→ 📖 Q1.2(P) 请在完成任务的同时记录，并在完成任务后整理完善：

1. 浏览任务要求，参照 附录A：基于 PSP 2.1 修改的 PSP 表格，估计任务预计耗时；
2. 完成编程任务期间，依次做了什么（比如查阅了什么资料，随后如何进行了开发，遇到了什么问题，又通过什么方式解决）；

Personal Software Process Stages	个人软件开发流程	预估耗时（分钟）	实际耗时（分钟）
PLANNING	计划
- Estimate	- 估计这个任务需要多少时间	120	119
DEVELOPMENT	开发
- Analysis & Design Spec	- 需求分析 & 生成设计规格（确定要实现什么）	10	6
- Technical Background	- 了解技术背景（包括学习新技术）	10	15
- Coding Standard	- 代码规范	5	4
- Design	- 具体设计（确定怎么实现）	10	9
- Coding	- 具体编码	20	22
- Code Review	- 代码复审	10	8
- Test Design	- 测试设计（确定怎么测，比如要测试哪些情景、设计哪些种类的测试用例）	10	15
- Test Implement	- 测试实现（设计/生成具体的测试用例、编码实现测试）	20	15
REPORTING	报告
- Quality Report	- 质量报告（评估设计、实现、测试的有效性）	10	8
- Size Measurement	- 计算工作量	5	6
- Postmortem & Process Improvement Plan	- 事后总结和过程改进计划（总结过程中的问题和改进点）	10	10
TOTAL	合计	120	119

首先我们查阅了一些AssemblyScript的语法和测试方法，简单了解之后就开始着手设计代码。在我们都提出了自己的想法之后，确定大致思路。写代码的过程中发现忘记考虑蛇的第二节身子的方向不能走的问题，通过冲突调头的方法解决。再之后就开始写测试，我们两人都提出了一些情况，综合情况后写了一些数据来测试。

测试

→ 📖 Q1.3(P) 请说明针对该任务，你们设计和实现测试的方法及过程，包括但不限于：出于对需求的哪些考虑设计了哪些测试用例、如何评估所设计测试的有效性 等等。

测试需要考虑的需求有蛇头与果子的相对位置，蛇头与身体的冲突以及边界情况。所以我们设计了包括蛇头与果子没有阻碍的简单情况、蛇头与身体发生冲突的情况、边界情况和多个方向的选择等情况的设计用例。测试的有效性通过覆盖需求、覆盖边界情况、异常处理、返回结果验证等等来验证和评估。

→ 📖 Q1.4(I) 请说明单元测试对软件开发的作用。

单元测试是软件开发中用于验证代码中最小可测试单元（如函数或方法）正确性的重要手段。它通过及时发现和修复缺陷，提高代码质量，降低后期修复成本。单元测试还能为代码重构提供保障，确保修改不破坏现有功能，并使代码更易于维护和扩展。此外，单元测试代码本身也可以作为功能的文档，有助于开发人员理解和维护代码。尽管编写单元测试会增加初期开发时间，但它能提高开发效率，减少后期调试和修复的工作量。

总结

→ 📖 Q1.5(P) 请记录下目前的时间，并根据实际情况填写 附录A：基于 PSP 2.1 修改的 PSP 表格 的“实际耗时”栏目。

2025/3/30 17:53

→ 📖 Q1.6(I) 请写下本部分的心得体会。

这一部分还是比较简单的，我的体会主要是在关于与同伴一起编程的时候该如何去交流，来提高工作的效率。不能否认的是，在两人一开始配合的时候还是比较生疏的。但是在一些比较困难的选择的讨论时，还是相对于一个人有着更好的效果。

Chapter.2 即使迷茫，也要前行。（迷子でもいい、迷子でも進め。）

结对过程

→ 📖 Q2.1(P) 请记录下目前的时间。

2025/3/31 21:06

→ 📖 Q2.2(P) 请在完成任务的同时记录，并在完成任务后整理完善：

1. 浏览任务要求，参照 附录A：基于 PSP 2.1 修改的 PSP 表格，估计任务预计耗时；
2. 完成编程任务期间，依次做了什么（比如查阅了什么资料，随后如何进行了开发，遇到了什么问题，又通过什么方式解决）；

Personal Software Process Stages	个人软件开发流程	预估耗时（分钟）	实际耗时（分钟）
PLANNING	计划
- Estimate	- 估计这个任务需要多少时间	15	16
DEVELOPMENT	开发
- Analysis & Design Spec	- 需求分析 & 生成设计规格（确定要实现什么）	25	27
- Technical Background	- 了解技术背景（包括学习新技术）	20	18
- Coding Standard	- 代码规范	10	12
- Design	- 具体设计（确定怎么实现）	25	24
- Coding	- 具体编码	30	32
- Code Review	- 代码复审	15	16
- Test Design	- 测试设计（确定怎么测，比如要测试哪些情景、设计哪些种类的测试用例）	15	14
- Test Implement	- 测试实现（设计/生成具体的测试用例、编码实现测试）	15	15
REPORTING	报告
- Quality Report	- 质量报告（评估设计、实现、测试的有效性）	10	9
- Size Measurement	- 计算工作量	5	6
- Postmortem & Process Improvement Plan	- 事后总结和过程改进计划（总结过程中的问题和改进点）	5	4
TOTAL	合计	180	178

我们首先想了BFS来选择路径，但是在写代码的过程中我们想到了一些特殊情况，比如BFS过程中visited的处理问题和路径保存问题。最后我们将头和脖子两个坐标作为状态存到visited数组里，作为已经遍历过的格子的保存。路径保存问题，我们通过建立节点形成类似树的结构来保存状态。

代码可复用性与需求变更

→ 📖 Q2.3(P) 请说明针对该任务，你们对 🧑‍💻 T2 中已实现的代码进行了哪些复用和修改。

实际上并没有啥复用，因为上一个问题的逻辑比较简单，同时我们写的不是特别好，有点冗余，所以我们重新写了比较简单的代码，逻辑与上一题是一样的。

→ 📖 Q2.4(I) 请说明在编码实现时，可以采取哪些设计思想、考虑哪些设计冗余，来提高既存代码适应需求变更的能力。

在编码实现时，为了提高代码适应需求变更的能力，可以采取模块化设计、低耦合高内聚、开闭原则、单一职责原则等设计思想，确保系统易于扩展且维护简单。同时，通过使用设计模式、接口冗余、数据冗余和容错冗余等措施，为系统提供灵活性和稳定性。此外，持续集成和自动化测试有助于确保需求变更后代码的正确性，减少修改带来的风险和复杂性。

头脑风暴环节

**→ 📖 Q2.5(P) **只吃一个食物可满足不了贪吃蛇的欲望，请一起思考并简述以下场景中贪吃蛇的策略：

在 🧑‍💻 T2 的基础上，场地里不再是只有 1 个果子，而是总共有 n 个果子 (1 < n < 10 )，果子随机分布在场地中且不会刷新，保证不与障碍物重叠，保证每个果子均可达，且至少存在一条成功吃掉所有果子的路线，其余条件保持不变，请你找出一条吃完所有果子的行动路径。

先采取贪心策略，选择哈夫曼距离最近的果子作为目标，然后再通过BFS来找到最短路径，重复这个操作直到吃完果子。

总结

→ 📖 Q2.6(P) 请记录下目前的时间，并根据实际情况填写 附录A：基于 PSP 2.1 修改的 PSP 表格 的“实际耗时”栏目。

2025/4/1 00:04

→ 📖 Q2.7(I) 请写下本部分的心得体会。

在这个部分中，我和同伴的默契增长了许多，在编程的效率方面有了比较大的提高。

Chapter.3 这就是我的前进、到我出场了！！！！！（It's MyGO!!!!!）

结对过程

→ 📖 Q3.1(P) 请记录下目前的时间。

2025/4/4 14:30 2025/4/6 18:00

→ 📖 Q3.2(P) 请在完成任务的同时记录，并在完成任务后整理完善：

1. 浏览任务要求，参照 附录A：基于 PSP 2.1 修改的 PSP 表格，估计任务预计耗时；
2. 完成编程任务期间，依次做了什么（比如查阅了什么资料，随后如何进行了开发，遇到了什么问题，又通过什么方式解决）；

Personal Software Process Stages	个人软件开发流程	预估耗时（分钟）	实际耗时（分钟）
PLANNING	计划
- Estimate	- 估计这个任务需要多少时间	30	31
DEVELOPMENT	开发
- Analysis & Design Spec	- 需求分析 & 生成设计规格（确定要实现什么）	40	42
- Technical Background	- 了解技术背景（包括学习新技术）	35	33
- Coding Standard	- 代码规范	15	16
- Design	- 具体设计（确定怎么实现）	40	39
- Coding	- 具体编码	45	47
- Code Review	- 代码复审	25	26
- Test Design	- 测试设计（确定怎么测，比如要测试哪些情景、设计哪些种类的测试用例）	25	24
- Test Implement	- 测试实现（设计/生成具体的测试用例、编码实现测试）	30	30
REPORTING	报告
- Quality Report	- 质量报告（评估设计、实现、测试的有效性）	20	21
- Size Measurement	- 计算工作量	10	12
- Postmortem & Process Improvement Plan	- 事后总结和过程改进计划（总结过程中的问题和改进点）	10	11
TOTAL	合计	360	361

我们在这一部分想了很久，最后筛选了一些策略在下一部分中给出。

需求建模和算法设计

→ 📖 Q3.3(P) 请说明你们如何建模这一需求。

需求就是在时间内吃到比对方多的果子，所以有两种选择，第一是让自己吃的更快一些，第二是让对面吃的更慢一些。而影响决策的分别是自己与五个果子之间的距离，对方与五个果子之间的距离，以及自己与对方之间的距离。

→ 📖 Q3.4(P) 请说明针对该任务，你们采取了哪些策略来优化决策。具体而言，怎么避免死亡？怎么吃到更多果子？如何编程实现。

我们大致的策略为优先判断对方是不是贪心策略，如果是则采用针对贪心的策略，因为我们认为大多数人采用的都是贪心策略。如果不是，则采用我们自己的策略尽快吃果子。具体来说，我们将对面蛇的身体和头可能移动的方向作为障碍来避障。至于如何吃到更多果子，我们的策略是先评估果子是不是可以和别人竞争的，即是不是比别人离果子更近。如果是，那么选最近的作为目标。否则，可以选择那些别人眼中的第二选择。

软件度量

→ 📖 Q3.5(P) 请说明你们如何量度所实现的程序模块的有效性，例如：“如何说明我们的程序模块对弈能力很强？”尝试提出一些可能的定量分析方式。

我们邀请了两组其他小组来对战，通过结果来看看是不是对弈能力强。同时也可以自己和自己对弈来看看是不是比较强。

总结

→ 📖 Q3.6(P) 请记录下目前的时间，并根据实际情况填写 附录A：基于 PSP 2.1 修改的 PSP 表格 的“实际耗时”栏目。

2025/4/4 17:03 2025/4/6 21:28

→ 📖 Q3.7(I) 请写下本部分的心得体会。

在这最后一部分，由于这一部分对于思考的占比比较大，所以结对编程的优点更加明显。两个人经过讨论得出的结果却是比一个人更加全面和详细。同时，我们也调整了合作的方式，进一步提高了我们的效率。

结对项目总结

结对过程回顾和反思

→ 📖 Q4.1(P) 提供两人在讨论的结对图像资料。

→ 📖 Q4.2(P) 回顾结对的过程，反思有哪些可以提升和改进的地方。

首先是我们的分工应该明确一些。虽然结对编程是两个人在一起，但是我觉得有些简单的任务可以两个人分工一起做，或者在不在一起的线下时候做。而在某些关键问题上，一起讨论得出结果确实比一个人的思路好很多。另外，我们在讨论的时候也可以自己先罗列出要点，这样可以提高讨论的效率。

→ 📖 Q4.3(I) 锐评一下你的搭档！并请至少列出三个优点和一个缺点。

优点：强哥很有耐心，稳健，而且比较细心。

缺点（也不算啥缺点）：逆天作息。

对结对编程的理解

→ 📖 Q4.4(I) 说明结对编程的优缺点、你对结对编程的理解。

优点：在解决关键问题上，尤其是需要思考的问题，一起讨论得出结果确实比一个人的思路好很多。而且两个人可以取长补短。

缺点：如果两个人没有默契或者任务过于简单时，可能会影响效率。

代码实现提交

→ 📖 Q4.5(P) 请提供你们完成代码实现的代码仓库链接。

代码仓库

附录

附录A：基于 PSP 2.1 修改的 PSP 表格

Personal Software Process Stages	个人软件开发流程	预估耗时（分钟）	实际耗时（分钟）
PLANNING	计划
- Estimate	- 估计这个任务需要多少时间
DEVELOPMENT	开发
- Analysis & Design Spec	- 需求分析 & 生成设计规格（确定要实现什么）
- Technical Background	- 了解技术背景（包括学习新技术）
- Coding Standard	- 代码规范
- Design	- 具体设计（确定怎么实现）
- Coding	- 具体编码
- Code Review	- 代码复审
- Test Design	- 测试设计（确定怎么测，比如要测试哪些情景、设计哪些种类的测试用例）
- Test Implement	- 测试实现（设计/生成具体的测试用例、编码实现测试）
REPORTING	报告
- Quality Report	- 质量报告（评估设计、实现、测试的有效性）
- Size Measurement	- 计算工作量
- Postmortem & Process Improvement Plan	- 事后总结和过程改进计划（总结过程中的问题和改进点）
TOTAL	合计