[P] 结对项目：影蛇舞
课程信息
| 项目 | 内容 |
|---|---|
| 这个作业属于哪个课程 | 2025年春季软件工程（罗杰、任健） |
| 这个作业的要求在哪里 | [P] 结对项目：影蛇舞 |
| 我在这个课程的目标是 | 学习并应用软件工程的方法论，掌握开发软件的先进工具，开发一款有趣的软件 |
| 这个作业在哪个具体方面帮助我实现目标 | 收获结对编程的经验，提高合作表达能力 |
Chapter.0 Belua multorum es capitums.（你是多首的怪物。）
引入
→ 📖 Q0.1(P) 请记录下目前的时间。
2025.3.24 20:30
调查
→ 📖 Q0.2(I) 作为本项目的调查：请如实标注在开始项目之前对 Wasm 的熟悉程度分级，可以的话请细化具体的情况。
I. 没有听说过；
II. 仅限于听说过相关名词；
III. 听说过，且有一定了解；
IV. 听说过，且使用 Wasm 实际进行过开发（即便是玩具项目的开发）。
I. 没有听说过
总结
→ 📖 Q0.3(P) 请记录下目前的时间。
2025/3/24 21:35
Chapter.1 不畏迷茫，只管前进。（迷子でもいい、前へ進め。）
结对过程
→ 📖 Q1.1(P) 请记录下目前的时间。
2025/3/24 21:40
→ 📖 Q1.2(P) 请在完成任务的同时记录，并在完成任务后整理完善：
浏览任务要求，参照 附录A：基于 PSP 2.1 修改的 PSP 表格，估计任务预计耗时；
完成编程任务期间，依次做了什么（比如查阅了什么资料，随后如何进行了开发，遇到了什么问题，又通过什么方式解决）；
| Personal Software Process Stages | 个人软件开发流程 | 预估耗时（分钟） | 实际耗时（分钟） |
| PLANNING | 计划 | ||
| - Estimate | - 任务分解和总耗时估计 | 5 | 3 |
| DEVELOPMENT | 开发 | ||
| - Analysis & Design Spec | - 需求分析 & 设计规格（贪吃蛇规则解析） | 10 | 20 |
| - Technical Background | - WebAssembly 技术学习（工具链配置/ RUST 语法） | 25 | 20 |
| - Coding Standard | - 代码规范制定 | 5 | 4 |
| - Design | - 算法设计（路径搜索） | 20 | 9 |
| - Code Review | - 代码审查 | 15 | 10 |
| - Test Design | - 测试用例设计 | 10 | 4 |
| - Test Implement | - 单元测试/集成测试 | 15 | 4 |
| REPORTING | 报告 | ||
| - Quality Report | - 性能分析 | 5 | 2 |
| - Size Measurement | - 代码量统计 | 5 | 2 |
| - Postmortem & Process Improvement Plan | - 结对过程反思总结 | 5 | 2 |
| TOTAL | 合计 | 120 | 80 |
我们选取了 rust 作为编程语言。由于有 Chapter 0 部分的引入以及课程组提供的许多参考资料可供学习，整个开发过程推进的还是较为顺利。
我们的算法思路比较简单粗暴：由于题目涉及的情景比较简单（场地里仅存在长度固定为4的蛇和果子，没有其他干扰项），同时回合限制和时间限制都比较宽松（最多1000ms），我们直接采用暴力的BFS，找到吃到果子的最短路径。同时，在移动的过程中针对四个方向进行障碍物检测，避免死亡。
在实践中我们主要遇到了如下两个问题：
-
打包工具使用错误：最初我们错误地使用了 web 作为打包工具，而任务要求使用 nodejs。发现问题后，我们重新检查了任务文档，明确了正确的打包工具。
-
蛇移动时尾部移除情况未考虑：在测试过程中，我们发现课程组给的测试样例 3 中蛇出生在角落时会被自己卡住无法移动。经过仔细分析，我们意识到是没有考虑蛇移动时原先蛇尾所处格子也会变空的情况。于是，我们重新审视算法设计，改善了蛇移动的逻辑，经过测试，问题得到解决。
测试
→ 📖 Q1.3(P) 请说明针对该任务，你们设计和实现测试的方法及过程，包括但不限于：出于对需求的哪些考虑设计了哪些测试用例、如何评估所设计测试的有效性 等等。
考虑到题设场景相对简单，我们选择采用构造样例的方式来设计和实施测试。具体而言，我们在课程组提供的 greedy_snake_fn_checker 函数的基础上，考虑了以下几类条件的数据来设计测试用例：
-
基本方向移动 为了确保蛇在简单情况下能正确响应果子的位置，我们构造了果子在蛇头上下左右不同方向时的用例。
-
特殊位置情况
- 当蛇被自身身体紧密环绕、陷入 “自我包围” 的困境时，程序应引导其朝着尾部方向移动，从而成功摆脱包围。
-
边界条件需求 我们设计了蛇出生在边界以及果子放在边界的的测试用例来验证蛇头位于边界附近时程序的行为。
为了评估所设计测试的有效性，我们从以下两个维度展开考量：
-
测试用例的多样性：丰富多样的测试用例能够从多个不同视角对程序进行全方位检测，保证测试的全面性与完整性。
-
问题发现能力：程序出现错误时，若测试用例能够迅速反馈，助力我们精准定位问题根源并加以解决，那么该测试具备良好的问题发现能力。
基于上述评估角度来看，鉴于题设条件本身相对简单，我们所设计的测试用例做到了丰富且全面，充分覆盖了各类可能出现的情况；并且，测试用例切实发挥了重要作用，帮助我们敏锐地意识到在蛇移动时，其尾部所处格子会空出这一容易被忽视的情况，展现出了较强的问题发现能力 。
→ 📖 Q1.4(I) 请说明单元测试对软件开发的作用。
-
单元测试于开发早期对函数及模块展开独立测试，能够敏锐捕捉到逻辑错误、边界处理失误等问题，极大程度地削减修复成本，有力提升软件的整体品质。同时，针对各个特定功能点，通过运用丰富多样的输入来验证输出，以此确保软件组件严格依照设计预期正常运作，有效增强软件的可靠性与稳定性。
-
编写单元测试推动代码朝着模块化、结构化方向发展，显著提升代码的可理解性与可维护性。当代码发生变动时，能够迅速对是否引入新错误进行验证，稳固代码质量。在开展代码重构工作时，运行单元测试能够及时检验重构是否对原有功能造成影响，大幅降低重构所带来的风险。
-
在团队开发场景中，多人同步修改代码的情况下，单元测试能够切实保障个人的修改不会对其他模块产生干扰。借助持续集成工具，每次代码提交时都能自动触发测试流程，及时发现并解决代码冲突以及兼容性问题。
总结
→ 📖 Q1.5(P) 请记录下目前的时间，并根据实际情况填写 附录A：基于 PSP 2.1 修改的 PSP 表格 的“实际耗时”栏目。
2025/3/24 23:00
PSP表格见 Q1.2
→ 📖 Q1.6(I) 请写下本部分的心得体会。
学到了rust的一些语法，初步接触了wasm编程，感觉很有收获
Chapter.2 即使迷茫，也要前行。（迷子でもいい、迷子でも進め。）
结对过程
→ 📖 Q2.1(P) 请记录下目前的时间。
2025/3/25 20:00
→ 📖 Q2.2(P) 请在完成任务的同时记录，并在完成任务后整理完善：
浏览任务要求，参照 附录A：基于 PSP 2.1 修改的 PSP 表格，估计任务预计耗时；
完成编程任务期间，依次做了什么（比如查阅了什么资料，随后如何进行了开发，遇到了什么问题，又通过什么方式解决）；
| Personal Software Process Stages | 个人软件开发流程 | 预估耗时（分钟） | 实际耗时（分钟） |
| PLANNING | 计划 | ||
| - Estimate | - 任务分解和总耗时估计 | 5 | 2 |
| DEVELOPMENT | 开发 | ||
| - Analysis & Design Spec | - 需求分析 & 设计规格（贪吃蛇规则解析） | 15 | 10 |
| - Technical Background | - WebAssembly 技术学习（工具链配置/ RUST 语法） | 30 | 8 |
| - Coding Standard | - 代码规范制定 | 8 | 3 |
| - Design | - 算法设计（路径搜索） | 25 | 8 |
| - Code Review | - 代码审查 | 20 | 16 |
| - Test Design | - 测试用例设计 | 15 | 3 |
| - Test Implement | - 单元测试/集成测试 | 22 | 4 |
| REPORTING | 报告 | ||
| - Quality Report | - 性能分析 | 10 | 2 |
| - Size Measurement | - 代码量统计 | 5 | 2 |
| - Postmortem & Process Improvement Plan | - 结对过程反思总结 | 5 | 2 |
| TOTAL | 合计 | 160 | 60 |
T2 进行的非常顺利。这是因为题目相较于上一问仅增添了12个障碍物。由于我们在 T1 中采用 BFS 实现，在应对此次变化时，只需将新增的障碍物加入到原有的障碍物数组中，程序就能达到避障的效果。此外，当蛇吃不到果子时，通过 BFS 也可以直接判断出不可达。
值得一提的是，由于题目变得复杂，我们不再采用构造样例的测试方法，而是借助 AI 编写了一份随机生成障碍物的自动化脚本，进行了 1000 轮测试。在测试过程中，我们考量了果子可达与不可达的不同情况，提升了测试的全面性与可靠性 。
代码可复用性与需求变更
→ 📖 Q2.3(P) 请说明针对该任务，你们对 🧑💻 T2 中已实现的代码进行了哪些复用和修改。
T1 中的框架基本上得到了完整复用，包括其中的 BFS 算法、障碍物检测等部分。只是增加了障碍物数组的输入以及可达性的判断。
→ 📖 Q2.4(I) 请说明在编码实现时，可以采取哪些设计思想、考虑哪些设计冗余，来提高既存代码适应需求变更的能力。
-
设计思想
-
模块化设计：将代码按照功能划分为不同的模块，每个模块专注于特定的功能，相互之间通过明确的接口进行交互。这样当需求变更时，只需要修改或替换相关的模块，而不会对整个系统造成大规模影响。
-
抽象化设计：提取代码中的共性部分，将其抽象成通用的接口或类，增强可扩展性。
-
-
设计冗余
-
预留扩展接口：在代码中提前设计一些预留接口，当需求变更时，可以通过实现这些接口来添加新功能。
-
参数化设计：对代码中一些具备变化可能性的部分进行参数化处理。通过调整参数数值，便能有效应对需求的变更情况。
-
头脑风暴环节
→ 📖 Q2.5(P) 只吃一个食物可满足不了贪吃蛇的欲望，请一起思考并简述以下场景中贪吃蛇的策略：
在 🧑💻 T2 的基础上，场地里不再是只有 1 个果子，而是总共有 n 个果子 (1 < n < 10 )，果子随机分布在场地中且不会刷新，保证不与障碍物重叠，保证每个果子均可达，且至少存在一条成功吃掉所有果子的路线，其余条件保持不变，请你找出一条吃完所有果子的行动路径。
采用简单的贪心算法，从初始位置用 BFS 找到最近的果子去吃，吃到后，更新蛇的位置与场地状态，对剩余果子再用 BFS 找果子。不断重复此过程直至吃完所有果子，过程中进行适当的避障检测。由于可能存在某果子在 “死路”（因为必存在能全吃完的路线，这样的果子至多一个），BFS 时记录果子位置与路径信息，判断出该果子并排除这一选择即可。
总结
→ 📖 Q2.6(P) 请记录下目前的时间，并根据实际情况填写 附录A：基于 PSP 2.1 修改的 PSP 表格 的“实际耗时”栏目。
2025/3/25 21:00
PSP表格见 Q2.2
→ 📖 Q2.7(I) 请写下本部分的心得体会。
Q1 的工作完美顺延到了 Q2，非常幸运
Chapter.3 这就是我的前进、到我出场了！！！！！（It's MyGO!!!!!）
结对过程
→ 📖 Q3.1(P) 请记录下目前的时间。
2025/4/1 19:00
→ 📖 Q3.2(P) 请在完成任务的同时记录，并在完成任务后整理完善：
浏览任务要求，参照 附录A：基于 PSP 2.1 修改的 PSP 表格，估计任务预计耗时；
完成编程任务期间，依次做了什么（比如查阅了什么资料，随后如何进行了开发，遇到了什么问题，又通过什么方式解决）；
| Personal Software Process Stages | 个人软件开发流程 | 预估耗时（分钟） | 实际耗时（分钟） |
| PLANNING | 计划 | ||
| - Estimate | - 任务分解和总耗时估计 | 5 | 5 |
| DEVELOPMENT | 开发 | ||
| - Analysis & Design Spec | - 需求分析 & 设计规格（贪吃蛇规则解析） | 25 | 45 |
| - Technical Background | - WebAssembly 技术学习（工具链配置/ RUST 语法） | 30 | 10 |
| - Coding Standard | - 代码规范制定 | 10 | 10 |
| - Design | - 算法设计（路径搜索） | 140 | 100 |
| - Code Review | - 代码审查 | 60 | 60 |
| - Test Design | - 测试用例设计 | 20 | 20 |
| - Test Implement | - 单元测试/集成测试 | 30 | 10 |
| REPORTING | 报告 | ||
| - Quality Report | - 性能分析 | 15 | 15 |
| - Size Measurement | - 代码量统计 | 10 | 10 |
| - Postmortem & Process Improvement Plan | - 结对过程反思总结 | 15 | 15 |
| TOTAL | 合计 | 360 | 300 |
需求建模和算法设计
→ 📖 Q3.3(P) 请说明你们如何建模这一需求。
不同于上述两问，Q3 引入了其他蛇的存在，需要我们将其视作一个动态移动的障碍物并进行相应的避障检测。
经过讨论，我们认为总共有三大需求需要权衡：
-
尽量吃到多的果子
-
尽量保证自己不被击杀，避免死亡
-
争取将敌人杀掉
→ 📖 Q3.4(P) 请说明针对该任务，你们采取了哪些策略来优化决策。具体而言，怎么避免死亡？怎么吃到更多果子？如何编程实现。
为了更有效地平衡 Q3.3 中所考量的三大需求，我们采用了 Q2.4 中提到的参数化设计理念。具体来说，针对蛇的行为表现，我们设定了生存得分、吃果子得分以及击杀得分，以此实现激进与保守策略之间的权衡（对应的应用场景有 1v1 模式中会激进些，大乱斗时则保守些）。当然，设定参数时我们也有设想借助深度学习进行参数调优，但由于前期代码编写已经快要超过课程组建议的 6 个小时，最终还是放弃了这一计划（我们也实在是写不动了/(ㄒoㄒ)/~~）
-
为了避免死亡我们考虑了：
-
不碰到边界和蛇身
-
尽可能预测其他蛇头的下一步行动轨迹。例如蛇大概率会朝着果子的方向移动。通过这样的预判，提前规避与其他蛇头发生正面碰撞的风险。
-
-
对于尽量吃到更多果子我们考虑了：
- 采用简单的贪心算法，找到和果子有着最近的曼哈顿距离的蛇头下一位置
-
争取杀人我们考虑了：
-
当走的下一步能够使得在下一回合中，对方蛇头很大概率无路可走时（如逼到角落时），考虑其击杀分
-
统计场上当前蛇的得分，当处在第一且有机会与第二同归于尽时，考虑其击杀分（尤其是在1v1模式中）
-
为了实现上述需求，我们建模了地图和其他蛇的身体，并通过其他蛇的移动轨迹判断其是否得分，以此来统计场上所有蛇的得分。然后我们通过简单的模拟，考虑我方蛇和敌方蛇的下一步，判断是否会碰触边界和是否有机会击杀敌蛇。
软件度量
→ 📖 Q3.5(P) 请说明你们如何量度所实现的程序模块的有效性，例如：“如何说明我们的程序模块对弈能力很强？”尝试提出一些可能的定量分析方式。
-
我们首先借助 GUI 界面，对程序模块在 1v1 对弈场景下的表现进行直观观测，以此初步判断特定功能是否成功实现。比如在考察攻击策略时，我们会看蛇在分数领先时会不会有尝试攻击敌蛇的倾向。由于我们采用参数化设计，为每个策略赋予了权重，在考察具体策略时我们会将其权重设置一个较大值
-
我们还将不同策略权重的蛇进行自我博弈，考量哪一策略更有利取得胜利。我们得出的结论是：1v1 模式时有必要激进一些，攻击的权重可以调大，大乱斗时则可以保守些
-
当然还有找了其他组的蛇进行“赛博斗蛐蛐”，并通过在不同模式下的胜率来评估（虽然感觉还是很看运气，大部分时候都是五五开）
总结
→ 📖 Q3.6(P) 请记录下目前的时间，并根据实际情况填写 附录A：基于 PSP 2.1 修改的 PSP 表格 的“实际耗时”栏目。
2025/4/1 24:00
PSP表格见 Q3.2
→ 📖 Q3.7(I) 请写下本部分的心得体会。
总算是完结了。虽然我们的蛇表现出来还是有一点呆，但还是感到很有收获，无论是在新的语言学习还是算法设计上都学到了很多。
结对项目总结
结对过程回顾和反思
→ 📖 Q4.1(P) 提供两人在讨论的结对图像资料。
→ 📖 Q4.2(P) 回顾结对的过程，反思有哪些可以提升和改进的地方。
-
最开始配环境浪费了一些时间，应该直接用 mac 系统
-
为了更快速的完成任务，我们的函数写得有些冗余，这给我们 debug 带来了一些麻烦
-
沟通与角色分工有待加强。每个阶段应明确双方任务，保证驾驶员和领航员的思路一致，有助于提升结对编程的效率与质量
→ 📖 Q4.3(I) 锐评一下你的搭档！并请至少列出三个优点和一个缺点。
-
优点
-
代码能力强，被 carry 了
-
行动力强，工作认真负责
-
资料查找能力强
-
-
缺点
- 能力非常强，导致我有点帮不上忙，(´ﾟдﾟ`)
对结对编程的理解
→ 📖 Q4.4(I) 说明结对编程的优缺点、你对结对编程的理解。
-
优点
-
搭档之间可以相互学习，分享各自的知识和经验。
-
两人同时审查代码，能及时发现并纠正错误，减少缺陷
-
在讨论过程中，对于代码的设计、架构等方面能进行更深入的思考，使代码更易读、可维护。
-
面对复杂问题时，两人的思维方式和解决问题的方法相互补充，能更快地找到解决方案，提高工作效率。
-
-
缺点
-
需要两人协调工作时间和节奏，可能会因为双方的工作习惯、时间安排不同而产生一些冲突，影响工作效率。
-
如果驾驶员过于强势，可能会主导整个编程过程，领航员则容易产生依赖心理，不利于双方的发展和发挥各自的优势。
-
-
我对结对编程的理解
结对编程不仅仅是简单地一个人写一个人审，它更强调的是一种合作和交流的过程。驾驶员关注代码细节，领航员把控整体架构，这有助于快速完成任务。
代码实现提交
→ 📖 Q4.5(P) 请提供你们完成代码实现的代码仓库链接。
https://github.com/JacckMa/BuaaSE-PairProgramming-SuperSnake
附录
附录A：基于 PSP 2.1 修改的 PSP 表格
td {white-space:nowrap;border:0.5pt solid #dee0e3;font-size:10pt;font-style:normal;font-weight:normal;vertical-align:middle;word-break:normal;word-wrap:normal;}| 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号