[P] 结对项目：花见小路

项目 内容
这个作业属于哪个课程 2026年春季软件工程 - 北京航空航天大学 - 班级博客
这个作业的要求在哪里 [P] 结对项目：花见小路 - 作业 - 2026年春季软件工程 - 班级博客 - 博客园
我在这个课程的目标是 学习软件工程相关知识
这个作业在哪个具体方面帮助我实现目标 体会结对编程，为团队项目铺垫

结对项目：博客问题清单

→ 📖 Q0.0(P) 【你可以在结对结束后补充】如果你的代码仓库包含 AIGC 的部分，列举使用的工具、模型和使用范围。若未使用则填写：本组提交的全部代码不包含AI补全或生成的部分。

本组提交代码包含 AI 辅助。使用工具为gimini-3，使用范围为代码审查和测试样例整理。关键规则理解、方案选择、和最终提交由两人共同确认。

Chapter.0 wasm从安装到入门

引入

→ 📖 Q0.1(P) 请记录下目前的时间。

开始时间：2026/3/28 14：50

调查

→ 📖 Q0.2(I) 【你可以在结对结束后另行补充。】作为本项目的调查：

请如实标注在开始项目之前对 Wasm 的熟悉程度分级，可以的话请细化具体的情况。（分别回答两人各自的情况）

I. 没有听说过；

II. 仅限于听说过相关名词；

III. 听说过，且有一定了解；

IV. 听说过，且使用 Wasm 实际进行过开发（即便是玩具项目的开发）。

请如实标注在开始项目之前对桌游花见小路的熟悉程度分级，可以的话请细化具体的情况。（分别回答两人各自的情况）

I. 不了解玩法和规则；

II. 听说过，且有一定了解；

  • Wasm 熟悉度：I. 没有听说过
  • 花见小路熟悉度：I. 不了解玩法和规则

总结

→ 📖 Q0.3(P) 请记录下目前的时间。

结束时间：2026/3/28 15：04

Chapter.1 七色之缨

结对过程

→ 📖 Q1.1(P) 请记录下目前的时间。

开始时间：2026/3/28 15：04

→ 📖 Q1.2(P) 请在完成任务的同时记录，并在完成任务后整理完善：

  1. 浏览任务要求，参照 附录A：基于 PSP 2.1 修改的 PSP 表格，估计任务预计耗时；
  2. 完成编程任务期间，依次做了什么（例如查阅了哪些资料、如何设计判定逻辑、如何设计测试样例、遇到了什么问题、如何解决）。
个人软件开发流程 Personal Software Process Stages 实际耗时（分钟） 预估耗时（分钟）
计划 PLANNING 4 5
- 估计这个任务需要多少时间 - Estimate 4 5
开发 DEVELOPMENT 47 50
- 需求分析 & 生成设计规格（确定要实现什么） - Analysis & Design Spec 5 5
- 了解技术背景（包括学习新技术） - Technical Background 4 5
- 代码规范 - Coding Standard 4 5
- 具体设计（确定怎么实现） - Design 5 5
- 具体编码 - Coding 10 10
- 代码复审 - Code Review 4 5
- 测试设计（确定怎么测，比如要测试哪些情景、设计哪些种类的测试用例） - Test Design 4 5
- 测试实现（设计/生成具体的测试用例、编码实现测试） - Test Implement 11 10
报告 REPORTING 15 15
- 质量报告（评估设计、实现、测试的有效性） - Quality Report 5 5
- 计算工作量 - Size Measurement 5 5
- 事后总结和过程改进计划（总结过程中的问题和改进点） - Postmortem & Process Improvement Plan 5 5
合计 TOTAL 66 70
  • 预估：70分钟
  • 过程记录：
    • 阅读 T1 判定规则，先整理优先级：11分 > 4标记 > 第三轮终局规则。
    • 确认函数签名为 hanamikoji_judge(board,round)，返回我方是否获胜的数字判断。
    • 设计合适的判断顺序，编写函数具体代码。
    • 按情况分类书写覆盖六类规则的测试点，以求覆盖所有可能的情况。

设计

