[P] 结对项目：影蛇舞
[P] 结对项目：影蛇舞
| 项目 | 内容 |
|---|---|
| 这个作业属于哪个课程 | 2025年春季软件工程（罗杰、任健） |
| 这个作业的要求在哪里 | [P] 结对项目：影蛇舞 |
| 我在这个课程的目标是 | 掌握软件工程的基本概念和方法，提高团队合作能力，增强问题解决能力，熟悉现代软件开发工具和技术，提升编程技能。 |
| 这个作业在哪个具体方面帮助我实现目标 | 通过结对项目，实践团队合作，应用软件工程方法，解决实际问题，使用现代开发工具，提升编程技能。 |
Chapter.0 Belua multorum es capitums.（你是多首的怪物。）
引入
→ 📖 Q0.1(P) 请记录下目前的时间。
3.24 9:
调查
→ 📖 Q0.2(I) 作为本项目的调查：请如实标注在开始项目之前对 Wasm 的熟悉程度分级，可以的话请细化具体的情况。
I. 没有听说过；
II. 仅限于听说过相关名词；
III. 听说过，且有一定了解；
IV. 听说过，且使用 Wasm 实际进行过开发（即便是玩具项目的开发）。
[!Answer]
II.
总结
→ 📖 Q0.3(P) 请记录下目前的时间。
3.24 10:00
Chapter.1 不畏迷茫，只管前进。（迷子でもいい、前へ進め。）
结对过程
→ 📖 Q1.1(P) 请记录下目前的时间。
3.24 5.30 p.m.
→ 📖 Q1.2(P) 请在完成任务的同时记录，并在完成任务后整理完善：
- 浏览任务要求，参照 附录A：基于 PSP 2.1 修改的 PSP 表格，估计任务预计耗时；
| Personal Software Process Stages | 个人软件开发流程 | 预估耗时（分钟） | 实际耗时（分钟） |
|---|---|---|---|
| PLANNING | 计划 | 10 | 10 |
| - Estimate | - 估计这个任务需要多少时间 | 10 | 10 |
| DEVELOPMENT | 开发 | 110 | 90 |
| - Analysis & Design Spec | - 需求分析 & 生成设计规格（确定要实现什么） | 5 | 5 |
| - Technical Background | - 了解技术背景（包括学习新技术） | 5 | 10 |
| - Coding Standard | - 代码规范 | 5 | 5 |
| - Design | - 具体设计（确定怎么实现） | 10 | 10 |
| - Coding | - 具体编码 | 35 | 30 |
| - Code Review | - 代码复审 | 20 | 10 |
| - Test Design | - 测试设计（确定怎么测，比如要测试哪些情景、设计哪些种类的测试用例） | 10 | 10 |
| - Test Implement | - 测试实现（设计/生成具体的测试用例、编码实现测试） | 20 | 10 |
| REPORTING | 报告 | 30 | 30 |
| - Quality Report | - 质量报告（评估设计、实现、测试的有效性） | 10 | 10 |
| - Size Measurement | - 计算工作量 | 10 | 5 |
| - Postmortem & Process Improvement Plan | - 事后总结和过程改进计划（总结过程中的问题和改进点） | 10 | 15 |
| TOTAL | 合计 | 150 | 130 |
- 完成编程任务期间，依次做了什么（比如查阅了什么资料，随后如何进行了开发，遇到了什么问题，又通过什么方式解决）；
2.我们采用了AssemblyScript作为语言，由于不熟悉AssemblyScript，我们先结合给的链接和gpt查阅并学习了AssemblyScript的语法，随后我们列出了第一题的解题思路就是先贪心算法来算方向优先级，之后再用该方向是否会装上身体或者墙壁来判断是否选择该方向，由于不熟悉AssemblyScript语言遇到了语法错误没通过的问题，通过copilot解决。
测试
→ 📖 Q1.3(P) 请说明针对该任务，你们设计和实现测试的方法及过程，包括但不限于：出于对需求的哪些考虑设计了哪些测试用例、如何评估所设计测试的有效性 等等。
思路：直接借用课程组提供的greedy_snake_fn_checker 函数，然后构造更多测试点进行测试。
具体而言，考虑了边界条件测试, 复杂路径测试, 角落测试, 中心测试, 环绕测试, 障碍物测试, 逆向测试
- 测试的有效性：
考虑了能想到的各种边缘情况
→ 📖 Q1.4(I) 请说明单元测试对软件开发的作用。
- 单元测试通过对代码的各个功能模块进行独立测试，确保每个模块按照预期工作。这有助于在开发早期发现并修复错误，提高代码质量
- 支持重构，降低调试成本，并促进良好的代码设计
总结
→ 📖 Q1.5(P) 请记录下目前的时间，并根据实际情况填写 附录A：基于 PSP 2.1 修改的 PSP 表格 的“实际耗时”栏目。
3.24 8:05 p.m.
→ 📖 Q1.6(I) 请写下本部分的心得体会。
TypeScript 的 lsp 不直接支持 AssemblyScript，报 warning 让我强迫症犯了，现在想来实在不应该。
尽管有点小挫折但是能这么快上手一门新（？）语言还是挺高兴的
Chapter.2 即使迷茫，也要前行。（迷子でもいい、迷子でも進め。）
结对过程
→ 📖 Q2.1(P) 请��录下目前的时间。
3.24 9:00 p.m.
→ 📖 Q2.2(P) 请在完成任务的同时记录，并在完成任务后整理完善：
- 浏览任务要求，参照 附录A：基于 PSP 2.1 修改的 PSP 表格，估计任务预计耗时；
| Personal Software Process Stages | 个人软件开发流程 | 预估耗时（分钟） | 实际耗时（分钟） |
|---|---|---|---|
| PLANNING | 计划 | 5 | 5 |
| - Estimate | - 估计这个任务需要多少时间 | 5 | 5 |
| DEVELOPMENT | 开发 | 140 | 150 |
| - Analysis & Design Spec | - 需求分析 & 生成设计规格（确定要实现什么） | 5 | 5 |
| - Technical Background | - 了解技术背景（包括学习新技术） | 0 | 0 |
| - Coding Standard | - 代码规范 | 0 | 0 |
| - Design | - 具体设计（确定怎么实现） | 20 | 25 |
| - Coding | - 具体编码 | 65 | 50 |
| - Code Review | - 代码复审 | 10 | 20 |
| - Test Design | - 测试设计（确定怎么测，比如要测试哪些情景、设计哪些种类的测试用例） | 10 | 10 |
| - Test Implement | - 测试实现（设计/生成具体的测试用例、编码实现测试） | 20 | 40 |
| REPORTING | 报告 | 35 | 30 |
| - Quality Report | - 质量报告（评估设计、实现、测试的有效性） | 10 | 10 |
| - Size Measurement | - 计算工作量 | 10 | 5 |
| - Postmortem & Process Improvement Plan | - 事后总结和过程改进计划（总结过程中的问题和改进点） | 15 | 15 |
| TOTAL | 合计 | 180 | 185 |
- 完成编程任务期间，依次做了什么（比如查阅了什么资料，随后如何进行了开发，遇到了什么问题，又通过什么方式解决）；
- 2.本次任务新加了障碍，并且由于不可达的情况我们需要直接输出-1，所以说我们联想到了DFS和BFS来解决这个问题，如果BFS可以在不通过障碍的情况下遍历到果子，那么即为可达的情况，否则不可达，在可达的情况下DFS的过程中用了一个Map来记录位置和方向的关系，然后记录到了一个全局数组中，之后每一次调用便依次返回这个数组中存储的方向。
代码可复用性与需求变更
→ 📖 Q2.3(P) 请说明针对该任务，你们对 🧑💻 T1 中已实现的代码进行了哪些复用和修改。
- 在通过传过来的参数来记录蛇的基础信息的时候的代码是复用的
- 修改了记录基础信息之后的代码，直接采用了DFS来判断是否可达并且在可达的情况下第一次调用DFS就记录了路径为全局数组在之后每一次调用中依次返回方向
→ 📖 Q2.4(I) 请说明在编码实现时，可以采取哪些设计思想、考虑哪些设计冗余，来提高既存代码适应需求变更的能力。
- 可以采用低耦合高内聚的设计思想和模块化的设计思想
- 可以通过参数化和配置化来提高冗余度来使得代码有更高的灵活性
头脑风暴环节
**→ 📖 Q2.5(P) **只吃一个食物可满足不了贪吃蛇的欲望，请一起思考并简述以下场景中贪吃蛇的策略：
在 🧑💻 T2 的基础上，场地里不再是只有 1 个果子，而是总共有 n 个果子 (1 < n < 10 )，果子随机分布在场地中且不会刷新，保证不与障碍物重叠，保证每个果子均可达，且至少存在一条成功吃掉所有果子的路线，其余条件保持不变，请你找出一条吃完所有果子的行动路径。
- 可以每次遍历蛇头和所有的果子来找到最小的曼哈顿距离，将该果子设为目标果子，然后DFS蛇头到该果子并记录路径，通过来路径吃掉这个果子，之后重复上述过程
总结
→ 📖 Q2.6(P) 请记录下目前的时间，并根据实际情况填写 附录A：基于 PSP 2.1 修改的 PSP 表格 的“实际耗时”栏目。
3.25 0:20 a.m.
→ 📖 Q2.7(I) 请写下本部分的心得体会。
在利用 greedy_snake_barrier_checker 测试的时候没仔细看测试函数的实现，还以为是实现有问题，思索良久。
要相信自己和队友
Chapter.3 这就是我的前进、到我出场了！！！！！（It's MyGO!!!!!）
结对过程
→ 📖 Q3.1(P) 请记录下目前的时间。
3.31 1.03 p.m.
→ 📖 Q3.2(P) 请在完成任务的同时记录，并在完成任务后整理完善：
- 浏览任务要求，参照 附录A：基于 PSP 2.1 修改的 PSP 表格，估计任务预计耗时；
| Personal Software Process Stages | 个人软件开发流程 | 预估耗时（分钟） | 实际耗时（分钟） |
|---|---|---|---|
| PLANNING | 计划 | 5 | 5 |
| - Estimate | - 估计这个任务需要多少时间 | 5 | 5 |
| DEVELOPMENT | 开发 | 300 | 150 |
| - Analysis & Design Spec | - 需求分析 & 生成设计规格（确定要实现什么） | 20 | 15 |
| - Technical Background | - 了解技术背景（包括学习新技术） | 20 | 15 |
| - Coding Standard | - 代码规范 | 0 | 0 |
| - Design | - 具体设计（确定怎么实现） | 100 | 120 |
| - Coding | - 具体编码 | 100 | 100 |
| - Code Review | - 代码复审 | 10 | 10 |
| - Test Design | - 测试设计（确定怎么测，比如要测试哪些情景、设计哪些种类的测试用例） | 30 | 20 |
| - Test Implement | - 测试实现（设计/生成具体的测试用例、编码实现测试） | 20 | 20 |
| REPORTING | 报告 | 35 | 30 |
| - Quality Report | - 质量报告（评估设计、实现、测试的有效性） | 10 | 10 |
| - Size Measurement | - 计算工作量 | 10 | 5 |
| - Postmortem & Process Improvement Plan | - 事后总结和过程改进计划（总结过程中的问题和改进点） | 15 | 15 |
| TOTAL | 合计 | 340 | 335 |
- 完成编程任务期间，依次做了什么（比如查阅了什么资料，随后如何进行了开发，遇到了什么问题，又通过什么方式解决）；
- 2.看到这个复杂的博弈问题，我们想到的策略是先看是否存在果子是我们的蛇到它的曼哈顿距离比其它蛇都短，如果存在，那么我们就找这几个目标果子中曼哈顿距离最短的一个作为目标，如果不存在那么就直接找所有果子中曼哈顿距离最短的果子为目标，安全性原则是不撞墙，不撞其它蛇的身体和自己的身体，同时会走其它蛇的蛇头可能走的格子(极限一换一)
需求建模和算法设计
→ 📖 Q3.3(P) 请说明你们如何建模这一需求。
- 避免死亡：一方面，将场上蛇身视为障碍物，避免直接撞上。另一方面，考虑其它蛇的下一步动向，在收益小于风险的情况下避免出现同归于尽的情况。
- 获得更多得分： 只考虑如何决策能最快吃到下一个果子
→ 📖 Q3.4(P) 请说明针对该任务，你们采取了哪些策略来优化决策。具体而言，怎么避免死亡？怎么吃到更多果子？如何编程实现。
- 我们采用了的优化策略有先看是否存在果子是我们的蛇到它的曼哈顿距离比其它蛇都短，如果存在，那么我们就找这几个目标果子中曼哈顿距离最短的一个作为目标，如果不存在那么就直接找所有果子中曼哈顿距离最短的果子为目标，这个是蛇吃到更多的果子的方式。
- 避免死亡的方式是不撞墙，不撞其它蛇的身体和自己的身体，同时会走其它蛇的蛇头可能走的格子(极限一换一)，同时也考虑了走边上被围死的可能性更大
- 按照上述吃更多果子策略得出的方向通过编码isOccupied函数来避免死亡
软件度量
→ 📖 Q3.5(P) 请说明你们如何量度所实现的程序模块的有效性，例如：“如何说明我们的程序模块对弈能力很强？”尝试提出一些可能的定量分析方式。
- 首先满足最基本的合理表现，比如说自我对弈的时候我们需要满足一个蛇死了之后另一条蛇是survive的，比如说四蛇大乱斗的时候至少有一条蛇是survive的
- 比如说1v1自我对弈的时候得分不少于15分
- 和其他小组的蛇对弈之后胜率不小于50%或者保证更高的存活率
总结
→ 📖 Q3.6(P) 请记录下目前的时间，并根据实际情况填写 附录A：基于 PSP 2.1 修改的 PSP 表格 的“实际耗时”栏目。
4.2 11:13 a.m.
→ 📖 Q3.7(I) 请写下本部分的心得体会。
一开始想的情况太多了，不太好实现，实际上简单的决策方法就已经很好地满足需求了。
结对项目总结
结对过程回顾和反思
→ 📖 Q4.1(P) 提供两人在讨论的结对图像资料。
→ 📖 Q4.2(P) 回顾结对的过程，反思有哪些可以提升和改进的地方。
- 我们结对的过程中T3的时间过于碎片化，我们可以选择更加整块的时间来完成结对编程
→ 📖 Q4.3(I) 锐评一下你的搭档！并请至少列出三个优点和一个缺点。
优点：
- 写代码很认真
- 会写注释
- 思考问题很理性
缺点：
- 变量命名风格有些奇怪，且不统一
对结对编程的理解
→ 📖 Q4.4(I) 说明结对编程的优缺点、你对结对编程的理解。
优点：有代码审查，有助于及时发现bug
缺点：审查耗时且效率并不高
对结对编程的理解：分为驾驶员和领航员，驾驶员负责编写代码，领航员负责审查代码和提供建议。两者需要密切合作，互相交流，以确保代码的质量和效率。
浙公网安备 33010602011771号