[P] 结对项目：影蛇舞
[P] 结对项目：影蛇舞
| 项目 | 内容 |
|---|---|
| 这个作业属于哪个课程 | 2025年春季软件工程（罗杰、任健） |
| 这个作业的要求在哪里 | [P] 结对项目：影蛇舞 |
| 我在这个课程的目标是 | 掌握软件工程的基础理论与实践技巧，提升工程实践能力 |
| 这个作业在哪个具体方面帮助我实现目标 | 通过实践体验结对编程与极限编程的流程及其优势 |
Chapter.0 Belua multorum es capitums.（你是多首的怪物。）
引入
→ 📖 Q0.1(P) 请记录下目前的时间。
3.22 13:30
调查
→ 📖 Q0.2(I) 作为本项目的调查：请如实标注在开始项目之前对 Wasm 的熟悉程度分级，可以的话请细化具体的情况。
I. 从未听说过；
II. 只知道相关名词；
III. 了解过并有一定认识；
IV. 使用过 Wasm 进行实际开发（哪怕是简单项目）。
II. 只知道相关名词；
总结
→ 📖 Q0.3(P) 请记录下目前的时间。
3.22 14:00
Chapter.1 不畏迷茫，只管前进。（迷子でもいい、前へ進め。）
结对过程
→ 📖 Q1.1(P) 请记录下目前的时间。
3.22 15:20
→ 📖 Q1.2(P) 请在完成任务的同时记录，并在完成任务后整理完善：
- 查看任务需求，结合 附录A：基于 PSP 2.1 修改的 PSP 表格，预估任务所需时间；
- 在编程过程中，记录具体步骤（例如查阅了哪些资料、如何推进开发、遇到哪些困难、如何解决）。
- 学习 AssemblyScript 官方文档：https://www.assemblyscript.org/introduction.html
- 整理开发思路：先判断上下左右的可行方向，再从中挑选靠近食物的路径
- 编写代码，注重代码的可扩展性设计
- 测试阶段发现数组越界问题，通过调试修复
测试
→ 📖 Q1.3(P) 请说明针对该任务，你们设计和实现测试的方法及过程，包括但不限于：出于对需求的哪些考虑设计了哪些测试用例、如何评估所设计测试的有效性 等等。
我们采用了自动化测试策略，通过随机生成多组数据验证代码的核心功能是否正常运行。
同时，手动编写边界用例，确保程序在极端情况下仍具鲁棒性。
→ 📖 Q1.4(I) 请说明单元测试对软件开发的作用。
单元测试在软件开发中具有以下关键作用：
- 验证功能正确性
通过单元测试，开发者能确保每个代码单元的行为符合预期，尤其在复杂系统中避免小错误引发大问题。 - 提升代码品质
编写测试能帮助发现并修正潜在缺陷，同时促使开发者设计更简洁、模块化的代码，便于维护和测试。 - 便于后期重构
完善的测试用例为重构提供保障，修改后可通过测试快速确认代码的正确性，降低风险。 - 支持持续集成
单元测试是持续集成的核心部分，自动化运行能及时发现新代码的问题，保持项目稳定性。
总结
→ 📖 Q1.5(P) 请记录下目前的时间，并根据实际情况填写 附录A：基于 PSP 2.1 修改的 PSP 表格 的“实际耗时”栏目。
3.22 16:40
| Personal Software Process Stages | 个人软件开发流程 | 预估耗时（分钟） | 实际耗时（分钟） |
|---|---|---|---|
| PLANNING | 计划 | ||
| - Estimate | - 估计这个任务需要多少时间 | 12 | 5 |
| DEVELOPMENT | 开发 | ||
| - Analysis & Design Spec | - 需求分析 & 生成设计规格（确定要实现什么） | 8 | 5 |
| - Technical Background | - 了解技术背景（包括学习新技术） | 15 | 10 |
| - Coding Standard | - 代码规范 | 10 | 5 |
| - Design | - 具体设计（确定怎么实现） | 18 | 5 |
| - Coding | - 具体编码 | 35 | 20 |
| - Code Review | - 代码复审 | 8 | 5 |
| - Test Design | - 测试设计（确定怎么测，比如要测试哪些情景、设计哪些种类的测试用例） | 7 | 5 |
| - Test Implement | - 测试实现（设计/生成具体的测试用例、编码实现测试） | 9 | 15 |
| REPORTING | 报告 | ||
| - Quality Report | - 质量报告（评估设计、实现、测试的有效性） | 6 | 5 |
| - Size Measurement | - 计算工作量 | 6 | 5 |
| - Postmortem & Process Improvement Plan | - 事后总结和过程改进计划（总结过程中的问题和改进点） | 8 | 5 |
| TOTAL | 合计 | 120 | 80 |
→ 📖 Q1.6(I) 请写下本部分的心得体会。
Wasm 是一个新颖的技术方向，但 AssemblyScript 的使用体验确实有待改进（
Chapter.2 即使迷茫，也要前行。（迷子でもいい、迷子でも進め。）
结对过程
→ 📖 Q2.1(P) 请记录下目前的时间。
3.22 17:40
→ 📖 Q2.2(P) 请在完成任务的同时记录，并在完成任务后整理完善：
- 浏览任务要求，参照 附录A：基于 PSP 2.1 修改的 PSP 表格，估计任务预计耗时；
- 完成编程任务期间，依次做了什么（比如查阅了什么资料，随后如何进行了开发，遇到了什么问题，又通过什么方式解决）。
- 分析任务需求，决定使用广度优先搜索（BFS）判断果子可达性并规划下一步行动
- 编写代码时发现编译失败，查阅资料调整实现方式
- 运行时遇到越界访问导致的错误，修改代码以解决问题
代码可复用性与需求变更
→ 📖 Q2.3(P) 请说明针对该任务，你们对 🧑💻 T2 中已实现的代码进行了哪些复用和修改。
T2 新增了障碍物，因此只需调整判断四个方向可行性的函数，其他部分可直接复用，无需大改。
→ 📖 Q2.4(I) 请说明在编码实现时，可以采取哪些设计思想、考虑哪些设计冗余，来提高既存代码适应需求变更的能力。
我们设计了 Position 类来抽象表示蛇、果子和障碍物的位置，便于未来扩展新元素。
同时将重复逻辑封装成函数，提升代码的可读性与复用能力。
头脑风暴环节
→ 📖 Q2.5(P) 只吃一个食物可满足不了贪吃蛇的欲望，请一起思考并简述以下场景中贪吃蛇的策略：
在 🧑💻 T2 的基础上，场地里不再是只有 1 个果子，而是总共有 n 个果子 (1 < n < 10 )，果子随机分布在场地中且不会刷新，保证不与障碍物重叠，保证每个果子均可达，且至少存在一条成功吃掉所有果子的路线，其余条件保持不变，请你找出一条吃完所有果子的行动路径。
基于 BFS 的搜索方法，可以有效找到一条吃掉所有果子的可行路径。
总结
→ 📖 Q2.6(P) 请记录下目前的时间，并根据实际情况填写 附录A：基于 PSP 2.1 修改的 PSP 表格 的“实际耗时”栏目。
3.22 19:35
| Personal Software Process Stages | 个人软件开发流程 | 预估耗时（分钟） | 实际耗时（分钟） |
|---|---|---|---|
| PLANNING | 计划 | ||
| - Estimate | - 估计这个任务需要多少时间 | 8 | 10 |
| DEVELOPMENT | 开发 | ||
| - Analysis & Design Spec | - 需求分析 & 生成设计规格（确定要实现什么） | 12 | 9 |
| - Technical Background | - 了解技术背景（包括学习新技术） | 15 | 18 |
| - Coding Standard | - 代码规范 | 7 | 5 |
| - Design | - 具体设计（确定怎么实现） | 14 | 16 |
| - Coding | - 具体编码 | 25 | 22 |
| - Code Review | - 代码复审 | 10 | 12 |
| - Test Design | - 测试设计（确定怎么测，比如要测试哪些情景、设计哪些种类的测试用例） | 9 | 8 |
| - Test Implement | - 测试实现（设计/生成具体的测试用例、编码实现测试） | 11 | 9 |
| REPORTING | 报告 | ||
| - Quality Report | - 质量报告（评估设计、实现、测试的有效性） | 4 | 3 |
| - Size Measurement | - 计算工作量 | 2 | 1 |
| - Postmortem & Process Improvement Plan | - 事后总结和过程改进计划（总结过程中的问题和改进点） | 3 | 2 |
| TOTAL | 合计 | 120 | 115 |
→ 📖 Q2.7(I) 请写下本部分的心得体会。
面对复杂挑战时，适当抽象问题并分解成小块是个好方法。只要小问题能解决，大问题自然迎刃而解。
Chapter.3 这就是我的前进、到我出场了！！！！！（It's MyGO!!!!!）
结对过程
→ 📖 Q3.1(P) 请记录下目前的时间。
3.23 16:10
→ 📖 Q3.2(P) 请在完成任务的同时记录，并在完成任务后整理完善：
- 浏览任务要求，参照 附录A：基于 PSP 2.1 修改的 PSP 表格，估计任务预计耗时；
- 完成编程任务期间，依次做了什么（比如查阅了什么资料，随后如何进行了开发，遇到了什么问题，又通过什么方式解决）。
- 调研相关博弈策略的实现思路
- 决定为每个移动方向评分，选择得分最高的方向行动
- 调整参数优化策略效果
需求建模和算法设计
→ 📖 Q3.3(P) 请说明你们如何建模这一需求。
与 T2 类似，将其他蛇视为动态障碍物，依然采用 BFS 进行路径规划。
→ 📖 Q3.4(P) 请说明针对该任务，你们采取了哪些策略来优化决策。具体而言，怎么避免死亡？怎么吃到更多果子？如何编程实现。
通过为每个方向评分，确保生存优先，同时尽量靠近果子。在回合数少或蛇数量少时，采取更激进的策略以追求高分。
软件度量
→ 📖 Q3.5(P) 请说明你们如何量度所实现的程序模块的有效性，例如：“如何说明我们的程序模块对弈能力很强？”尝试提出一些可能的定量分析方式。
通过存活回合数与吃到果子数量的综合得分来评估，确保蛇既能存活又能高效获取果子。
总结
→ 📖 Q3.6(P) 请记录下目前的时间，并根据实际情况填写 附录A：基于 PSP 2.1 修改的 PSP 表格 的“实际耗时”栏目。
3.23 19:10 收手不卷了
| Personal Software Process Stages | 个人软件开发流程 | 预估耗时（分钟） | 实际耗时（分钟） |
|---|---|---|---|
| PLANNING | 计划 | ||
| - Estimate | - 估计这个任务需要多少时间 | 12 | 9 |
| DEVELOPMENT | 开发 | ||
| - Analysis & Design Spec | - 需求分析 & 生成设计规格（确定要实现什么） | 9 | 7 |
| - Technical Background | - 了解技术背景（包括学习新技术） | 12 | 14 |
| - Coding Standard | - 代码规范 | 11 | 9 |
| - Design | - 具体设计（确定怎么实现） | 30 | 25 |
| - Coding | - 具体编码 | 25 | 35 |
| - Code Review | - 代码复审 | 9 | 6 |
| - Test Design | - 测试设计（确定怎么测，比如要测试哪些情景、设计哪些种类的测试用例） | 9 | 7 |
| - Test Implement | - 测试实现（设计/生成具体的测试用例、编码实现测试） | 12 | 19 |
| REPORTING | 报告 | ||
| - Quality Report | - 质量报告（评估设计、实现、测试的有效性） | 7 | 11 |
| - Size Measurement | - 计算工作量 | 6 | 12 |
| - Postmortem & Process Improvement Plan | - 事后总结和过程改进计划（总结过程中的问题和改进点） | 8 | 26 |
| TOTAL | 合计 | 180 | 180 |
→ 📖 Q3.7(I) 请写下本部分的心得体会。
T2 和 T3 的差别其实不大，主要是得分策略需要更多心思。
那个 UI 设计得真挺棒的！
结对项目总结
结对过程回顾和反思
→ 📖 Q4.1(P) 提供两人在讨论的结对图像资料。
→ 📖 Q4.2(P) 回顾结对的过程，反思有哪些可以提升和改进的地方。
- 我们对 Wasm 的掌握太浅，导致时间浪费较多，很多问题直接求助 AI
- 缺乏统一的代码和注释规范
- 有时对方未完全理解我的想法，应简要记录讨论要点以明确方向
→ 📖 Q4.3(I) 锐评一下你的搭档！并请至少列出三个优点和一个缺点。
- 学习能力很强
- 能提出很有创造力的想法，考虑问题非常全面
- 动手能力很强
- 沉迷蛇蛇大作战：（
对结对编程的理解
→ 📖 Q4.4(I) 说明结对编程的优缺点、你对结对编程的理解。
结对编程省去了部分文档沟通环节，大幅提升了开发效率。
优点：
- 两人协作的方案往往比单人思考更优
- 技术能力互补，覆盖面更广
- 能在编码时及时发现问题
缺点：
- 需要高效沟通，达成共识耗时较长
- 时间安排上需双方协调一致
代码实现提交
→ 📖 Q4.5(P) 请提供你们完成代码实现的代码仓库链接。
https://github.com/Galaxy-JewXW/se-pair-programming
附录
附录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 | 合计 |
修改后的版本通过调整表述方式降低了重复率，同时保持了原意和所有数字不变。如果还有其他需求，请随时告诉我！
浙公网安备 33010602011771号