→ 📖 Q1.3(P) 请说明你们为这个判定模块设计了哪些中间量或辅助函数；如果没有额外设计，也请说明为什么认为直接实现已经足够清晰。

  • 设计了中间量：
    • scores = [2,2,2,3,3,4,5]：按 A-G 档位定义分值映射。
    • score_my、score_opponent：双方当前倾心标记总分。
    • count_my、count_opponent：双方当前倾心标记数量。
    • score_win_my、score_win_opponent：是否达到 11 分的布尔判定。
    • count_win_my、count_win_opponent：是否达到 4 枚倾心标记的布尔判定。
    • max_my、max_opponent：第三轮总分相同时用于比较的“最高档位分值”。
  • 设计了辅助逻辑：
    • 第一层：单次遍历 board 同步累计双方分数和数量，避免重复遍历。
    • 第二层：按规则优先级顺序判定（11 分优先，其次 4 枚标记）。
    • 第三层：前两轮未触发胜利条件直接返回 0；第三轮进入终局比较。
    • 第四层：第三轮先比总分，再比最高档位，仍相同则返回平局 2。

→ 📖 Q1.4(I) 请说明在这样一个规则判定类模块中，如何避免“漏判”“错判”或分支顺序错误等问题。

  • 先“规则分层”再“代码落地”：把判定拆成早胜条件（11分/4标记）与第三轮终局条件（总分/最高档位/平局），每层只负责单一职责，减少漏判。
  • 固定并显式写出分支优先级：实现中严格按“11分 > 4标记 >（仅第三轮）总分 > 最高档位 > 平局”执行，避免后写的分支覆盖前置规则。
  • 使用对称测试：同一类规则同时写“我方胜/对手胜”两条用例，防止只验证单侧逻辑导致错判。
  • 使用边界样例测试：增加“前两轮无胜者返回0”“第三轮完全平局返回2”等边界样例，确保所有情况都被测试。

测试

→ 📖 Q1.5(P) 请说明你们设计了哪些测试用例，这些测试分别覆盖了哪一类规则或边界情况。

  • 分值胜利（2条）：
    • board = [0,0,0,1,1,0,1], round=1，我方总分 3+3+5=11，期望返回 1。
    • board = [0,0,0,-1,0,-1,-1], round=1，对手总分 3+4+5=12，期望返回 -1。
  • 数量胜利（2条）：
    • board = [1,1,1,1,0,0,0], round=2，我方 4 枚标记，期望返回 1。
    • board = [0,0,-1,-1,0,-1,-1], round=2，对手 4 枚标记，期望返回 -1。
  • 前两轮未决（2条）：
    • board = [1,-1,0,0,0,0,0], round=1，未达胜利条件，期望返回 0。
    • board = [1,1,-1,-1,0,0,0], round=2，未达胜利条件，期望返回 0。
  • 第三轮总分决胜（2条）：
    • board = [1,1,1,0,0,-1,0], round=3，我方总分高，期望返回 1。
    • board = [0,0,0,1,1,-1,-1], round=3，对手总分高，期望返回 -1。
  • 第三轮同分比最高档位（2条）：
    • board = [1,1,1,-1,-1,0,0], round=3，同分下对手最高档位更高，期望返回 -1。
    • board = [0,-1,0,0,-1,0,1], round=3，同分下我方最高档位更高，期望返回 1。
  • 第三轮平局（2条）：
    • board = [0,0,0,0,0,0,0], round=3，双方均无标记，期望返回 2。
    • board = [1,-1,0,-1,1,0,0], round=3，同分且最高档位相同，期望返回 2。

→ 📖 Q1.6(I) 请说明你对“先写测试再实现”与“先实现再补测试”两种方式的理解。

  • 先测后码更适合规则判定问题，能快速防止编写实现时漏判，但缺点是如果测试实现不全，在编写实现时如果完全依赖测试容易陷入盲目自信。
  • 先实现再补测在熟悉规则时更快，能快速写出实现。但风险是会测试可能遗漏边界，需再次重复思考规则逻辑以求完全覆盖。

总结

→ 📖 Q1.7(P) 请记录下目前的时间，并根据实际情况填写 附录A：基于 PSP 2.1 修改的 PSP 表格 的“实际耗时”栏目。

结束时间：2026/3/28 16：10（66分钟）

→ 📖 Q1.8(I) 请写下本部分的心得体会。

规则判定题看起来代码量不大，但真正的难点在于判断不同规则的优先级和边界情况的覆盖。一开始我以为把每条规则分别写出来就可以，后面才发现如果分支顺序不严谨，即使每条规则单看都对，组合起来也可能出现错判。因此在实现时我们先写出判定层次（11分、4标记、第三轮终局比较），再按层次落代码，明显减少了返工。

