[P] 结对项目：影蛇舞
结对项目：影蛇舞
格式描述
| 项目 | 内容 |
|---|---|
| 这个作业属于哪个课程 | 软件工程 |
| 这个作业的要求在哪里 | 影蛇舞作业要求 |
| 我在这个课程的目标是 | 提升软件工程化能力，提升团队合作与交流沟通能力 |
| 这个作业在哪个具体方面帮助我实现目标 | 与同伴共同完成结对作业，体验结对编程流程 |
Chapter.0 Belua multorum es capitums.（你是多首的怪物。）
引入
→ 📖 Q0.1(P) 请记录下目前的时间。
2025/3/27 20:20
调查
→ 📖 Q0.2(I) 作为本项目的调查：请如实标注在开始项目之前对 Wasm 的熟悉程度分级，可以的话请细化具体的情况。
I. 没有听说过；
II. 仅限于听说过相关名词；
III. 听说过，且有一定了解；
IV. 听说过，且使用 Wasm 实际进行过开发（即便是玩具项目的开发）。
没有听说过；Wasm ，对概念完全不了解，看了项目书首次看到这个东西。
总结
→ 📖 Q0.3(P) 请记录下目前的时间。
2025.3.27 20：30
Chapter.1 不畏迷茫，只管前进。（迷子でもいい、前へ進め。）
结对过程
→ 📖 Q1.1(P) 请记录下目前的时间。
2025.3.27 20：30
→ 📖 Q1.2(P) 请在完成任务的同时记录，并在完成任务后整理完善：
- 浏览任务要求，参照 附录A：基于 PSP 2.1 修改的 PSP 表格，估计任务预计耗时；
- 完成编程任务期间，依次做了什么（比如查阅了什么资料，随后如何进行了开发，遇到了什么问题，又通过什么方式解决）；
-
见Chapter.1附录
-
首先我们查询了Wasm语言的相关概念，同时对几个课程组支持的语言类型进行调查，并进行选择。之后由我们一起讨论大致的实现思路与可能出现的问题。搞定初始思路后按照结对开发的流程进行开发。在开发过程中，对程序的运行出现一些疑问，之后在结合教程组教程指引与上网查询相关资料解决该问题。
测试
→ 📖 Q1.3(P) 请说明针对该任务，你们设计和实现测试的方法及过程，包括但不限于：出于对需求的哪些考虑设计了哪些测试用例、如何评估所设计测试的有效性 等等。
本次任务仅考虑单条贪吃蛇在单个果子情况下的运动问题，对贪吃蛇头部产生阻碍的要素仅有自身的蛇身与地图边缘，因此在理论上不存在不可达的情况，因此我们针对蛇头位置，与果子位置做了不同的假设以满足测试需求并输出每一步蛇身的移动方向，查看是否有冗余步骤，除此之外，我们还作了部分规格要求外的测试，通过扩张地图大小来进一步测试贪吃蛇路径规划的正确性。
→ 📖 Q1.4(I) 请说明单元测试对软件开发的作用。
1. 提高代码质量
- 早期发现错误：在开发过程中即可发现并修复代码中的逻辑错误、边界问题等，减少后续调试成本。
- 增强代码可读性：单元测试通常反映了代码的预期行为，有助于开发者理解代码的功能和使用方式。
- 促进良好设计：编写可测试代码往往促使开发者遵循单一职责原则（SRP）、低耦合高内聚等良好设计模式，从而提高代码的可维护性。
2. 提高开发效率
- 减少回归错误：通过持续运行单元测试，可以快速检测新代码是否破坏了已有功能，减少回归测试的工作量。
- 加快调试过程：测试失败时，可以快速定位问题，避免在整个系统中排查错误。
- 自动化测试支持：单元测试可集成到CI/CD（持续集成/持续部署）流程中，实现自动化测试，减少手动测试成本。
3. 提高代码的可维护性和可扩展性
- 确保重构安全：在重构代码或优化性能时，单元测试可以确保代码行为未被破坏，使开发者更加放心地修改代码。
- 支持敏捷开发：在敏捷开发和测试驱动开发（TDD）中，单元测试是保障代码质量的重要手段，使开发团队能更快地响应需求变化。
- 提升团队协作：单元测试提供了一种明确的契约，帮助团队成员理解代码行为，减少沟通成本。
总结
→ 📖 Q1.5(P) 请记录下目前的时间，并根据实际情况填写 附录A：基于 PSP 2.1 修改的 PSP 表格 的“实际耗时”栏目。
2025.3.27 22：00
见Chapter.1附录
→ 📖 Q1.6(I) 请写下本部分的心得体会。
在本节任务中我担任观察员的身份，负责审阅代码并提供建议，在环节中我学习到了另一名同学良好的代码习惯，并且学习了队友在使用的生产力插件，收获颇多。
Chapter.1附录
| Personal Software Process Stages | 个人软件开发流程 | 预估耗时（分钟） | 实际耗时（分钟） |
|---|---|---|---|
| PLANNING | 计划 | ||
| - Estimate | - 估计这个任务需要多少时间 | 5 | 5 |
| DEVELOPMENT | 开发 | ||
| - Analysis & Design Spec | - 需求分析 & 生成设计规格（确定要实现什么） | 10 | 10 |
| - Technical Background | - 了解技术背景（包括学习新技术） | 10 | 5 |
| - Coding Standard | - 代码规范 | 5 | 5 |
| - Design | - 具体设计（确定怎么实现） | 5 | 5 |
| - Coding | - 具体编码 | 20 | 10 |
| - Code Review | - 代码复审 | 5 | 5 |
| - Test Design | - 测试设计（确定怎么测，比如要测试哪些情景、设计哪些种类的测试用例） | 10 | 5 |
| - Test Implement | - 测试实现（设计/生成具体的测试用例、编码实现测试） | 5 | 5 |
| REPORTING | 报告 | ||
| - Quality Report | - 质量报告（评估设计、实现、测试的有效性） | 10 | 10 |
| - Size Measurement | - 计算工作量 | 5 | 5 |
| - Postmortem & Process Improvement Plan | - 事后总结和过程改进计划（总结过程中的问题和改进点） | 5 | 5 |
| TOTAL | 合计 | 95 | 75 |
Chapter.2 即使迷茫，也要前行。（迷子でもいい、迷子でも進め。）
结对过程
→ 📖 Q2.1(P) 请记录下目前的时间。
2025.3.27 22：15
→ 📖 Q2.2(P) 请在完成任务的同时记录，并在完成任务后整理完善：
- 浏览任务要求，参照 附录A：基于 PSP 2.1 修改的 PSP 表格，估计任务预计耗时；
- 完成编程任务期间，依次做了什么（比如查阅了什么资料，随后如何进行了开发，遇到了什么问题，又通过什么方式解决）；
-
见Chapter.2附录
-
首先，我们一起讨论了第二节作业的需求，确认增量化开发的可行性，之后一起讨论需要用到的解决算法，解决思路问题后按照结对开发的流程进行开发。但是在初版代码完成后经测试发现代码逻辑出现问题，经再次思考后发现初次思路出现问题，再次修改解决思路按照结对开发的流程进行二次开发，最终完成。
代码可复用性与需求变更
→ 📖 Q2.3(P) 请说明针对该任务，你们对 🧑💻 T1 中已实现的代码进行了哪些复用和修改。
T1中我们完成了贪吃蛇对自身蛇身与地图边界的避障，通过在避障的前提下向果子行进。在本节任务中，引入新的障碍物，我们在复用自身蛇身与地图边界的避障逻辑的前提下更新了贪吃蛇对果子的寻路逻辑，能够主动避开障碍物，沿着最短路径向果子行动。
→ 📖 Q2.4(I) 请说明在编码实现时，可以采取哪些设计思想、考虑哪些设计冗余，来提高既存代码适应需求变更的能力。
1. 设计思想
- 模块化设计：将系统拆分成多个独立的模块，每个模块只负责单一功能，以降低耦合度，提高可复用性和可替换性。
- 低耦合、高内聚：通过接口、抽象类等手段，使模块之间的依赖关系最小化，同时保证模块内部功能完整，方便独立修改和扩展。
- 面向接口编程：通过定义接口（Interface）而非具体实现，使得代码在更换实现时不需要大规模修改，提高灵活性。
- 依赖倒置原则（DIP）：依赖抽象而不是具体实现，使得底层实现变化时不会影响上层逻辑。
- 开闭原则（OCP）：对扩展开放，对修改封闭，使得在新增功能时尽量避免修改已有代码。
2. 设计冗余
- 预留扩展点：在系统设计时，预见可能的变化，并提供扩展点（如钩子函数、回调机制等）。
- 参数化设计：对于可能变化的逻辑，使用参数或策略模式，而不是硬编码，使得调整需求时无需修改代码。
- 日志和监控：在关键功能点添加日志记录和监控系统，以便在需求变更时快速诊断和调整代码。
头脑风暴环节
**→ 📖 Q2.5(P) **只吃一个食物可满足不了贪吃蛇的欲望，请一起思考并简述以下场景中贪吃蛇的策略：
在 🧑💻 T2 的基础上，场地里不再是只有 1 个果子，而是总共有 n 个果子 (1 < n < 10 )，果子随机分布在场地中且不会刷新，保证不与障碍物重叠，保证每个果子均可达，且至少存在一条成功吃掉所有果子的路线，其余条件保持不变，请你找出一条吃完所有果子的行动路径。
可以采用A*+TSP算法来解决，通过TSP方法先计算蛇头到所有果子的最短路径与所有果子之间的最短路径，从而可以用近似 TSP 算法找出最佳吃果子顺序。 之后通过A* 公式：
$$
f(n) = g(n) + h(n)
$$
- $g(n)$ = 从蛇头到当前点的实际代价（路径长度）。
- $h(n)$ = 采用曼哈顿距离估算到目标果子的代价。
之后动态更新地图，采用A*算法继续求解即可。
总结
→ 📖 Q2.6(P) 请记录下目前的时间，并根据实际情况填写 附录A：基于 PSP 2.1 修改的 PSP 表格 的“实际耗时”栏目。
2025.3.28 00：30
见Chapter.2附录
→ 📖 Q2.7(I) 请写下本部分的心得体会。
在本节任务中我担任驾驶员的身份，负责编写代码，在该环节中我与负责观察的同学交换了不同的思路，在广泛的可行性讨论后，由我着手完成代码编写，在该过程中由于不熟悉Vs下的断点调试，在debug时比较困难。
Chapter.2附录
| Personal Software Process Stages | 个人软件开发流程 | 预估耗时（分钟） | 实际耗时（分钟） |
|---|---|---|---|
| PLANNING | 计划 | ||
| - Estimate | - 估计这个任务需要多少时间 | 5 | 5 |
| DEVELOPMENT | 开发 | ||
| - Analysis & Design Spec | - 需求分析 & 生成设计规格（确定要实现什么） | 10 | 10 |
| - Technical Background | - 了解技术背景（包括学习新技术） | 10 | 5 |
| - Coding Standard | - 代码规范 | 5 | 5 |
| - Design | - 具体设计（确定怎么实现） | 20 | 20 |
| - Coding | - 具体编码 | 40 | 30 |
| - Code Review | - 代码复审 | 5 | 5 |
| - Test Design | - 测试设计（确定怎么测，比如要测试哪些情景、设计哪些种类的测试用例） | 10 | 10 |
| - Test Implement | - 测试实现（设计/生成具体的测试用例、编码实现测试） | 20 | 20 |
| REPORTING | 报告 | ||
| - Quality Report | - 质量报告（评估设计、实现、测试的有效性） | 10 | 10 |
| - Size Measurement | - 计算工作量 | 5 | 5 |
| - Postmortem & Process Improvement Plan | - 事后总结和过程改进计划（总结过程中的问题和改进点） | 5 | 5 |
| TOTAL | 合计 | 145 | 130 |
Chapter.3 这就是我的前进、到我出场了！！！！！（It's MyGO!!!!!）
结对过程
→ 📖 Q3.1(P) 请记录下目前的时间。
2025.3.28 00：30
→ 📖 Q3.2(P) 请在完成任务的同时记录，并在完成任务后整理完善：
- 浏览任务要求，参照 附录A：基于 PSP 2.1 修改的 PSP 表格，估计任务预计耗时；
- 完成编程任务期间，依次做了什么（比如查阅了什么资料，随后如何进行了开发，遇到了什么问题，又通过什么方式解决）；
-
见Chapter.3附录
-
首先阅读了有关assemblyScript的资料，然后结合第一问的代码先给出了一个简单的版本（直接选一个最近果子，只刨除禁止的方向）。但是逻辑上考虑到，在蛇数不同的情况下，竞争和生存的要求会发生变化，因此加入了动态判断的策略（两蛇竞争，多蛇生存）。最后经搭档指出，选单个最近果子的策略可能局限性比较大，因此综合所有最近果子的信息对方向进行考量。
需求建模和算法设计
→ 📖 Q3.3(P) 请说明你们如何建模这一需求。
任务给出了棋盘中自己蛇的位置，其他蛇的位置，以及果子的坐标等等数据，目的是尽可能吃到更多的果子，因为果子更新速度很快，即便是某一时刻给出一个静态的最短路径，也很快就不会再适用，因此选择最短视的贪心策略，直接去寻找最近的果子们。
在这一任务中，蛇判断方向的依据有以下几个。
- 该方向能不能尽可能快的吃到果子。
- 有没有其他蛇的蛇头或第1、2节（因为第四节所在的位置下轮如果没有别的蛇头补上，就一定会空出来，所以看作空气）。
- 是否躲避其他蛇可能撞击的蛇头。
- 墙壁，自身阻挡等因素。
- 为了最大化分数，多人场景下生存较为优先，双人场景下竞争为主要地位。
综合以上信息给出一个方向即可。
→ 📖 Q3.4(P) 请说明针对该任务，你们采取了哪些策略来优化决策。具体而言，怎么避免死亡？怎么吃到更多果子？如何编程实现。
首先需要计算离蛇头最近的果子，如果有多个，则全部记录下来。
创建一个数组记录四个方向的优越性，对于某一个最近的果子，如果其在蛇头的右上，则右和上各加一分。
对四个方向的分数排序，作为最初判断方向优越性的标准，这样的方法可以尽可能快的吃到一个最近的果子，相较于直接选定一个最近果子，这样的方式在有多个最近果子时，可以给出一个最快接近尽可能多最近果子的方法。并且设想如果有多个最近果子，直接选定一个最近果子的方式给出一个最优方向，但是该方向有第一节蛇身阻挡（或其他蛇）的情况，便会无法判断哪个方向更好，只能勉强从两个垂直方向随机选一个。但是像本算法这样综合其他最近果子的数据的方式，可以在这样的前提下给出一个除阻挡方向以外的较好的方向，使得选择不再那么单一。
然后将蛇头不可以前往的方向，比如第一节蛇身的方向，墙壁（如果靠墙）的方向，其他蛇的蛇头或前两节蛇身所在的位置的方向（如果紧贴蛇头）。
这些方向作为禁止方向，将其首先排除，如果排除后无结果，则说明必死无疑，因此随意选择一个方向结束。
之后对于非禁止的方向判断危险方向，危险方向即如果某个蛇头距离自己的蛇的蛇头只隔一个位置，那么这个蛇可能与蛇头相撞，具体来说如果在右上角有其他蛇的蛇头，则右和上作为危险方向。
如果不存在安全方向，则在危险方向里选择优越性最高的，否则选择安全方向之中优越性最高的。
对于多蛇场景，生存更重要，因为如果早早和别的蛇同归于尽只会双输，因此优先选择安全方向。
然而如果图中只剩一条其他的蛇，则预判规避对方的头往往会导致能吃到的果子更少，在竞争中处于劣势，因此如果只剩两条蛇则不会考虑危险方向，直接选择非禁止方向中的最优解。这样更可能压制对方的吃果子速度，如果同归于尽也没关系，因为分数往往可能占优。
软件度量
→ 📖 Q3.5(P) 请说明你们如何量度所实现的程序模块的有效性，例如：“如何说明我们的程序模块对弈能力很强？”尝试提出一些可能的定量分析方式。考虑到棋盘的随机性很大，少量对局的结果往往不能反映出竞争能力的强弱，因此所有的分析都建立在100局对局的基础上。
-
首先是判断吃果子的速度，不妨将两个分别以修改前的保守吃果策略和修改后的激进吃果策略的蛇放在一个棋盘之中，测量其胜出的对局，结果激进吃果以62：38胜出
-
然后判断综合考量最近果子信息是否有优势，将两个保守型且分别以单个贪心和综合贪心为吃果策略的蛇放在一个棋盘之中，综合贪心以55：45胜出。
-
最后将蛇与某自称小王老师的同学进行对战，两蛇局和四蛇局分别测试了30局，双蛇局大致打平，四蛇局碾压获胜（主要因为多蛇情况下优先生存）。
总结
→ 📖 Q3.6(P) 请记录下目前的时间，并根据实际情况填写 附录A：基于 PSP 2.1 修改的 PSP 表格 的“实际耗时”栏目。
2025.4.5 20：44
见Chapter.3附录
→ 📖 Q3.7(I) 请写下本部分的心得体会。
在本环节中，我们历经多次版本的修改，期间还和其他同学的贪吃蛇策略进行了测试比赛，在一步步修改中逐渐优化贪吃蛇的策略，在本环节与结对的同伴合作密切，真正体会到了结对的优势。
Chapter.3附录
| Personal Software Process Stages | 个人软件开发流程 | 预估耗时（分钟） | 实际耗时（分钟） |
|---|---|---|---|
| PLANNING | 计划 | ||
| - Estimate | - 估计这个任务需要多少时间 | 5 | 5 |
| DEVELOPMENT | 开发 | ||
| - Analysis & Design Spec | - 需求分析 & 生成设计规格（确定要实现什么） | 10 | 10 |
| - Technical Background | - 了解技术背景（包括学习新技术） | 10 | 5 |
| - Coding Standard | - 代码规范 | 5 | 5 |
| - Design | - 具体设计（确定怎么实现） | 40 | 120 |
| - Coding | - 具体编码 | 90 | 160 |
| - Code Review | - 代码复审 | 5 | 5 |
| - Test Design | - 测试设计（确定怎么测，比如要测试哪些情景、设计哪些种类的测试用例） | 10 | 10 |
| - Test Implement | - 测试实现（设计/生成具体的测试用例、编码实现测试） | 20 | 20 |
| REPORTING | 报告 | ||
| - Quality Report | - 质量报告（评估设计、实现、测试的有效性） | 10 | 10 |
| - Size Measurement | - 计算工作量 | 5 | 5 |
| - Postmortem & Process Improvement Plan | - 事后总结和过程改进计划（总结过程中的问题和改进点） | 5 | 5 |
| TOTAL | 合计 | 215 | 360 |
结对项目总结
结对过程回顾和反思
→ 📖 Q4.1(P) 提供两人在讨论的结对图像资料。
→ 📖 Q4.2(P) 回顾结对的过程，反思有哪些可以提升和改进的地方。
结对初期两人的合作并不熟练，略偏离结对的实践方向，而是两个人分别完成自己的任务，团队内交流较少，随着结对任务的进行与两人的逐步了解结对过程中的交流逐渐增多，流程逐渐规范。
→ 📖 Q4.3(I) 锐评一下你的搭档！并请至少列出三个优点和一个缺点。
优点：吃苦耐劳，任劳任怨，具有优秀的代码与算法设计水平，为人友善
缺点：时间安排比较紧，协调时间较为困难
对结对编程的理解
→ 📖 Q4.4(I) 说明结对编程的优缺点、你对结对编程的理解。
优点：结对编程能够最大程度上利用两个人的共同时间，高效的完成一项任务，同时由两人实时审查代码，可以及时发现并修复错误，减少 bug 的产生，结对过程中团队成员间互相学习，相互进步。
缺点：两个开发者同时投入同一任务，短期内可能不如分工协作高效。同时如果两人沟通不顺畅，可能会影响开发进度和情绪。两人的工作风格与技术能力也是需要逐渐磨合的，长时间的结对编程容易导致疲劳，影响持续工作能力。
就我个人而言，结对编程适用于任务较为紧急，同时由技术互补，了解较深的两位编程人员共同完成。
浙公网安备 33010602011771号