[p] 结对项目：影蛇舞
[p] 结对项目：影蛇舞
| 项目 | 内容 |
|---|---|
| 这个作业属于哪个课程 | 2025年春季软件工程（罗杰、任健） (北京航空航天大学 - 计算机学院) |
| 这个作业的要求在哪里 | [P] 结对项目：影蛇舞 |
| 我在这个课程的目标是 | 深入学习软件工程，掌握其核心思想，增强自身团队合作能力，学会敏捷开发 |
| 这个作业在哪个具体方面帮助我实现目标 | 提高自己和队友的沟通能力和代码开发能力，在实践中提高软件开发能力，体会结对编程的魅力 |
结对项目：博客问题清单
请将本文件在代码仓库外复制一份，一边阅读和完成结对项目、一边填写入代码仓库外的版本，或采取简记、语音备忘等方式记载较复杂问题的要点之后再补充。请不要将本文档内的作答提交到代码仓库。
Chapter.0 Belua multorum es capitums.（你是多首的怪物。）
引入
→ 📖 Q0.1(P) 请记录下目前的时间。
2025.3.24 17:00
调查
→ 📖 Q0.2(I) 作为本项目的调查：请如实标注在开始项目之前对 Wasm 的熟悉程度分级，可以的话请细化具体的情况。
I. 没有听说过；
II. 仅限于听说过相关名词；
III. 听说过，且有一定了解；
IV. 听说过，且使用 Wasm 实际进行过开发（即便是玩具项目的开发）。
I. 没有听说过；
总结
→ 📖 Q0.3(P) 请记录下目前的时间。
2025.3.24 18:00
Chapter.1 不畏迷茫，只管前进。（迷子でもいい、前へ進め。）
结对过程
→ 📖 Q1.1(P) 请记录下目前的时间。
2025.3.24 18:00
→ 📖 Q1.2(P) 请在完成任务的同时记录，并在完成任务后整理完善：
- 浏览任务要求，参照 附录A：基于 PSP 2.1 修改的 PSP 表格，估计任务预计耗时；
- 完成编程任务期间，依次做了什么（比如查阅了什么资料，随后如何进行了开发，遇到了什么问题，又通过什么方式解决）；
| Personal Software Process Stages | 个人软件开发流程 | 预估耗时（分钟） | 实际耗时（分钟） |
|---|---|---|---|
| PLANNING | 计划 | ||
| - Estimate | - 估计这个任务需要多少时间 | 60 | 60 |
| DEVELOPMENT | 开发 | ||
| - Analysis & Design Spec | - 需求分析 & 生成设计规格（确定要实现什么） | 5 | 5 |
| - Technical Background | - 了解技术背景（包括学习新技术） | 10 | 10 |
| - Coding Standard | - 代码规范 | 1 | 1 |
| - Design | - 具体设计（确定怎么实现） | 1 | 1 |
| - Coding | - 具体编码 | 18 | 18 |
| - Code Review | - 代码复审 | 2 | 2 |
| - Test Design | - 测试设计（确定怎么测，比如要测试哪些情景、设计哪些种类的测试用例） | 10 | 10 |
| - Test Implement | - 测试实现（设计/生成具体的测试用例、编码实现测试） | 10 | 10 |
| REPORTING | 报告 | ||
| - Quality Report | - 质量报告（评估设计、实现、测试的有效性） | 1 | 1 |
| - Size Measurement | - 计算工作量 | 1 | 1 |
| - Postmortem & Process Improvement Plan | - 事后总结和过程改进计划（总结过程中的问题和改进点） | 1 | 1 |
| TOTAL | 合计 | 60 | 60 |
-
在T1中我们主要是对于rust语法不熟悉，结合LLM的帮助，边编程边学习语法，比如rust的弱类型系统，rust许多数据结构的使用等等
-
同时在测试部分也花了一些时间来编写测试样例进行测试
测试
→ 📖 Q1.3(P) 请说明针对该任务，你们设计和实现测试的方法及过程，包括但不限于：出于对需求的哪些考虑设计了哪些测试用例、如何评估所设计测试的有效性 等等。
- 测试样例都是我们手动编写的，后续也考量一下可否实现测评机
- 测试用例的考量是我们有针对普通情况，以及极端情况等来设计
→ 📖 Q1.4(I) 请说明单元测试对软件开发的作用。
单元测试是对代码的最小单元进行测试，可以在早期更有效的发现问题
总结
→ 📖 Q1.5(P) 请记录下目前的时间，并根据实际情况填写 附录A：基于 PSP 2.1 修改的 PSP 表格 的“实际耗时”栏目。
2025.3.24 19:00
→ 📖 Q1.6(I) 请写下本部分的心得体会。
T1 的内容相对较为基础，我们的主要目标是熟悉 Rust 语法，并掌握基本的编程模式。同时，我们将重点应用 G 课堂上讲授的流程，使用 wasm-pack 将 Rust 代码打包为 JavaScript 模块，并进行测试验证。
这一阶段不仅是对 Rust 语言的入门实践，也为后续更复杂的开发任务奠定了基础。通过实际操作，我们可以加深对 Rust + WebAssembly 生态的理解，并逐步提升代码的可读性、可维护性和优化能力。
Chapter.2 即使迷茫，也要前行。（迷子でもいい、迷子でも進め。）
结对过程
→ 📖 Q2.1(P) 请记录下目前的时间。
2025.3.24 19:00
→ 📖 Q2.2(P) 请在完成任务的同时记录，并在完成任务后整理完善：
- 浏览任务要求，参照 附录A：基于 PSP 2.1 修改的 PSP 表格，估计任务预计耗时；
- 完成编程任务期间，依次做了什么（比如查阅了什么资料，随后如何进行了开发，遇到了什么问题，又通过什么方式解决）；
| Personal Software Process Stages | 个人软件开发流程 | 预估耗时（分钟） | 实际耗时（分钟） |
|---|---|---|---|
| PLANNING | 计划 | ||
| - Estimate | - 估计这个任务需要多少时间 | 120 | 120 |
| DEVELOPMENT | 开发 | ||
| - Analysis & Design Spec | - 需求分析 & 生成设计规格（确定要实现什么） | 10 | 10 |
| - Technical Background | - 了解技术背景（包括学习新技术） | 20 | 20 |
| - Coding Standard | - 代码规范 | 2 | 2 |
| - Design | - 具体设计（确定怎么实现） | 2 | 2 |
| - Coding | - 具体编码 | 36 | 36 |
| - Code Review | - 代码复审 | 4 | 4 |
| - Test Design | - 测试设计（确定怎么测，比如要测试哪些情景、设计哪些种类的测试用例） | 20 | 20 |
| - Test Implement | - 测试实现（设计/生成具体的测试用例、编码实现测试） | 20 | 20 |
| REPORTING | 报告 | ||
| - Quality Report | - 质量报告（评估设计、实现、测试的有效性） | 2 | 2 |
| - Size Measurement | - 计算工作量 | 2 | 2 |
| - Postmortem & Process Improvement Plan | - 事后总结和过程改进计划（总结过程中的问题和改进点） | 2 | 2 |
| TOTAL | 合计 | 120 | 120 |
- 主要使用了BFS广度搜索算法来进行可达性判定，同时我们也做了一些细节上的处理，比如状态的保存，蛇身体作为障碍物的思考等等
- 过程中我们也进一步学习rust语法，比如对于队列数据结构的使用，全局变量的使用等等
代码可复用性与需求变更
→ 📖 Q2.3(P) 请说明针对该任务，你们对 🧑💻 T2 中已实现的代码进行了哪些复用和修改。
- T1中我们对于蛇是否会和自己蛇身碰撞的部分，以及是否会和场地碰撞的部分可以拿来复用，但整体改动较大
→ 📖 Q2.4(I) 请说明在编码实现时，可以采取哪些设计思想、考虑哪些设计冗余，来提高既存代码适应需求变更的能力。
- 在编码实现时，可以通过模块化和解耦的方式降低代码耦合度，例如将 BFS 逻辑与地图状态分离，便于未来扩展不同的搜索策略。同时，遵循开放封闭原则，使代码能够支持新增不可达逻辑，而无需修改核心结构，提升扩展性。此外，通过策略模式和配置化设计，使路径选择算法更加灵活，能够适应不同需求变化。为了增强代码的可扩展性，可以预留接口，如在 BFS 逻辑中增加路径过滤器，便于后续调整规则，并使用更灵活的数据结构（如图结构）来存储路径信息，以适应未来的优化需求。最后，通过添加日志记录和调试功能，方便问题排查，提高代码的可维护性和适应性。
头脑风暴环节
**→ 📖 Q2.5(P) **只吃一个食物可满足不了贪吃蛇的欲望，请一起思考并简述以下场景中贪吃蛇的策略：
在 🧑💻 T2 的基础上，场地里不再是只有 1 个果子，而是总共有 n 个果子 (1 < n < 10 )，果子随机分布在场地中且不会刷新，保证不与障碍物重叠，保证每个果子均可达，且至少存在一条成功吃掉所有果子的路线，其余条件保持不变，请你找出一条吃完所有果子的行动路径。
- 由于没有要求最短路径，且保证所有果子均可达，但需要判断每个果子是否位于“死路”（即吃掉它之后蛇无法再去吃其他果子），判断死路的办法为先让蛇吃到当前这个果子，再看其是否可达其他所有果子，如果不可以，当前果子位于“死路”中，由于题目保证了至少存在一条成功路径，那么这样子的“死路”果子最多只有一个，把它留在最后一个吃即可
总结
→ 📖 Q2.6(P) 请记录下目前的时间，并根据实际情况填写 附录A：基于 PSP 2.1 修改的 PSP 表格 的“实际耗时”栏目。
2025.3.24 21:00
→ 📖 Q2.7(I) 请写下本部分的心得体会。
- 在这一部分的合作中，我主要负责算法实现，而队友负责 WebAssembly 生态的运行环境搭建。这样的分工使我们能够专注于各自的领域，提高开发效率。我在编写算法的过程中，更加熟悉了核心逻辑的优化和实现，同时也了解到 WebAssembly 作为执行环境对代码结构的要求。虽然没有直接参与 WebAssembly 相关的配置和运行，但通过与队友的交流，我对其基本原理和工作流程也有了一定的理解。这次合作让我体会到团队分工的重要性，以及不同技术栈之间的衔接对项目整体推进的影响。
Chapter.3 这就是我的前进、到我出场了！！！！！（It's MyGO!!!!!）
结对过程
→ 📖 Q3.1(P) 请记录下目前的时间。
2025.3.31 4:00
→ 📖 Q3.2(P) 请在完成任务的同时记录，并在完成任务后整理完善：
- 浏览任务要求，参照 附录A：基于 PSP 2.1 修改的 PSP 表格，估计任务预计耗时；
- 完成编程任务期间，依次做了什么（比如查阅了什么资料，随后如何进行了开发，遇到了什么问题，又通过什么方式解决）；
| Personal Software Process Stages | 个人软件开发流程 | 预估耗时（分钟） | 实际耗时（分钟） |
|---|---|---|---|
| PLANNING | 计划 | ||
| - Estimate | - 估计这个任务需要多少时间 | 540 | 540 |
| DEVELOPMENT | 开发 | ||
| - Analysis & Design Spec | - 需求分析 & 生成设计规格（确定要实现什么） | 45 | 45 |
| - Technical Background | - 了解技术背景（包括学习新技术） | 90 | 90 |
| - Coding Standard | - 代码规范 | 9 | 9 |
| - Design | - 具体设计（确定怎么实现） | 9 | 9 |
| - Coding | - 具体编码 | 162 | 162 |
| - Code Review | - 代码复审 | 18 | 18 |
| - Test Design | - 测试设计（确定怎么测，比如要测试哪些情景、设计哪些种类的测试用例） | 90 | 90 |
| - Test Implement | - 测试实现（设计/生成具体的测试用例、编码实现测试） | 90 | 90 |
| REPORTING | 报告 | ||
| - Quality Report | - 质量报告（评估设计、实现、测试的有效性） | 9 | 9 |
| - Size Measurement | - 计算工作量 | 9 | 9 |
| - Postmortem & Process Improvement Plan | - 事后总结和过程改进计划（总结过程中的问题和改进点） | 9 | 9 |
| TOTAL | 合计 | 540 | 540 |
- 查阅资料：
- 一笔画最短路的状压DP写法
- rust深度学习框架BURN
- python深度学习算法
- rust语法
- 开发过程：
- 构思：
- 查阅资料，思考所有的优化可能性
- 思考了两种方法：纯算法 和 深度学习
- 深度学习：
- 考虑使用rust的深度学习框架BURN，但是发现学习成本太高
- 因此考虑先使用python将模型训练好，再将参数导入rust去跑神经网络
- 由于我们两都没有深度学习的基础，因此也具有一定的学习成本
- 所以最后决定，先使用纯算法进行测试，看看效果如何
- 纯算法：
- 优先考虑一笔画最短路，查阅资料发现需要使用状压DP（当然纯搜索也可以，因为只有十个果子）
- 后来发现，当要考虑其他蛇的位置之后，最短路的计算变得复杂起来，并且果子会实时更新，一笔画最短路需要的图构建起来会比较复杂，所以还是打算从简考虑
- 经过一番讨论，得到最终结论：
- 首先选取安全方向
- 通过代价函数判断每个方向的代价，来决定最终要走的方向
- 构思：
需求建模和算法设计
→ 📖 Q3.3(P) 请说明你们如何建模这一需求。
每次运行可以看作是在三个方向上进行选择的决策过程，我们的目标是在其中选取最佳方向。
核心策略：代价函数 + 安全方向策略
其中，代价函数 确保我们在前进过程中能够尽可能多地获取果子，而 安全方向策略 则保障我们尽可能长时间地存活，从而提高整体的生存能力和收益。
综合运用这两种策略，我们能够在保证安全的前提下，最大化收益，从而实现更优的决策。
→ 📖 Q3.4(P) 请说明针对该任务，你们采取了哪些策略来优化决策。具体而言，怎么避免死亡？怎么吃到更多果子？如何编程实现。
- 避障方面
- 我们针对边缘地带，只有没有其他蛇在附近的时候才会去，对于四个角（11，nn，1n，n1）我们去的条件更苛刻
- 我们不接受与另一条蛇同归于尽（在两个蛇都是离果子的距离为1的时候）
- 吃果子方面
- 我们对方向进行评分，影响因素有果子数量，果子距离，其他蛇是否离果子比我们还近等等
软件度量
→ 📖 Q3.5(P) 请说明你们如何量度所实现的程序模块的有效性，例如：“如何说明我们的程序模块对弈能力很强？”尝试提出一些可能的定量分析方式。
我们通过写python脚本，大量测试对局，获得一些有代表性的数据，如下图：
我们进行了课程组规定的比赛局数：6局的大量测试，发现我们程序在四条蛇种会有前三名的波动，总测试下来我们蛇获得第一的概率是最大的
同时我们还进行了对局数50，100的测试，当对局数非常大了之后，排名接近收敛（即我们的蛇可以稳定第一）
总结
→ 📖 Q3.6(P) 请记录下目前的时间，并根据实际情况填写 附录A：基于 PSP 2.1 修改的 PSP 表格 的“实际耗时”栏目。
2025.4.1 1:00
→ 📖 Q3.7(I) 请写下本部分的心得体会。
-
这次的体验非常棒，收获颇丰！不仅更深入地了解了 Rust 开发，还用 Python 编写脚本进行数据处理，并在不断优化策略的过程中加深了对问题求解的理解。同时，也初步接触了 机器学习（炼丹） 等方法，认识到它们在此类问题中的应用潜力。整个 T3 任务 设计得非常巧妙，解出来后成就感十足！
-
最有趣的是，最终发现大道至简——复杂的优化思路未必能带来更好的效果，反而是简单高效的算法往往能取得最佳结果。这次经历让我更加理解了算法设计的核心理念，也学到了如何在多种方法中权衡选择。
结对项目总结
结对过程回顾和反思
→ 📖 Q4.1(P) 提供两人在讨论的结对图像资料。
→ 📖 Q4.2(P) 回顾结对的过程，反思有哪些可以提升和改进的地方。
在结对编程的过程中，我们发现整体解决问题的流程仍有优化空间，特别是在问题的切入方式和开发节奏方面。
首先，在最初阶段，不应过早陷入细节，而应优先制定整体思路，快速实现一个简略版本进行验证。这种方法不仅可以帮助我们更早发现潜在问题，还能提高整体效率，避免在初期投入过多精力到可能不必要的细节上。
其次，我们可以采用迭代开发的方式，先实现核心功能，确保整体流程可行，然后逐步优化细节和提升性能。这种方法能够降低一次性开发的风险，确保每个阶段都有可验证的成果，从而提高开发的灵活性和适应性。
此外，在结对过程中，加强沟通与角色分工也是一个改进点。可以在每个阶段明确各自的任务，并定期回顾进展，以确保双方始终保持一致的思路和目标。通过不断优化这些方面，我们可以进一步提升结对编程的效率和质量。
→ 📖 Q4.3(I) 锐评一下你的搭档！并请至少列出三个优点和一个缺点。
-
超级靠谱，会提前预习！（惭愧了
-
代码能力很强，很快就能掌握rust的用法，运用刚学的语法快速构建起整体框架
-
优秀的逻辑思维和表达能力，让我们能高效的进行沟通
-
太能抗饿了（9个小时不吃饭，太痛苦了
对结对编程的理解
→ 📖 Q4.4(I) 说明结对编程的优缺点、你对结对编程的理解。
结对编程的优缺点体现在多个层面，它不仅影响代码质量和开发效率，还涉及到团队协作、思维碰撞和时间管理等方面。
- 从技术角度来看，结对编程的最大优势是代码质量的提升。两个人协作可以减少逻辑漏洞和低级错误，同时在代码风格、架构设计上也更容易达成共识。此外，由于即时交流，调试和优化的效率也更高。
- 从思维角度来看，结对编程提供了一种“双脑协同”的方式。不同的人思考问题的方式不同，合作过程中可以相互启发，避免思维定式或盲区，从而找到更优的解决方案。尤其是在面对复杂问题时，讨论往往能带来新的思路，使问题的求解更加高效。
- 从团队协作角度来看，结对编程能促进知识共享。经验丰富的一方可以帮助另一方快速上手新技术，而新人也可以从新的角度提出有价值的问题。这种知识流动有助于团队整体技术水平的提升。同时，结对编程还能营造更轻松的工作氛围，使开发过程更具互动性和趣味性。
- 然而，结对编程也有一些现实层面的挑战。最主要的问题是时间协调，两个人需要共同安排时间进行编码，这在项目进度紧张或个人日程繁忙时可能较难实现。此外，并非所有任务都适合结对编程，对于一些较为独立、明确的任务，单独完成可能更高效。
总体来说，结对编程是一种高效的开发模式，特别适用于复杂问题求解、代码质量要求高的场景，但在实际应用时需要考虑任务的性质和团队的时间协调问题，以找到最合适的协作方式。
浙公网安备 33010602011771号