[P] 结对项目：影蛇舞
| 项目 | 内容 |
|---|---|
| 这个作业属于哪个课程 | 2025年春季软件工程（罗杰、任健 |
| 这个作业的要求在哪里 | [I.1] 个人作业：阅读和提问 |
| 我在这个课程的目标是 | 学习系统化软件工程知识，增进个人专业化素养，打造令人满意的软件产品 |
| 这个作业在哪个具体方面帮助我实现目标 | 通过软件开发的全生命周期的深入阅读和学习，以极短的时间领略软件开发所需的专业知识 |
Chapter.0 Belua multorum es capitums.（你是多首的怪物。）
引入
→ 📖 Q0.1(P) 请记录下目前的时间。
3.23 2:03
调查
→ 📖 Q0.2(I) 作为本项目的调查：请如实标注在开始项目之前对 Wasm 的熟悉程度分级，可以的话请细化具体的情况。
I. 没有听说过；
II. 仅限于听说过相关名词；
III. 听说过，且有一定了解；
IV. 听说过，且使用 Wasm 实际进行过开发（即便是玩具项目的开发）。
II: 仅限于相关名词
总结
→ 📖 Q0.3(P) 请记录下目前的时间。
3.22 2:34
Chapter.1 不畏迷茫，只管前进。（迷子でもいい、前へ進め。）
结对过程
→ 📖 Q1.1(P) 请记录下目前的时间。
3.22 2:34
→ 📖 Q1.2(P) 请在完成任务的同时记录，并在完成任务后整理完善：
- 浏览任务要求，参照 附录A：基于 PSP 2.1 修改的 PSP 表格，估计任务预计耗时；
- 完成编程任务期间，依次做了什么（比如查阅了什么资料，随后如何进行了开发，遇到了什么问题，又通过什么方式解决）；
-
查阅相关资料：包括assemblyscript相关文档：https://www.assemblyscript.org/introduction.html， 以及CSDN上复数对贪吃蛇策略的实现
-
熟悉任务已有的代码架构和任务要求
-
实际开发以及最终的简单测试
测试
→ 📖 Q1.3(P) 请说明针对该任务，你们设计和实现测试的方法及过程，包括但不限于：出于对需求的哪些考虑设计了哪些测试用例、如何评估所设计测试的有效性 等等。
首先过了测试样例，后自行构建了一些较为极端的结果（如与墙角交互、蛇身位置较为少见的情况），其次进行了自动化、随机化的测试
→ 📖 Q1.4(I) 请说明<u>单元测试</u>对软件开发的作用。
-
早期缺陷发现
在代码编写阶段即可暴露问题，最小化后续debug成本 -
代码质量提升
迫使开发者编写可测试的代码（高内聚、低耦合），间接改善架构设计 -
模块套件可复用性
单元测试的完成意味着代码架构的某一模块具有相当的可靠性，可放心用于后续复用 -
开发效率提升
提供即时反馈循环，减少调试时间，不必在遇到bug时从代码架构角度细细拆分
总结
→ 📖 Q1.5(P) 请记录下目前的时间，并根据实际情况填写 附录A：基于 PSP 2.1 修改的 PSP 表格 的“实际耗时”栏目。
结束时间：3.22 3: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) 请说明在编码实现时，可以采取哪些<u>设计思想</u>、考虑哪些<u>设计冗余</u>，来提高既存代码适应需求变更的能力。
t1-3使用 javascript直接实现，未对冗余性加以考虑（因为知道最后要换别的）
头脑风暴环节
**→ 📖 Q2.5(P) **只吃一个食物可满足不了贪吃蛇的欲望，请一起思考并简述以下场景中贪吃蛇的策略：
在 🧑💻 T2 的基础上，场地里不再是只有 1 个果子，而是总共有 n 个果子 (1 < n < 10 )，果子随机分布在场地中且不会刷新，保证不与障碍物重叠，保证每个果子均可达，且至少存在一条成功吃掉所有果子的路线，其余条件保持不变，请你找出一条吃完所有果子的行动路径。
带路径的bfs即可解决
总结
→ 📖 Q2.6(P) 请记录下目前的时间，并根据实际情况填写 附录A：基于 PSP 2.1 修改的 PSP 表格 的“实际耗时”栏目。
结束时间3.26 3: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加上调整就完事了，测试也很简单
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) 请说明你们如何<u>建模</u>这一需求。
将其他🐍的四节身体看作障碍，使其与T2代码架构对齐，而后发现实际上第四节身体无需视为障碍，并调整思路
→ 📖 Q3.4(P) 请说明针对该任务，你们采取了<u>哪些策略</u>来优化决策。具体而言，怎么避免死亡？怎么吃到更多果子？如何编程实现。
策略：以果子为主体，反向进行BFS，保证最后选定的要前往的果子，离它最近的🐍一定是本🐍，并且这种策略也保证了在同一距离的其他的🐍无法通过改变方向来阻挡我们的道路，进而也一定程度上避免了死亡，而本身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) 锐评一下你的搭档！并请至少列出三个优点和一个缺点。
优点：
思维明察秋毫、代码风格高风亮节，编程速度一骑绝尘
缺点：
不拘小节，能够写出 i*8+1+1这一神奇代码
对结对编程的理解
→ 📖 Q4.4(I) 说明结对编程的优缺点、你对结对编程的理解。
两个人裨补阙漏，有所广益，并且能在交换思路、互相监督的过程中达到1+1>2的效果，在编码过程中即时发现小错误
但是毕竟是两个人，需要协调时间
浙公网安备 33010602011771号