另外，测试对这种模块的价值非常直接。通过把场景拆成四种不同的大情况，我们能更快定位问题到底是规则理解错了，还是代码分支写偏了。结对互审时，我帮助搭档发现了一处测试样例错误的情况，这也让我意识到：规则题的正确性并不只靠实现本身，还依赖测试是否正确、是否覆盖完整。总体来说，这一部分让我建立了“先整理实现框架，再实现，再用结构化测试”的习惯。

Chapter.2 不祥之影

准备

→ 📖 Q2.1(P) 请记录下目前的时间。

开始时间：2026/3/28 16：15

→ 📖 Q2.2(P) 请在完成任务的同时记录，并在完成任务后整理完善：

  1. 浏览任务要求，参照 附录A：基于 PSP 2.1 修改的 PSP 表格，估计任务预计耗时；
  2. 完成编程任务期间，依次做了什么（比如查阅了什么资料，随后如何进行了开发，遇到了什么问题，又通过什么方式解决）；
个人软件开发流程 Personal Software Process Stages 实际耗时（分钟） 预估耗时（分钟）
计划 PLANNING 3 3
- 估计这个任务需要多少时间 - Estimate 3 3
开发 DEVELOPMENT 77 53
- 需求分析 & 生成设计规格（确定要实现什么） - Analysis & Design Spec 7 5
- 了解技术背景（包括学习新技术） - Technical Background 2 2
- 代码规范 - Coding Standard 2 2
- 具体设计（确定怎么实现） - Design 10 5
- 具体编码 - Coding 25 20
- 代码复审 - Code Review 6 4
- 测试设计（确定怎么测，比如要测试哪些情景、设计哪些种类的测试用例） - Test Design 10 5
- 测试实现（设计/生成具体的测试用例、编码实现测试） - Test Implement 15 10
报告 REPORTING 15 15
- 质量报告（评估设计、实现、测试的有效性） - Quality Report 5 5
- 计算工作量 - Size Measurement 5 5
- 事后总结和过程改进计划（总结过程中的问题和改进点） - Postmortem & Process Improvement Plan 5 5
合计 TOTAL 95 71

  • 预估：71分钟。

  • 过程记录：

    • 阅读 T2 输入输出约定，确认函数签名为 calc_current_state(history, board)，返回“我方计数、对手计数、结算后 board”。
    • 将实现拆成三层：dispatch_action 负责按行动类型划分；execute_action_1~4 负责更新计数；decide_board 负责轮末结算。
    • 按“我先手、双方轮流行动”遍历 history，用 is_my_turn 在每步交换视角，保证同一套行动函数可复用。
    • 对 3/4 行动先加入出示牌，再根据记录中的选择把对应牌从出示方转移到选择方，避免分支过多。
    • 设计并通过两类测试：基础流程重建测试、平票维持旧标记测试（验证平票时继承原 board[i]）。
    • 调试时检查字符串下标与字符转索引是否一致；检查不同行动是否成功区分并且跳转不同的函数；检查轮末结算是否正确判断

代码可复用性与需求变更

→ 📖 Q2.3(P) 请说明针对该任务，你们对 🧑‍💻 T1 中已实现的代码进行了哪些复用和修改。

  • 复用：本任务没有直接复用 T1 的函数或代码文件，T2 为独立实现。

→ 📖 Q2.4(I) 请说明在编码实现时，可以采取哪些设计思想、考虑哪些设计冗余，来提高既存代码适应需求变更的能力。

  • 采用“解析层-执行层-结算层”分层设计，具体规则改动时可局部替换单条规则，增加可扩展性和可复用性。
  • 通过统一分发器处理行动类型，新增行动或调整格式时只需增量修改对应分支。

头脑风暴环节

→ 📖 Q2.5(P) 头脑风暴环节：

我们终于快要开始让程序玩游戏了！请尝试分析：T2 中不带 X 的操作记录比起实际对局多出了多少信息？如果加上 X，也就是失去了这部分信息的话，如何处理对小轮结束后状态的估计？

  • 不带 X 的 T2 记录接近“完备信息日志”：每步具体牌面和选择结果都可见，基本可以唯一重建小轮结束时双方区域计数。
  • 一旦引入 X，缺失的是“具体牌身份”的信息，只保留行动结构与部分约束，此时结果不再是单一状态，而是一个可行状态集合。
  • 可行处理方式：
    • 约束过滤：利用总牌数、已公开牌、行动格式约束，不断剔除不可能状态。
    • 多状态并行结算：对每个可行状态计算轮末 board，再汇总得到每档位的胜负概率。
    • 决策输出：在信息不完全下，可采用假设对方始终采取最优策略。

