[P]结对项目：影蛇舞
结对项目：博客问题清单
| 项目 | 内容 |
|---|---|
| 这个作业属于哪个课程 | 2025年春季软件工程（罗杰、任健） |
| 这个作业的要求在哪里 | [P] 结对项目：影蛇舞 |
| 我在这个课程的目标是 | 掌握软件工程的基本概念和方法，提高团队合作能力，增强问题解决能力，熟悉现代软件开发工具和技术，提升编程技能。 |
| 这个作业在哪个具体方面帮助我实现目标 | 通过结对项目，实践团队合作，应用软件工程方法，解决实际问题，使用现代开发工具，提升编程技能。 |
请将本文件在代码仓库外复制一份，一边阅读和完成结对项目、一边填写入代码仓库外的版本，或采取简记、语音备忘等方式记载较复杂问题的要点之后再补充。请不要将本文档内的作答提交到代码仓库。
Chapter.0 Belua multorum es capitums.（你是多首的怪物。）
引入
→ 📖 Q0.1(P) 请记录下目前的时间。
3.24 9：43a.m.
调查
→ 📖 Q0.2(I) 作为本项目的调查：请如实标注在开始项目之前对 Wasm 的熟悉程度分级，可以的话请细化具体的情况。
I. 没有听说过；
II. 仅限于听说过相关名词；
III. 听说过，且有一定了解；
IV. 听说过，且使用 Wasm 实际进行过开发（即便是玩具项目的开发）。
I. 没有听说过
总结
→ 📖 Q0.3(P) 请记录下目前的时间。
3.24 10：00 a.m.
Chapter.1 不畏迷茫，只管前进。（迷子でもいい、前へ進め。）
结对过程
→ 📖 Q1.1(P) 请记录下目前的时间。
3.24 5：30p.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.我们采用了Assembly Script作为语言，由于不熟悉Assembly Script，我们先结合给的链接和gpt查阅并学习了Assembly Script的语法，随后我们列出了第一题的解题思路就是先贪心算法来算方向优先级，之后再用该方向是否会装上身体或者墙壁来判断是否选择该方向，由于不熟悉Assembly Script语言遇到了语法错误没通过的问题，通过copilot解决。
测试
→ 📖 Q1.3(P) 请说明针对该任务，你们设计和实现测试的方法及过程，包括但不限于：出于对需求的哪些考虑设计了哪些测试用例、如何评估所设计测试的有效性 等等。
思路：直接借用课程组提供的greedy_snake_fn_checker 函数，然后构造更多测试点进行测试。
具体而言，考虑了边界条件测试, 复杂路径测试, 角落测试, 中心测试, 环绕测试, 障碍物测试, 逆向测试
- 测试的有效性：
考虑了能想到的各种边缘情况
→ 📖 Q1.4(I) 请说明单元测试对软件开发的作用。
- 单元测试可以让我们确保代码可以按照预期工作，保障了代码的正确性
- 方便重构和优化，在重构和优化的时候我们不需要修改单元测试
- 可以集成到CI/CD中，提升软件质量
总结
→ 📖 Q1.5(P) 请记录下目前的时间，并根据实际情况填写 附录A：基于 PSP 2.1 修改的 PSP 表格 的“实际耗时”栏目。
3.24 8：05 p.m.
→ 📖 Q1.6(I) 请写下本部分的心得体会。
我们通过链接和gpt快速上手了一门语言，然后合作编完了一个小项目还是比较有成就感的
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) 请写下本部分的心得体会。
感觉灰常有趣
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) 锐评一下你的搭档！并请至少列出三个优点和一个缺点。
优点：
- coding的时候很专注
- 敏锐的找出bug
- 测试思路很全面
缺点： - 查找资料能力待提升
对结对编程的理解
→ 📖 Q4.4(I) 说明结对编程的优缺点、你对结对编程的理解。
- 结对编程优点在于能够更高质量和效率地完成编程任务，相比于一个人编程结对编程地成果bug会更少，缺点在于两个人的码风不同，很多编码习惯不同导致编码效率不高容易起争执。
- 我认为结对编程可以用于非常赶ddl的项目，但是对于个人编码能力的提升不大，在结对编程中很容易演变成为编码水平较高的人来主导编码而非平等的编码
代码实现提交
→ 📖 Q4.5(P) 请提供你们完成代码实现的代码仓库链接。
https://github.com/Happyaped/SE-PairProgramming
附录
附录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号