[P]软工结对作业：影蛇舞

软工结对作业：影蛇舞

格式描述

项目	内容
这个作业属于哪个课程	软件工程
这个作业的要求在哪里	影蛇舞作业要求
我在这个课程的目标是	提升软件工程化能力，提升团队合作与交流沟通能力，培养敏捷开发能力
这个作业在哪个具体方面帮助我实现目标	培养结对编程与敏捷开发能力，熟练掌握GitHub等版本控制和协作开发平台的各类操作

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

引入

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

2025.03.27 10:52 - 2025.03.27 11:17

调查

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

I. 没有听说过；

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

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

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

I. 没有听说过

总结

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

2025.03.27 10:52 - 2025.03.27 11:17

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

结对过程

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

2025.03.28 14:57 - 2025.03.28 15:23
2025.03.28 19:18 - 2025.03.28 20:16

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

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

表格见总结部分。

在完成编程期间，我们主要查阅了Rust语言的基础语法、Rust-Wasm的编译文档，并进行了简单的开发实践。在这之中，由于初次接触Rust语言，我们也遇到一定问题，如编译过程中出现的模块丢失问题。经查验，发现是编译时命令使用出错：错用了 wasm-pack build --target web 指令，使得不能直接在js文件中引用和使用。

测试

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

章节一场景较为简单，不存在障碍物，同时数值为4的蛇身长度设置保证了正常情况下蛇不会出现锁死的状态。我们也使用样例进行了验证：在该任务中，主要需要测试蛇头与蛇身碰撞的情况，因此在正常样例外我们又设计了如下样例：蛇头和蛇身四个坐标呈正方形，果子、蛇头、蛇尾在同一直线上且蛇尾位于中央。经查验，算法对于样例效果良好。

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

单元测试是软件开发中的重要环节，它通过对代码的最小单元进行独立验证，确保各个模块的正确性和稳定性。单元测试能够提高代码质量，支持持续集成，降低缺陷率，同时加速开发过程，使代码更加可维护。尽管编写测试需要额外的时间投入，但它能够在长期减少调试成本，提升软件的可靠性。

总结

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

2025.03.28 14:57 - 2025.03.28 15:23
2025.03.28 19:18 - 2025.03.28 20:16

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

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

在任务耗时预估环节，我意识到合理的时间规划对于提高开发效率至关重要，但在简单的编程任务中，结对编程并未显示其优势。

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

结对过程

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

2025.03.31 15:18 - 2025.03.31 17:03

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

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

表格见总结部分。

在本章节中，出于对语言的学习目的，尝试使用了更加复杂的数据结构，如结构体、 Vec 队列等。在使用过程中，遇到很多语法问题，比如为通过 Wasm编译，需在结构体定义部分新加 #[derive(Clone, Copy, PartialEq, Eq, Hash)] 说明；为完成函数的参数传递，需要更改和对应可变和不可变引用；为重复独立使用变量，需要对变量进行 clone() 操作。通过查阅资料，并借助大模型，对错误代码进行了一定修改。

代码可复用性与需求变更

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

• 复用：章节一设置的算法较为简单，因此在章节二中复用性较弱。主要复用了章节一的数据解析部分。
• 修改：章节二重写了核心算法，主要采用了广度优先遍历算法，查找从果子出发，到达蛇头的最短路径和方向。同时，使用了更多的数据结构，并尝试了构建函数和变量引用传递。

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

设计思想：

1. 模块化：拆分功能，减少耦合。
2. 面向对象：用封装、继承、多态，提高复用性。

设计冗余：

1. 预留扩展点：关键流程中留出调用点，允许后续插入新要求，方便加新功能。

头脑风暴环节

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

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

可以把果子分类为四种，并进行分别讨论：

• 果子周边只有一格可达：可能有三种情况：位于地图顶角，周围有一个障碍；位于地图边，周围有两个障碍；位于地图中央，周围有三个障碍。对于这类果子，蛇应该最后吃掉。
• 果子周边有两格可达：在章节二中使用广度优先算法，并在其中规定，当从果子遍历到蛇时，停止搜索。这表明，蛇将要走的路径一定是最短路径。在最短路径下，一定不会出现当蛇吃到果子时，蛇身出现在果子另外两个方向的情况，即蛇身将蛇头围住。因此，正常吃果子即可。
• 果子周边有三格可达：情况与两格可达时相似。
• 果子周边有四格可达：情况与两格可达时相似。