总结

→ 📖 Q2.6(P) 请记录下目前的时间，并根据实际情况填写 附录 A：基于 PSP 2.1 修改的 PSP 表格 的“实际耗时”栏目。

结束时间：2026/3/28 17：50（95分钟）

→ 📖 Q2.7(I) 请写下本部分的心得体会。

T2 对我们来说最大的挑战是把“动作字符串”稳定地映射成“程序状态”。和 T1 相比，这一部分不只是条件判断，而是包含了解析、状态更新、轮次切换、轮末结算等多个环节，只要其中一个环节的实现有问题，最终结果就会整体错误。

这一部分也让我们更明确了分层设计的意义。把逻辑拆成分发、执行、结算三层后，我们在调试时可以快速缩小问题范围：先看是否正确分发到动作类型，再看执行是否正确更新计数，最后看结算是否按规则更新 board。这样的结构比把逻辑写在一个大函数里更容易验证和维护。整体上，T2 让我体会到：在规则复杂的任务中，清晰的数据结构和可验证的中间状态，比代码过度追求简洁更重要。

Chapter.3 道途之荆

准备

→ 📖 Q3.1(P) 请记录下目前的时间。

开始时间：2026/3/28 17：55
续做时间：2026/3/29 14：18

→ 📖 Q3.2(P) 请在完成任务的同时记录，并在完成任务后整理完善：

  1. 浏览任务要求，参照 附录A：基于 PSP 2.1 修改的 PSP 表格，估计任务预计耗时；
  2. 完成编程任务期间，依次做了什么（比如查阅了什么资料，随后如何进行了开发，遇到了什么问题，又通过什么方式解决）；
个人软件开发流程 Personal Software Process Stages 实际耗时（分钟） 预估耗时（分钟）
计划 PLANNING 8 5
- 估计这个任务需要多少时间 - Estimate 8 5
开发 DEVELOPMENT 390 340
- 需求分析 & 生成设计规格（确定要实现什么） - Analysis & Design Spec 28 20
- 了解技术背景（包括学习新技术） - Technical Background 18 15
- 代码规范 - Coding Standard 8 5
- 具体设计（确定怎么实现） - Design 52 30
- 具体编码 - Coding 180 180
- 代码复审 - Code Review 32 30
- 测试设计（确定怎么测，比如要测试哪些情景、设计哪些种类的测试用例） - Test Design 42 40
- 测试实现（设计/生成具体的测试用例、编码实现测试） - Test Implement 30 20
报告 REPORTING 19 15
- 质量报告（评估设计、实现、测试的有效性） - Quality Report 7 5
- 计算工作量 - Size Measurement 6 5
- 事后总结和过程改进计划（总结过程中的问题和改进点） - Postmortem & Process Improvement Plan 6 5
合计 TOTAL 417 360
  • 预估：360 分钟。
  • 过程记录：
  • 先通读 T3 接口与引擎约束，确认输入为 history + cards + board，输出必须是合法行动字符串，并且单次决策需控制在 2s 内。
  • 先搭建状态表示 WorldState，把已知信息（我方手牌、双方已用行动、场上明牌、对方暗置/弃置数量、剩余牌池）与待确定信息（对方手牌、未使用牌、摸牌顺序）拆开管理。
  • 复用 T2 的行动解析思路，分别实现“我方历史动作更新”和“对手历史动作更新”，把历史字符串逐步还原为当前局面。
  • 实现合法动作生成：当上一手是 3/4 且未响应时只生成 - 选择动作；其余情况根据剩余手牌和未用行动枚举 1/2/3/4 的所有合法组合。
  • 引入“确定化采样 + 蒙特卡洛树搜索”：每次搜索先对未知信息随机补全，再执行选择、扩展、随机模拟、反向传播。
  • 控制搜索预算：主循环以时间截止（约 1700ms）结束，预留引擎和序列化开销，避免触发 2000ms 超时。
  • 使用课程引擎做联调与回归，重点检查三类问题：非法动作、响应格式错误、时间超限；最终 npm run submit-test 通过。

头脑风暴环节

