[P] 结对项目：影蛇舞

结对项目：影蛇舞

项目	内容
这个作业属于哪个课程	2025年春季软件工程（罗杰、任健）
这个作业的要求在哪里	[P] 结对项目：影蛇舞
我在这个课程的目标是	掌握软件工程的核心技能，完善个人技术栈，提升开发效率与项目质量。
这个作业在哪个具体方面帮助我实现目标	通过结对编程，提高合作与表达能力，在协作开发中不断学习和提升自我

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

引入

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

2025/3/29 15:20

调查

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

I. 没有听说过；

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

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

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

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

总结

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

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

测试

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

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

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

1. 提高代码质量
   单元测试可以帮助开发者及早发现和修复代码中的错误。每次开发新的功能或修复一个bug时，编写单元测试可以确保这些修改不会引入新的问题，提升代码的稳定性。

2. 便于重构
   在进行代码重构时，单元测试可以作为一个“安全网”，确保重构后的代码仍然能够保持预期的功能和行为。这使得开发者可以在不担心引入错误的情况下优化代码结构。

3. 增强代码可维护性
   通过单元测试，可以明确地知道代码模块的预期行为。每当开发者需要修改代码时，单元测试可以验证修改是否破坏了现有功能，进而提高代码的可维护性和长期的稳定性。

4. 支持敏捷开发
   在敏捷开发中，频繁的迭代和小步快跑是常态。单元测试通过自动化的方式帮助开发人员在每次迭代后都能确认系统的功能是否正确，支持团队快速响应需求变化和确保持续交付

总结

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

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

代码可复用性与需求变更

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

我们对T1的复用较少，基本只延续了T1的基本思路，并没有较多地使用T1的代码，因为上一个问题的逻辑比较简单，所以我们的T1代码并不精细，也没有考虑之后的T2，且我们认为T2比T1复杂很多，如果过于追求复用反而不会取得很好的效果，所以我们基本没有使用T1的代码。

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

1. 模块化设计
   ：将系统分解成多个功能相对独立的模块，每个模块负责单一的功能（单一职责原则）。模块之间通过接口进行通信，减少模块之间的耦合。

2. 高内聚低耦合
   尽量使得系统中的模块高度内聚、功能单一，并减少模块之间的依赖（低耦合）。内聚的模块负责特定的功能，而模块间的交互通过明确的接口进行。

3. 避免过度设计
   只设计当前需求所需要的功能，避免过度设计和提前做不必要的假设。避免添加未来可能不需要的复杂功能。

头脑风暴环节

**→ 📖 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) 请说明你们如何量度所实现的程序模块的有效性，例如：“如何说明我们的程序模块对弈能力很强？”尝试提出一些可能的定量分析方式。

我们设置了四组敌人，分别是我们的复制体和另外三组同学，并与这四组敌人进行了1v1。
我们与每组敌人都进行了至少100次的1v1对战，并统计了胜率，分别为53%，57%，45%，71%。
由此，我们认为我们的策略实现效果尚可。

总结

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

2025/4/4 17:03

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

在这一部分的开发过程中，我深刻感受到结对编程的优势。由于这部分工作对思考的要求较高，两个人一起讨论和推敲，能够产生更加全面和深入的思路。与单独工作相比，结对编程让我能够从同伴的角度获得不同的见解和建议，这对问题的解决起到了非常积极的作用。此外，我们在过程中也不断优化了合作方式，更加默契的配合让我们的工作效率得到了显著提升。

结对项目总结

结对过程回顾和反思

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

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

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

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

优点：我的搭档思维灵活，工作高效，友好，易于沟通。

缺点：写的代码里有个难找的小bug。

对结对编程的理解

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

本次结对编程我基本作为“驾驶员”去完成任务，我认为结对编程既有优点，又会带来新的挑战。

优劣	维度	具体
优点	即时反馈，减少错误	作为驾驶员，我可以获得来自导航员的实时反馈。这种反馈帮助我快速发现并修正代码中的错误，避免了很多潜在的问题。相比于单独编码，我可以在错误发生的第一时间就得到纠正，减少了后期调试的时间和成本
优点	提高代码质量	由于我和导航员是实时合作的，导航员能帮助我从更广阔的角度审视我的代码，提醒我一些潜在的设计问题或改进点。我们讨论并达成共识后，我可以更加高效地进行编写，从而确保代码质量更高
优点	提高工作效率	当我们逐步适应彼此的工作方式后，效率会大大提升，我只需专注于代码实现，避免了很多不必要的分心
缺点	沟通成本较高	作为驾驶员，我需要不断地与导航员沟通和协调，这对于一些简单任务来说可能显得有些多余。尤其是在两个人的工作节奏不一致时，频繁的讨论反而可能导致工作进展缓慢
缺点	需要时间磨合	并非一开始就能达到高度的默契。在刚开始的时候，我和导航员需要一定的时间来磨合。期间，我们可能会因沟通不畅或彼此的工作节奏不一致而影响效率。

代码实现提交

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

github仓库链接

附录

附录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	合计