[P] 结对项目：花见小路
| 项目 | 内容 |
|---|---|
| 这个作业属于哪个课程 | https://edu.cnblogs.com/campus/buaa/BUAA_SE_2026_LR |
| 这个作业的要求在哪里 | https://edu.cnblogs.com/campus/buaa/BUAA_SE_2026_LR/homework/15648 |
| 我在这个课程的目标是 | 系统性的学习软件工程的知识，逐步成为一个成熟的软件开发者 |
| 这个作业在哪个具体方面帮助我实现目标 | 熟悉敏捷开发，结对编程的流程。熟悉 wasm 项目的开发 |
[P] 结对项目：花见小路
Chapter.0 wasm 从安装到入门
→ Q0.0(P) 如果你的代码仓库包含 AIGC 的部分，列举使用的工具、模型和使用范围。若未使用则填写：本组提交的全部代码不包含 AI 补全或生成的部分。
包含少量 AIGC 内容，使用 Gemini 网页版对话，让 LLM 整理资料、生成测试样例（但是测试代码人工编写）、实现示例代码，最终的代码均经过人工矫正和修改。
→ Q0.1(P) 记录目前的时间。
2026-04-07 19:04
→ Q0.2(I) 分别说明两人对 Wasm 的熟悉程度（IIV）和对桌游花见小路的熟悉程度（III）。
wasm:
cwz：III, 使用过 C 语言编写 WASM，并配置过相关工具链。
lyk: III, 尝试过将 WASM 反汇编至 C 语言。
花见小路
cwz：I
lyk：I
→ Q0.3(P) 记录目前的时间（完成 Guide 后）。
2026-04-07 19:17
Chapter.1 七色之缨
→ Q1.1(P) 记录当前时间。
2026-04-07 19:17
→ Q1.2(P) 填写 PSP 表格预估耗时，并记录开发过程（查阅资料、设计逻辑、测试等）。
| Personal Software Process Stages | 个人软件开发流程 | 预估耗时（分钟） | 实际耗时（分钟） |
|---|---|---|---|
| PLANNING | 计划 | ||
| - Estimate | - 估计这个任务需要多少时间 | 5 | 6 |
| DEVELOPMENT | 开发 | ||
| - Analysis & Design Spec | - 需求分析 & 生成设计规格（确定要实现什么） | 10 | 12 |
| - Technical Background | - 了解技术背景（包括学习新技术） | 5 | 4 |
| - Coding Standard | - 代码规范 | 5 | 3 |
| - Design | - 具体设计（确定怎么实现） | 5 | 5 |
| - Coding | - 具体编码 | 20 | 16 |
| - Code Review | - 代码复审 | 10 | 10 |
| - Test Design | - 测试设计（确定怎么测，比如要测试哪些情景、设计哪些种类的测试用例） | 5 | 4 |
| - Test Implement | - 测试实现（设计/生成具体的测试用例、编码实现测试） | 5 | 8 |
| REPORTING | 报告 | ||
| - Quality Report | - 质量报告（评估设计、实现、测试的有效性） | 5 | 2 |
| - Size Measurement | - 计算工作量 | 5 | 3 |
| - Postmortem & Process Improvement Plan | - 事后总结和过程改进计划（总结过程中的问题和改进点） | 5 | 3 |
| TOTAL | 合计 | 85 | 78 |
→ Q1.3(P) 说明设计了哪些中间量或辅助函数。
设计了 cnt1/cnt2（倾心标记数量）、score1/score2（总分）、mx1/mx2（最高分标记分值）作为中间量。
→ Q1.4(I) 说明如何避免漏判、错判或分支顺序错误。
严格按以下判定顺序编写 if-else 分支：
- 若一方总分 ≥11 → 该方获胜
- 否则若一方获得倾心标记数量 ≥4 且对方总分 <11 → 该方获胜
- 否则若
round < 3→ 返回 0 - 否则（
round == 3）：- 总分高者获胜
- 总分相同则比较最高分倾心标记（优先级 G > F > D/E > A/B/C）
- 若仍无法区分 → 平局（返回 2）
→ Q1.5(P) 说明设计了哪些测试用例，覆盖什么规则。
设计了 9 个测试用例，覆盖：总分≥11 获胜、标记数量≥4 获胜、前两轮返回 0、第三轮总分高低、总分相同最高档位（G/F 优先）、平局返回 2，以及全中立边界情况。
→ Q1.6(I) 说明对“先写测试”与“先实现”两种方式的理解。
先写测试可以首先思考到各类边界情况，在实现时可以规避分支漏判的情况。
先实现则效率更高，更快速的完成功能实现。
→ Q1.7(P) 记录当前时间，填写实际耗时。
2026-04-07 20:21
→ Q1.8(I) 写下心得体会。
第一部分的代码逻辑很简单，难度主要集中在 rust 语言特性上。这部分使得我加深了对于 rust 奇怪特性的理解。
Chapter.2 不祥之影
→ Q2.1(P) 记录当前时间。
2026-04-07 20:21
→ Q2.2(P) 填写 PSP 预估耗时，记录开发过程。
| Personal Software Process Stages | 个人软件开发流程 | 预估耗时（分钟） | 实际耗时（分钟） |
|---|---|---|---|
| PLANNING | 计划 | ||
| - Estimate | - 估计这个任务需要多少时间 | 5 | 3 |
| DEVELOPMENT | 开发 | ||
| - Analysis & Design Spec | - 需求分析 & 生成设计规格（确定要实现什么） | 10 | 12 |
| - Technical Background | - 了解技术背景（包括学习新技术） | 5 | 0 |
| - Coding Standard | - 代码规范 | 2 | 2 |
| - Design | - 具体设计（确定怎么实现） | 10 | 20 |
| - Coding | - 具体编码 | 30 | 35 |
| - Code Review | - 代码复审 | 10 | 8 |
| - Test Design | - 测试设计（确定怎么测，比如要测试哪些情景、设计哪些种类的测试用例） | 5 | 2 |
| - Test Implement | - 测试实现（设计/生成具体的测试用例、编码实现测试） | 5 | 2 |
| REPORTING | 报告 | ||
| - Quality Report | - 质量报告（评估设计、实现、测试的有效性） | 3 | 3 |
| - Size Measurement | - 计算工作量 | 3 | 2 |
| - Postmortem & Process Improvement Plan | - 事后总结和过程改进计划（总结过程中的问题和改进点） | 3 | 4 |
| TOTAL | 合计 | 91 | 93 |
→ Q2.3(P) 说明对 T1 代码的复用和修改。
复用了 T1 中的得分标记更新逻辑（比较双方各牌张数），修改点：将 T1 的固定分值表替换为按牌类型统计张数，并在结算时用张数比较结果更新 board。
→ Q2.4(I) 说明编码时采用了哪些设计思想或冗余来提高代码适应需求变更的能力。
采用函数拆分（secret_action/gift_action/compete_action）封装不同行动规则，用 my_turn 动态交换双方结果数组指针，避免重复代码；未硬编码牌张位置，便于扩展新行动类型。
→ Q2.5(P) 头脑风暴：T2 中不带 X 的操作记录比实际对局多了多少信息？如果加上 X（未知信息），如何处理对状态的估计？
多了完整公开的牌面信息（无未知），实际对局中对方选择可能未知。若加上 X，需要及时过滤未知信息，只将自己所能知道的信息存到数据结构中。
→ Q2.6(P) 记录当前时间，填写实际耗时。
2026-04-07 21:55
→ Q2.7(I) 写下心得体会。
这部分的代码逻辑也不难，但是提前封装函数有助于第三部分的开发。
Chapter.3 道途之荆
准备
→ 📖 Q3.1(P) 请记录下目前的时间。
2026-04-10 14:00
→ 📖 Q3.2(P) 请在完成任务的同时记录，并在完成任务后整理完善：
- 浏览任务要求，参照 附录A：基于 PSP 2.1 修改的 PSP 表格，估计任务预计耗时；
- 完成编程任务期间，依次做了什么（比如查阅了什么资料，随后如何进行了开发，遇到了什么问题，又通过什么方式解决）；
| Personal Software Process Stages | 个人软件开发流程 | 预估耗时（分钟） | 实际耗时（分钟） |
|---|---|---|---|
| PLANNING | 计划 | ||
| - Estimate | - 估计这个任务需要多少时间 | 5 | 5 |
| DEVELOPMENT | 开发 | ||
| - Analysis & Design Spec | - 需求分析 & 生成设计规格（确定要实现什么） | 20 | 25 |
| - Technical Background | - 了解技术背景（包括学习新技术） | 5 | 0 |
| - Coding Standard | - 代码规范 | 2 | 2 |
| - Design | - 具体设计（确定怎么实现） | 10 | 30 |
| - Coding | - 具体编码 | 180 | 240 |
| - Code Review | - 代码复审 | 30 | 20 |
| - Test Design | - 测试设计（确定怎么测，比如要测试哪些情景、设计哪些种类的测试用例） | 10 | 7 |
| - Test Implement | - 测试实现（设计/生成具体的测试用例、编码实现测试） | 30 | 25 |
| REPORTING | 报告 | ||
| - Quality Report | - 质量报告（评估设计、实现、测试的有效性） | 5 | 3 |
| - Size Measurement | - 计算工作量 | 3 | 2 |
| - Postmortem & Process Improvement Plan | - 事后总结和过程改进计划（总结过程中的问题和改进点） | 5 | 5 |
| TOTAL | 合计 | 305 | 364 |
头脑风暴环节
→ 📖 Q3.3(P) 头脑风暴环节：
假设提供更充裕的时间和资源，这个游戏中你能找到的最优策略有可能是什么形式的？进行调研并总结分析。你还可以在任务结束后试着实现（不计分）。
可能会是使用最大最小算法，并按照条件概率去预测对手的手牌从而构建完整决策树（目前我们的决策树只有一层）
需求建模和算法设计
→ 📖 Q3.4(P) 请说明针对该任务，你们采取了哪些策略来优化决策。具体而言，怎么选择行动类型？选牌如何更优？如何编程实现。
设计一个给局面评分的函数 rate，根据单次决策后 rate 的变化情况来决定选择哪种行动类型。具体而言，完全掌控的角色的分值越高，rate 越高；对于未完全掌控的角色，已放置的牌相比对手越多，rate 越高。
决定如何行动时，把所有可能的合法操作都列出来，分别计算它们的 rate，并根据行动类型进行一些修正（例如，我们发现将操作3与操作4的 rate 翻倍后，效果明显更优）最后选择 rate 最高的行动。
代码可复用性与需求变更
→ 📖 Q3.5(P) 请说明针对该任务，你们对 🧑💻 T2 中已实现的代码进行了哪些复用和修改。
T2 实现了根据历史行动来分析目前每个角色都被双方各放置了多少牌。这个功能可以复用，不过需要稍加修改：对于 1X 和 2XX 这种不可见操作，需要跳过。
→ 📖 Q3.6(I) 请说明在编码实现时，可以采取哪些设计思想、考虑哪些设计冗余，来提高既存代码适应需求变更的能力。
T3 会涉及到多种策略直接的互相比较，于是可以采取接口模式，为不同的选牌，行动策略提供一个统一的接口。这样可以实现对分析局势代码的共用，大幅减少代码量。同时方便写更多种类的行动策略。
软件度量
→ 📖 Q3.7(P) 请说明你们如何量度所实现的程序模块的有效性，例如：“如何说明我们的程序模块决策能力很强？”，尝试提出一些可能的定量分析方式或测试方式。
首先我们实现了一个纯随机的策略，它会在所有合法的操作中随机选择一个来行动。然后我们根据已有的代码（test.js, hanamikoji-engine.js）实现了测试代码。配置好所有想要测试的策略后，测试脚本可以自动让所有策略进行双循环比赛，每次比赛比 10000 局，最终输出对局结果。此后我们会将所有我们实现的优化策略都进行互相对弈，根据胜率的变化情况来决定此优化是否有效。
总结
→ 📖 Q3.8(P) 请记录下目前的时间，并根据实际情况填写 附录A：基于 PSP 2.1 修改的 PSP 表格 的“实际耗时”栏目。
2026-04-11 13:07
→ 📖 Q3.9(I) 请写下本部分的心得体会。
此部分实现一个最简单的纯随机策略还是很简单的，最耗时间的是各种调优。对于 rate 函数的调优可以十分显著的提升胜率。
结对项目总结
结对过程回顾和反思
→ 📖 Q4.1(P) 提供两人在讨论的结对图像资料。
→ 📖 Q4.2(P) 回顾结对的过程，反思有哪些可以提升和改进的地方。
此次结对作业开始的时间很晚，最后一周才开始，导致优化策略做的比较匆忙。此后可以尽早完成基础部分，给困难部分留足时间
→ 📖 Q4.3(I) 锐评一下你的搭档！并请至少列出三个优点和一个缺点。
优点：
- rust 语言了解很深，知道 trait 等高级特性，有助于设计模式的落实。
- AI 工具运用熟练，极大的提高了我们的最终策略的胜率。
- 人脉深，他的朋友提供了一个比随机策略强得多的基准策略，给我们的调优提供了很多思路。
缺点：
- 时间不是很富裕，可以安排在一起结对编程的时间很少。
对结对编程的理解
→ 📖 Q4.4(I) 说明结对编程的优缺点、你对结对编程的理解。
优点：
- 由于可以互相监督，不能摸鱼，可以很大提升编程的效率。
- 一边写代码一边审代码，可以避免很多低级错误。
缺点：
- 必须找两人的公共空余时间来编程，不是很灵活
- 相比于分工编程，结对编程不能两边一起开工，效率不一定能比分工高
代码实现提交
→ 📖 Q4.5(P) 请提供你们完成代码实现的代码仓库链接。
浙公网安备 33010602011771号