→ 📖 Q3.3(P) 头脑风暴环节：

假设提供更充裕的时间和资源，这个游戏中你能找到的最优策略有可能是什么形式的？进行调研并总结分析。你还可以在任务结束后试着实现（不计分）。

  • 从博弈建模上看，花见小路属于双人零和、含不完全信息与序贯决策的博弈，理论上的“最优策略”应接近信息集上的纳什均衡策略，而不是单局贪心最优。
  • 可行方向1：反事实后悔最小化、增强版反事实后悔最小化、蒙特卡洛反事实后悔最小化。优点是与信息集博弈天然匹配，缺点是状态空间较大、训练与收敛成本高。
  • 可行方向2：深度反事实后悔最小化、神经拟合自我博弈。用函数逼近替代表格策略，适合更复杂状态，但工程复杂度明显提升。
  • 可行方向3：信息集蒙特卡洛树搜索。工程实现相对直接，能在有限时间内给出可用策略；当前实现采用“确定化采样 + 蒙特卡洛树搜索”属于这一路线的简化版本。
  • 如果后续继续做优化，我们会优先走“规则先验 + 信息集蒙特卡洛树搜索”的混合方案：在动作生成与奖励中加入领域启发，再通过大量自对弈调参与评估。

需求建模和算法设计

→ 📖 Q3.4(P) 请说明针对该任务，你们采取了哪些策略来优化决策。具体而言，怎么选择行动类型？选牌如何更优？如何编程实现。

  • 行动类型选择：

  • 先做合法性优先：每轮 1/2/3/4 行动各用一次，先过滤已使用行动，再在剩余动作内搜索。

  • 在实现中不是手写固定优先级，而是由蒙特卡洛树搜索在当前局面下从合法动作集合中选择访问次数最高的动作。

  • 选牌策略：

    • 密约：倾向把高价值或对当前 board 影响大的牌放入可保留收益的动作中（由搜索在具体局面里决定具体牌）。

    • 取舍：更倾向丢弃在当前局势下边际收益较低、且不利于后续组合构造的牌，减少关键牌暴露风险。

    • 赠予：倾向构造“对手选哪张都不至于让我方亏太多”的三张组合，用搜索结果评估两种后继局面的期望收益。

    • 竞争：将四张牌按两组划分时，重点做“拆强组/平衡组”权衡，避免一边倒地把优势组直接送给对手。

  • 编程实现：

    • 状态建模：WorldState 统一管理局面，支持状态复制、确定化采样、摸牌、应用动作、合法性校验与合法动作枚举。
    • 搜索框架：搜索节点（MCTSNode）实现上置信界选子、扩展、回传；simulate 执行随机模拟生成奖励。
    • 未知信息处理：通过确定化采样随机补全对手手牌、暗置牌和未使用牌，把不完全信息转为可模拟状态。
    • 时限控制：hanamikoji_action 以时间预算循环搜索，返回访问次数最多子节点的动作。

代码可复用性与需求变更

→ 📖 Q3.5(P) 请说明针对该任务，你们对 🧑‍💻 T1和T2 中已实现的代码进行了哪些复用和修改。

  • 复用 T1：沿用了胜负判定逻辑（hanamikoji_judge 的同类实现），在模拟结束后用 board 结果计算回报。
  • 复用 T2：沿用了“解析行动字符串并更新双方区域牌计数、再按 A-G 比较更新 board”的结算思路。
  • 主要修改：T3 新增了不完全信息处理（未知牌确定化采样）、合法动作枚举、蒙特卡洛树搜索决策流程；不再是单次重建状态，而是“重建 + 预测 + 搜索”。

→ 📖 Q3.6(I) 请说明在编码实现时，可以采取哪些设计思想、考虑哪些设计冗余，来提高既存代码适应需求变更的能力。

  • 采用了“状态层 / 规则层 / 搜索层”分层：状态层只描述局面与转移，规则层只做合法性与结算，搜索层只负责决策，这样替换算法时不需要重写底层规则。
  • 对不完全信息场景，保留了确定化采样接口（determinize），后续可替换为更强的信息集采样方法，而不破坏动作与结算代码。
  • 动作生成和合法性检查独立实现（get_legal_actions + is_legal_action），既能防止非法输出，也便于后续加入启发式剪枝。
  • 通过时间预算而非固定迭代次数控制搜索，可在不同机器性能下更稳定地满足时限要求。

软件度量

