[P] 结对项目：影蛇舞
[P] 结对项目：影蛇舞
| 项目 | 内容 |
|---|---|
| 这个作业属于哪个课程 | 2025年春季软件工程（罗杰、任健） |
| 这个作业的要求在哪里 | [P] 结对项目：影蛇舞 |
| 我在这个课程的目标是 | 实践结对编程，体会结对编程的优劣势，锻炼与人合作的技巧 |
| 这个作业在哪个具体方面帮助我实现目标 | 锻炼和队友合作进行编程任务的技巧 |
Chapter.0 Belua multorum es capitums.（你是多首的怪物。）
引入
→ 📖 Q0.1(P) 请记录下目前的时间。
3月23日，14:03。
调查
→ 📖 Q0.2(I) 作为本项目的调查：请如实标注在开始项目之前对 Wasm 的熟悉程度分级，可以的话请细化具体的情况。
I. 没有听说过；
II. 仅限于听说过相关名词；
III. 听说过，且有一定了解；
IV. 听说过，且使用 Wasm 实际进行过开发（即便是玩具项目的开发）。
I. 没有听说过；
总结
→ 📖 Q0.3(P) 请记录下目前的时间。
3月22日，14:34。
Chapter.1 不畏迷茫，只管前进。（迷子でもいい、前へ進め。）
结对过程
→ 📖 Q1.1(P) 请记录下目前的时间。
3月22日，14:34。
→ 📖 Q1.2(P) 请在完成任务的同时记录，并在完成任务后整理完善：
- 浏览任务要求，参照 附录A：基于 PSP 2.1 修改的 PSP 表格，估计任务预计耗时；
- 完成编程任务期间，依次做了什么（比如查阅了什么资料，随后如何进行了开发，遇到了什么问题，又通过什么方式解决）；
查阅相关资料：包括assemblyscript相关文档：https://www.assemblyscript.org/introduction.html， 以及CSDN上复数对贪吃蛇策略的实现
熟悉任务已有的代码架构和任务要求
实际开发以及最终的简单测试
测试
→ 📖 Q1.3(P) 请说明针对该任务，你们设计和实现测试的方法及过程，包括但不限于：出于对需求的哪些考虑设计了哪些测试用例、如何评估所设计测试的有效性 等等。
以极端情况测试为主。在通过测试样例的基础上构造了一部分蛇靠墙、卷曲的样例进行极端情形测试。
→ 📖 Q1.4(I) 请说明单元测试对软件开发的作用。
单元测试能够帮助开发人员确认每个函数或方法的行为是否符合预期，从而保证代码的正确性。通过编写单元测试，开发人员能够发现并修复代码中的缺陷，进而提高代码的质量。此外，单元测试还鼓励开发人员编写更简洁、清晰、模块化的代码，以便于测试。
总结
→ 📖 Q1.5(P) 请记录下目前的时间，并根据实际情况填写 附录A：基于 PSP 2.1 修改的 PSP 表格 的“实际耗时”栏目。
3月22日，15:20
| Personal Software Process Stages | 个人软件开发流程 | 预估耗时（分钟） | 实际耗时（分钟） |
|---|---|---|---|
| PLANNING | 计划 | ||
| - Estimate - | 估计这个任务需要多少时间 | 10 | 9 |
| DEVELOPMENT | 开发 | ||
| - Analysis & Design Spec | - 需求分析 & 生成设计规格（确定要实现什么） | 10 | 5 |
| - Technical Background | - 了解技术背景（包括学习新技术） | 10 | 5 |
| - Coding Standard | - 代码规范 | 12 | 6 |
| - Design | - 具体设计（确定怎么实现） | 12 | 5 |
| - Coding | - 具体编码 | 20 | 20 |
| REPORTING | 报告 | ||
| - Quality Report | - 质量报告（评估设计、实现、测试的有效性） | 10 | 5 |
| - Size Measurement | - 计算工作量 | 10 | 5 |
| - Postmortem & Process Improvement Plan | - 事后总结和过程改进计划（总结过程中的问题和改进点） | 10 | 15 |
| TOTAL | 合计 | 102 | 75 |
→ 📖 Q1.6(I) 请写下本部分的心得体会。
基本的贪心算法，在结对编程视角下也没有太多影响。
Chapter.2 即使迷茫，也要前行。（迷子でもいい、迷子でも進め。）
结对过程
→ 📖 Q2.1(P) 请记录下目前的时间。
3月26日，14：01。
→ 📖 Q2.2(P) 请在完成任务的同时记录，并在完成任务后整理完善：
- 浏览任务要求，参照 附录A：基于 PSP 2.1 修改的 PSP 表格，估计任务预计耗时；
- 完成编程任务期间，依次做了什么（比如查阅了什么资料，随后如何进行了开发，遇到了什么问题，又通过什么方式解决）；
-
简单阅读项目要求，明确编码方向
-
以bfs思路编码
-
组织测试和总结
代码可复用性与需求变更
→ 📖 Q2.3(P) 请说明针对该任务，你们对 🧑💻 T2 中已实现的代码进行了哪些复用和修改。
出现的障碍物使得我们不再以简单的最近路径搜索来完成代码，需要使用bfs的整体框架来处置，但是由于只有一个果子不需要考虑后续生存问题，实际上没有太大的思路变化。
→ 📖 Q2.4(I) 请说明在编码实现时，可以采取哪些设计思想、考虑哪些设计冗余，来提高既存代码适应需求变更的能力。
t1-3使用 javascript直接实现，未对冗余性加以考虑。
头脑风暴环节
**→ 📖 Q2.5(P) **只吃一个食物可满足不了贪吃蛇的欲望，请一起思考并简述以下场景中贪吃蛇的策略：
在 🧑💻 T2 的基础上，场地里不再是只有 1 个果子，而是总共有 n 个果子 (1 < n < 10 )，果子随机分布在场地中且不会刷新，保证不与障碍物重叠，保证每个果子均可达，且至少存在一条成功吃掉所有果子的路线，其余条件保持不变，请你找出一条吃完所有果子的行动路径。
考虑A*？或者在bfs的基础上考虑生存问题。基本上四格身体不太可能撞死。
总结
→ 📖 Q2.6(P) 请记录下目前的时间，并根据实际情况填写 附录A：基于 PSP 2.1 修改的 PSP 表格 的“实际耗时”栏目。
3月26，15:11。
| Personal Software Process Stages | 个人软件开发流程 | 预估耗时（分钟） | 实际耗时（分钟） |
|---|---|---|---|
| PLANNING | 计划 | ||
| - Estimate - | 估计这个任务需要多少时间 | 10 | 5 |
| DEVELOPMENT | 开发 | ||
| - Analysis & Design Spec | - 需求分析 & 生成设计规格（确定要实现什么） | 10 | 5 |
| - Technical Background | - 了解技术背景（包括学习新技术） | 10 | 5 |
| - Coding Standard | - 代码规范 | 12 | 6 |
| - Design | - 具体设计（确定怎么实现） | 12 | 5 |
| - Coding | - 具体编码 | 20 | 20 |
| REPORTING | 报告 | ||
| - Quality Report | - 质量报告（评估设计、实现、测试的有效性） | 10 | 5 |
| - Size Measurement | - 计算工作量 | 10 | 5 |
| - Postmortem & Process Improvement Plan | - 事后总结和过程改进计划（总结过程中的问题和改进点） | 10 | 5 |
| TOTAL | 合计 | 102 | 62 |
→ 📖 Q2.7(I) 请写下本部分的心得体会。
简单的bfs其实没有什么好交接的。本身为贪吃蛇有查过一些资料，但在只有一个果子且蛇身为4的情况下其实很多策略都不再重要了。
Chapter.3 这就是我的前进、到我出场了！！！！！（It's MyGO!!!!!）
结对过程
→ 📖 Q3.1(P) 请记录下目前的时间。
4月4日，15:00。
→ 📖 Q3.2(P) 请在完成任务的同时记录，并在完成任务后整理完善：
- 浏览任务要求，参照 附录A：基于 PSP 2.1 修改的 PSP 表格，估计任务预计耗时；
- 完成编程任务期间，依次做了什么（比如查阅了什么资料，随后如何进行了开发，遇到了什么问题，又通过什么方式解决）；
-
阅读题目要求，清晰其与前两题的差别在哪
-
阅读代码，确定策略，决定直接对第二题的javascript进行修改
-
测试时发现javascript无法生成wasm
-
将其翻译为AssemblyScipt文件，并编译后进行npm测试
需求建模和算法设计
→ 📖 Q3.3(P) 请说明你们如何建模这一需求。
原以为将其他蛇的前节身体看作障碍，就能对第二部分代码进行复用，但实际上为了找果子的速率还是对代码进行了大幅度的修改。
→ 📖 Q3.4(P) 请说明针对该任务，你们采取了哪些策略来优化决策。具体而言，怎么避免死亡？怎么吃到更多果子？如何编程实现。
考虑到头相撞时两蛇同归于尽，根据简单的博弈论可以得出退让一定相对吃亏，因此决定对该种情况不避免（偷懒）。吃果子考虑从果子开始bfs，选择不会被争夺的果子中最近的那个去吃。
软件度量
→ 📖 Q3.5(P) 请说明你们如何量度所实现的程序模块的有效性，例如：“如何说明我们的程序模块对弈能力很强？”尝试提出一些可能的定量分析方式。
实际上并没有想出合适的定量分析方式，但通过找别人的蛇一起测试可以发现至少没有多余步和无端撞死的情况。有基本的对弈能力。
总结
→ 📖 Q3.6(P) 请记录下目前的时间，并根据实际情况填写 附录A：基于 PSP 2.1 修改的 PSP 表格 的“实际耗时”栏目。
| Personal Software Process Stages | 个人软件开发流程 | 预估耗时（分钟） | 实际耗时（分钟） |
|---|---|---|---|
| PLANNING | 计划 | ||
| - Estimate - | 估计这个任务需要多少时间 | 10 | 9 |
| DEVELOPMENT | 开发 | ||
| - Analysis & Design Spec | - 需求分析 & 生成设计规格（确定要实现什么） | 10 | 5 |
| - Technical Background | - 了解技术背景（包括学习新技术） | 10 | 15 |
| - Coding Standard | - 代码规范 | 12 | 8 |
| - Design | - 具体设计（确定怎么实现） | 20 | 25 |
| - Coding | - 具体编码 | 30 | 40 |
| REPORTING | 报告 | ||
| - Quality Report | - 质量报告（评估设计、实现、测试的有效性） | 15 | 20 |
| - Size Measurement | - 计算工作量 | 10 | 5 |
| - Postmortem & Process Improvement Plan | - 事后总结和过程改进计划（总结过程中的问题和改进点） | 10 | 15 |
| TOTAL | 合计 | 127 | 134 |
→ 📖 Q3.7(I) 请写下本部分的心得体会。
至少设计的过程还是挺有趣的，有些思路碍于时间没有实现。结对编程对我们思考一个足够简单的策略确实提供了很大的帮助。如果有机会的话会想再次尝试。
结对项目总结
结对过程回顾和反思
→ 📖 Q4.1(P) 提供两人在讨论的结对图像资料。
(不是我拍的)
→ 📖 Q4.2(P) 回顾结对的过程，反思有哪些可以提升和改进的地方。
角色交换不够频繁。驾驶员写上头了不愿意松开键盘，领航员有时发现问题无法及时传达。
→ 📖 Q4.3(I) 锐评一下你的搭档！并请至少列出三个优点和一个缺点。
优点：coding时认真细致，能发现很多小错误；资料搜索效率高，
缺点：拍照水平捉急。对编程本身积极性不高，更倾向于提供思路。
对结对编程的理解
→ 📖 Q4.4(I) 说明结对编程的优缺点、你对结对编程的理解。
优点：能够尽量结合两人的优点，互相弥补，提高代码质量；能够提供两人充分进行思想碰撞的机会，更容易交流出合适的策略。
缺点：任何多人配合项目都需要磨合，需要充足的时间供两人培养配合的默契，在这段时间的工作效率会偏低。如果最后两人都不能很好的配合，相当于浪费了磨合的时间。
浙公网安备 33010602011771号