总结

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

2025.03.31 15:18 - 2025.03.31 17:03

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

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

在T1的基础上进行代码复用和扩展，使我更加理解了如何编写可维护、可扩展的代码。通过合理的模块化设计和面向对象思想，我学会了如何在不修改原有代码的情况下添加新功能，提高了代码的灵活性。此外，在扩展过程中，我意识到预留扩展点的重要性，它能够减少后续改动的成本，让代码更具适应性。这次实践让我更深刻地体会到代码复用和扩展不仅能提升开发效率，还能优化系统结构，为后续迭代打下良好基础。

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

结对过程

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

2025.04.01 14:35 - 2025.04.01 18:02

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

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

表格见总结部分。

首先回顾了广度优先遍历算法，然后进行具体编码，在实现过程中发现了不同蛇下一步吃同一颗果子的相撞情况，为此进行系数调整，提高其他蛇到果子最短距离的权重；此外，有联想到了不同蛇在运动过程中蛇头相撞，因此找出其他蛇的蛇头下一步可能到达的格子，并在选择运动方向时候避开这些格子。

需求建模和算法设计

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

将其他蛇的蛇头蛇身所在坐标都视为障碍，之后实现策略仿效章节二采用广度优先遍历算法即可。

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

• 基本策略：
  • 采用广度优先遍历算法，获得每个果子到本蛇蛇头和其他蛇头的距离以及方向；
  • 对于每个果子，赋予果子到本蛇蛇头距离、果子到其他最近蛇蛇头距离权重，获得果子的得分（以距离本蛇越近，距离其他蛇越远为佳）；
  • 比较每个果子的得分，向得分最高的果子前进一格。
• 死亡避免：
  • 按照本蛇蛇头坐标，判断蛇头周围一格是否存在障碍（障碍及其他蛇）；
  • 按照本蛇蛇头坐标及其他蛇蛇头坐标，判断周围一格是否存在有其他蛇蛇头在下一轮次可以到达的情况，并尽量避免其他蛇蛇头可能到达的格子，降低同归于尽的可能。

软件度量

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

• 存活：将其他蛇的蛇头蛇身坐标以及它们即将可能到达的格子都视为障碍，在选取运动方向时候尽可能避开这些格子；

• 系数：给其它蛇蛇头到目标果子的最小距离赋予权重，这样在选择运动方向时就会避免选择离其它蛇更近的果子，减少了不同蛇争取同一个果子或者在运动过程中相撞的情况的出现；

• 得分：蛇吃掉果子得1分，分数理所当然的作为一个评价标准。

总结

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

2025.04.01 14:35 - 2025.04.01 18:02

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

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

在选择“优先存活”与“自杀式抢果子”策略时，我意识到每种策略有不同的适用场景和风险。优先存活偏向稳定，强调长期利益和安全；而自杀式抢果子更激进，追求快速回报，但风险大，失败可能导致严重后果。

选择策略时要根据当前目标和可能的后果。如果追求长期稳定，优先存活更合适；如果需要快速突破，自杀式策略可能更适用，但需要小心风险。这次思考让我理解了在决策时，要平衡短期和长期的需求，避免盲目激进。

结对项目总结

结对过程回顾和反思

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

约到研讨室和未约到研讨室的两人……

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

• 本次结对过程中，队友间的交流仍然不够，还需要多通过微信等社交软件多沟通；
• 本次结对过程中，分工不是十分明确，出现过一个人编程另一个人休息的局面，还是应该确定分工策略，提高并行效率；
• 本次结对过程中，对于时间安排规划不足，分多时段完成，以后可以商量出整块时间进行编程。

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

优点：

1. 行动能力强；
2. 时间规划合理；
3. 亲切近人，一直耐心听我唠叨；

缺点：

1. 缺点是让我在Q4.3缺点一栏目不知道写啥

对结对编程的理解

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

结对编程是一种两名开发者共同编写代码的工作方式。两人通过紧密合作，相互交流、讨论解决方案，一起编写和优化代码。通过这种方式，开发者可以互相检查代码，及时发现并纠正错误，提高代码质量。结对编程有助于知识共享和团队合作，尤其适合解决复杂问题。然而，对于一些简单任务，结对编程可能导致效率降低，因此在选择是否采用结对编程时，需要根据任务的复杂性和团队需求来决定。

代码实现提交

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

2025 SE - Pair Program

附录

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