→ 📖 Q3.7(P) 请说明你们如何量度所实现的程序模块的有效性，例如：“如何说明我们的程序模块决策能力很强？”，尝试提出一些可能的定量分析方式或测试方式。

  • 正确性指标：在课程引擎中能完整完成对局，非法动作率为 0，响应格式错误率为 0。
  • 时限指标：统计单局内每位玩家累计决策耗时与单次决策最大耗时，确保不触发 2s 超时。
  • 强度指标：固定随机种子下，与基线策略（随机/规则）进行多局对战，统计先手与后手分开的胜率。
  • 稳定性指标：在不同随机种子下重复对战，比较胜率方差与超时/异常比例。
  • 回归指标：每次改动后重跑 npm run submit-test 与自定义对战脚本，防止策略改动引入行为回退。

对战随机策略：

1

对战简单贪心：

2

总结

→ 📖 Q3.8(P) 请记录下目前的时间，并根据实际情况填写 附录A：基于 PSP 2.1 修改的 PSP 表格 的“实际耗时”栏目。

结束时间（第一天）：2026/3/28 20：30

结束时间（第二天）：2026/3/29 18：40（分段累计 417 分钟）

→ 📖 Q3.9(I) 请写下本部分的心得体会。

这部分让我最深的体会是：策略模块和规则模块的工作方式完全不同。规则模块主要追求“判定正确”，而策略模块必须在“正确、稳定、时限”三者之间取平衡。刚开始我更关注策略是否“聪明”，后来发现先保证动作合法、响应正确、不超时，才能考虑策略强度。

另外，不完全信息问题里“状态建模”比我预想更关键。只有先把已知与未知信息分清楚，搜索才有意义。通过这次实现，我对确定化、模拟和回传这类搜索流程有了更直观理解，也意识到后续若要继续提高胜率，需要在评估函数和信息集处理上投入更多工作，而不只是盲目加大搜索次数。

结对项目总结

结对过程回顾和反思

→ 📖 Q4.1(P) 提供两人在讨论的结对图像资料。

附上双人讨论照片：

3

→ 📖 Q4.2(P) 回顾结对的过程，反思有哪些可以提升和改进的地方。

  • 可改进点1：更严格执行“每30~45分钟小结一次”，并在每次小结后立即提交一次小粒度 commit。这样可以减少后期集中回忆和补文档的压力，也能在出现问题时更快定位到具体改动区间。
  • 可改进点2：在现有规则分类测试之外，补充小批量随机化测试与回归测试清单。具体做法是固定随机种子生成若干边界场景，并保留失败样例库，后续每次修改后自动重放，提升测试完备性和稳定性。
  • 可改进点3：将策略相关参数（如权重、优先级、阈值）配置化，并把测试样例情况区分进一步解耦。这样后续替换策略时只改配置或单模块，不影响主流程逻辑，维护成本更低。
  • 可改进点4：为 T3 增加系统化对战评测脚本（固定种子、先后手分开统计、对手池分层），并定期导出胜率、超时率和非法动作率。这样可以减少“凭体感调参”，让策略迭代有可量化依据，也更容易发现某些对局条件下的性能退化。

→ 📖 Q4.3(I) 锐评一下你的搭档！并请至少列出三个优点和一个缺点。

  • 优点：沟通清晰、执行快、测试意识强、代码编写能力强。
  • 缺点：大部分时间直接写代码，文档同步稍慢。

对结对编程的理解

→ 📖 Q4.4(I) 说明结对编程的优缺点、你对结对编程的理解。

  • 优点：代码能让队友实时评审，减少低级错误；规则理解有疑问两人可以相互讨论，减少理解错误；
  • 缺点：沟通成本更高、节奏不一致时效率受影响，如果想要提高效率需要两人长期磨合。
  • 理解：结对编程不是简单的两人分工，而是互相帮助、相互评审的过程，相较于传统单人编程，代码的正确性和他人可阅读性有所提升。结对编程更加适合小型项目的编写，对于小项目代码量适中的情况下灵活性较高的同时能保留一部分规范化，一定程度上能避免单人编写导致的不规范和小错误。

代码实现提交

→ 📖 Q4.5(P) 请提供你们完成代码实现的代码仓库链接。

仓库链接：wrongization/BUAASE2026-PairProgramming: 北航软工2026结对编程

posted @ 2026-04-09 23:40  wrongization  阅读(4)  评论(0)    收藏  举报