[P] 结对项目：影蛇舞
| 项目 | 内容 |
|---|---|
| 这个作业属于哪个课程 | 2025年春季软件工程（罗杰、任健） |
| 这个作业的要求在哪里 | [P] 结对项目：影蛇舞 |
| 我在这个课程的目标是 | 将软件工程理论与实践相结合、提升批判性思维和团队协作能力 |
| 这个作业在哪个具体方面帮助我实现目标 | 通过与他人合作开发，完成一个项目，培养问题建模与算法优化能力 |
结对项目：博客问题清单
请将本文件在代码仓库外复制一份，一边阅读和完成结对项目、一边填写入代码仓库外的版本，或采取简记、语音备忘等方式记载较复杂问题的要点之后再补充。请不要将本文档内的作答提交到代码仓库。
Chapter.0 Belua multorum es capitums.（你是多首的怪物。）
引入
→ 📖 Q0.1(P) 请记录下目前的时间。
2025.3.24 20:30
调查
→ 📖 Q0.2(I) 作为本项目的调查：请如实标注在开始项目之前对 Wasm 的熟悉程度分级，可以的话请细化具体的情况。
I. 没有听说过；
II. 仅限于听说过相关名词；
III. 听说过，且有一定了解；
IV. 听说过，且使用 Wasm 实际进行过开发（即便是玩具项目的开发）。
I. 没有听说过
总结
→ 📖 Q0.3(P) 请记录下目前的时间。
2025/3/24 21:35
Chapter.1 不畏迷茫，只管前进。（迷子でもいい、前へ進め。）
结对过程
→ 📖 Q1.1(P) 请记录下目前的时间。
2025/3/24 21:40
→ 📖 Q1.2(P) 请在完成任务的同时记录，并在完成任务后整理完善：
- 浏览任务要求，参照 附录A：基于 PSP 2.1 修改的 PSP 表格，估计任务预计耗时；
- 完成编程任务期间，依次做了什么（比如查阅了什么资料，随后如何进行了开发，遇到了什么问题，又通过什么方式解决）；
| Personal Software Process Stages | 个人软件开发流程 | 预估耗时（分钟） | 实际耗时（分钟） |
|---|---|---|---|
| PLANNING | 计划 | ||
| - Estimate | - 任务分解和总耗时估计 | 5 | 3 |
| DEVELOPMENT | 开发 | ||
| - Analysis & Design Spec | - 需求分析 & 设计规格（贪吃蛇规则解析） | 10 | 20 |
| - Technical Background | - WebAssembly 技术学习（工具链配置/ RUST 语法） | 25 | 20 |
| - Coding Standard | - 代码规范制定 | 5 | 4 |
| - Design | - 算法设计（路径搜索） | 20 | 9 |
| - Code Review | - 代码审查 | 15 | 10 |
| - Test Design | - 测试用例设计 | 10 | 4 |
| - Test Implement | - 单元测试/集成测试 | 15 | 4 |
| REPORTING | 报告 | ||
| - Quality Report | - 性能分析 | 5 | 2 |
| - Size Measurement | - 代码量统计 | 5 | 2 |
| - Postmortem & Process Improvement Plan | - 结对过程反思总结 | 5 | 2 |
| TOTAL | 合计 | 120 | 80 |
我们选取了 rust 作为编程语言。由于有 Chapter 0 部分的引入以及课程组提供的许多参考资料可供学习，整个开发过程推进的还是较为顺利。
我们的算法思路比较简单粗暴：由于题目涉及的情景比较简单（场地里仅存在长度固定为4的蛇和果子，没有其他干扰项），同时回合限制和时间限制都比较宽松（最多1000ms），我们直接采用暴力的BFS，找到吃到果子的最短路径。同时，在移动的过程中针对四个方向进行障碍物检测，避免死亡。
在实践中我们主要遇到了如下两个问题：
- 打包工具使用错误：最初我们错误地使用了 web 作为打包工具，而任务要求使用 nodejs。发现问题后，我们重新检查了任务文档，明确了正确的打包工具。
- 蛇移动时尾部移除情况未考虑：在测试过程中，我们发现课程组给的测试样例 3 中蛇出生在角落时会被自己卡住无法移动。经过仔细分析，我们意识到是没有考虑蛇移动时原先蛇尾所处格子也会变空的情况。于是，我们重新审视算法设计，改善了蛇移动的逻辑，经过测试，问题得到解决。
测试
→ 📖 Q1.3(P) 请说明针对该任务，你们设计和实现测试的方法及过程，包括但不限于：出于对需求的哪些考虑设计了哪些测试用例、如何评估所设计测试的有效性 等等。
考虑到题设场景相对简单，我们选择采用构造样例的方式来设计和实施测试。具体而言，我们在课程组提供的 greedy_snake_fn_checker 函数的基础上，考虑了以下几类条件的数据来设计测试用例：
- 基本方向移动 为了确保蛇在简单情况下能正确响应果子的位置，我们构造了果子在蛇头上下左右不同方向时的用例。
- 特殊位置情况
- 当蛇被自身身体紧密环绕、陷入 “自我包围” 的困境时，程序应引导其朝着尾部方向移动，从而成功摆脱包围。
- 边界条件需求 我们设计了蛇出生在边界以及果子放在边界的的测试用例来验证蛇头位于边界附近时程序的行为。
为了评估所设计测试的有效性，我们从以下两个维度展开考量：
- 测试用例的多样性：丰富多样的测试用例能够从多个不同视角对程序进行全方位检测，保证测试的全面性与完整性。
- 问题发现能力：程序出现错误时，若测试用例能够迅速反馈，助力我们精准定位问题根源并加以解决，那么该测试具备良好的问题发现能力。
基于上述评估角度来看，鉴于题设条件本身相对简单，我们所设计的测试用例做到了丰富且全面，充分覆盖了各类可能出现的情况；并且，测试用例切实发挥了重要作用，帮助我们敏锐地意识到在蛇移动时，其尾部所处格子会空出这一容易被忽视的情况，展现出了较强的问题发现能力 。
→ 📖 Q1.4(I) 请说明单元测试对软件开发的作用。
提升代码质量与减少修复成本 单元测试在开发早期对函数或模块进行独立验证，能够迅速发现诸如逻辑错误、边界处理失误等问题。这种“早发现、早解决”的机制，有效降低了后期调试和修复的成本，提升了整体软件质量。
增强软件的可靠性与稳定性 通过为每个功能点设计多样化的输入场景，并验证其输出是否符合预期，可以确保各个模块在各种条件下都能稳定运行。这不仅增强了软件的鲁棒性，也保证了其在实际运行中的一致性与可靠性。
促进代码的模块化与可维护性 为了便于测试，开发者会自觉将代码划分为结构清晰、职责明确的模块，这推动了代码结构的优化。单元测试还能在代码变更时提供即时反馈，帮助开发者判断是否引入了新的缺陷，从而保持代码的健康状态。
降低重构风险 在进行代码重构时，运行已有的单元测试可以确保重构没有破坏原有功能逻辑。测试的存在让开发者更有信心进行优化性修改，避免“改动即出错”的风险。
总结
→ 📖 Q1.5(P) 请记录下目前的时间，并根据实际情况填写 附录A：基于 PSP 2.1 修改的 PSP 表格 的“实际耗时”栏目。
2025/3/24 23:00
PSP表格见 Q1.2
→ 📖 Q1.6(I) 请写下本部分的心得体会。
在本次结对项目中，我深刻体会到了结对编程所带来的协作优势和思维碰撞。通过与队友的配合，我们能够更迅速地分工协作、相互查漏补缺，并在遇到问题时共同分析、快速定位，显著提升了开发效率。
我们选择使用 Rust 和 WebAssembly 来开发贪吃蛇的自动控制逻辑，虽然在一开始对 WebAssembly 技术了解几乎为零，但在学习资料和课程组参考文档的帮助下，我们很快上手并完成了基本的环境配置和项目搭建。这一过程也让我意识到，面对陌生技术时，主动查阅资料并动手实践，是最快的学习方式。
在开发过程中，我们初步采用了 BFS 搜索算法来寻找蛇吃果子的最短路径，并设计了障碍物检测以避免撞墙或撞到蛇身。虽然算法不算复杂，但实践中仍暴露出不少容易忽略的细节问题（比如蛇尾的处理）。所幸我们有完善的测试机制及时发现了这些 bug，也深刻感受到单元测试对开发的重要性。
此外，本次项目还让我体会到了“先设计、后编码”的重要性：我们在正式编码前花时间分析规则、设计算法和预估风险，使得实际编码过程更加有条不紊、问题处理更高效。
最后，通过撰写 PSP 表格，我们也更清晰地回顾了整个项目的时间投入与阶段安排，认识到规划与总结对于提升开发效率和质量具有积极意义。
Chapter.2 即使迷茫，也要前行。（迷子でもいい、迷子でも進め。）
结对过程
→ 📖 Q2.1(P) 请记录下目前的时间。
2025/3/25 20:00
→ 📖 Q2.2(P) 请在完成任务的同时记录，并在完成任务后整理完善：
- 浏览任务要求，参照 附录A：基于 PSP 2.1 修改的 PSP 表格，估计任务预计耗时；
- 完成编程任务期间，依次做了什么（比如查阅了什么资料，随后如何进行了开发，遇到了什么问题，又通过什么方式解决）；
| Personal Software Process Stages | 个人软件开发流程 | 预估耗时（分钟） | 实际耗时（分钟） |
|---|---|---|---|
| PLANNING | 计划 | ||
| - Estimate | - 任务分解和总耗时估计 | 5 | 2 |
| DEVELOPMENT | 开发 | ||
| - Analysis & Design Spec | - 需求分析 & 设计规格（贪吃蛇规则解析） | 15 | 10 |
| - Technical Background | - WebAssembly 技术学习（工具链配置/ RUST 语法） | 30 | 8 |
| - Coding Standard | - 代码规范制定 | 8 | 3 |
| - Design | - 算法设计（路径搜索） | 25 | 8 |
| - Code Review | - 代码审查 | 20 | 16 |
| - Test Design | - 测试用例设计 | 15 | 3 |
| - Test Implement | - 单元测试/集成测试 | 22 | 4 |
| REPORTING | 报告 | ||
| - Quality Report | - 性能分析 | 10 | 2 |
| - Size Measurement | - 代码量统计 | 5 | 2 |
| - Postmortem & Process Improvement Plan | - 结对过程反思总结 | 5 | 2 |
| TOTAL | 合计 | 160 | 60 |
T2 进行的非常顺利。这是因为题目相较于上一问仅增添了12个障碍物。由于我们在 T1 中采用 BFS 实现，在应对此次变化时，只需将新增的障碍物加入到原有的障碍物数组中，程序就能达到避障的效果。此外，当蛇吃不到果子时，通过 BFS 也可以直接判断出不可达。
值得一提的是，由于题目变得复杂，我们不再采用构造样例的测试方法，而是借助 AI 编写了一份随机生成障碍物的自动化脚本，进行了 1000 轮测试。在测试过程中，我们考量了果子可达与不可达的不同情况，提升了测试的全面性与可靠性 。
代码可复用性与需求变更
→ 📖 Q2.3(P) 请说明针对该任务，你们对 🧑💻 T2 中已实现的代码进行了哪些复用和修改。
T1 中的框架基本上得到了完整复用，包括其中的 BFS 算法、障碍物检测等部分。只是增加了障碍物数组的输入以及可达性的判断。
→ 📖 Q2.4(I) 请说明在编码实现时，可以采取哪些设计思想、考虑哪些设计冗余，来提高既存代码适应需求变更的能力。
模块化设计
- 将系统按照功能拆分为多个独立模块，每个模块只关注单一职责（SRP：Single Responsibility Principle）。
- 模块之间通过清晰、稳定的接口进行通信，减少耦合。
- 优点：当需求发生变化时，通常只需修改相关模块，无需全局调整，降低维护成本。
抽象化设计
- 将具体实现抽象为接口或基类，隐藏实现细节，强调行为契约。
- 例如，通过定义 trait（Rust）或 interface（Java/TS）来描述功能，具体实现可以灵活更换或扩展。
- 优点：增强系统的可扩展性与灵活性，为后续变更留有空间。
面向接口编程
- 在调用其他模块时依赖接口而非具体实现，这样可以更方便地替换或调整功能模块。
遵循 SOLID 原则（尤其是开放封闭原则 OCP）
- 软件实体应当对扩展开放，对修改封闭。即在不修改已有代码的前提下，通过扩展来实现新需求。
头脑风暴环节
→ 📖 Q2.5(P) 只吃一个食物可满足不了贪吃蛇的欲望，请一起思考并简述以下场景中贪吃蛇的策略：
在 🧑💻 T2 的基础上，场地里不再是只有 1 个果子，而是总共有 n 个果子 (1 < n < 10 )，果子随机分布在场地中且不会刷新，保证不与障碍物重叠，保证每个果子均可达，且至少存在一条成功吃掉所有果子的路线，其余条件保持不变，请你找出一条吃完所有果子的行动路径。
采用简单的贪心算法，从初始位置用 BFS 找到最近的果子去吃，吃到后，更新蛇的位置与场地状态，对剩余果子再用 BFS 找果子。不断重复此过程直至吃完所有果子，过程中进行适当的避障检测。由于可能存在某果子在 “死路”（因为必存在能全吃完的路线，这样的果子至多一个），BFS 时记录果子位置与路径信息，判断出该果子并排除这一选择即可。
总结
→ 📖 Q2.6(P) 请记录下目前的时间，并根据实际情况填写 附录A：基于 PSP 2.1 修改的 PSP 表格 的“实际耗时”栏目。
2025/3/25 21:00
PSP表格见 Q2.2
→ 📖 Q2.7(I) 请写下本部分的心得体会。
Q2 阶段的任务推进十分顺利，主要得益于我们在 Q1 中打下的良好基础。我们的代码在一开始就遵循了清晰的模块化结构和良好的抽象设计，使得此次新增障碍物的需求只需要在输入处理和数据结构层面做少量改动，主逻辑几乎无需调整，体现出了较高的可复用性和可扩展性。
本阶段我们最大的收获是体会到了良好设计对应对需求变更的巨大优势。在 Q1 中投入的精力不仅帮助我们构建了清晰的框架，也显著降低了 Q2 的开发成本。这种“前期多思考、后期省力气”的开发经验，让我们更加重视设计阶段的深度思考和代码结构的前瞻性布局。
此外，在测试方面我们也做出了优化：由于障碍物增多导致测试场景更复杂，我们引入了自动化脚本生成测试用例，相比 Q1 手动构造样例的方式大大提升了效率，也提高了测试的覆盖面和鲁棒性。这一做法让我们进一步认识到自动化测试工具的重要性，尤其是在面对复杂、多变场景时，能显著减轻开发者负担、提升信心。
最后，在思考如何吃掉多个果子的策略过程中，我们尝试将实际问题简化为多轮局部最优决策（贪心）的过程，并考虑了“死路”排除逻辑。虽然这不是最优解，但在保证可行性的前提下实现了合理的近似解，也让我们感受到算法设计中“实用优先”的重要性。
Chapter.3 这就是我的前进、到我出场了！！！！！（It's MyGO!!!!!）
结对过程
→ 📖 Q3.1(P) 请记录下目前的时间。
2025/4/1 19:00
→ 📖 Q3.2(P) 请在完成任务的同时记录，并在完成任务后整理完善：
- 浏览任务要求，参照 附录A：基于 PSP 2.1 修改的 PSP 表格，估计任务预计耗时；
- 完成编程任务期间，依次做了什么（比如查阅了什么资料，随后如何进行了开发，遇到了什么问题，又通过什么方式解决）；
| Personal Software Process Stages | 个人软件开发流程 | 预估耗时（分钟） | 实际耗时（分钟） |
|---|---|---|---|
| PLANNING | 计划 | ||
| - Estimate | - 任务分解和总耗时估计 | 5 | 5 |
| DEVELOPMENT | 开发 | ||
| - Analysis & Design Spec | - 需求分析 & 设计规格（贪吃蛇规则解析） | 25 | 45 |
| - Technical Background | - WebAssembly 技术学习（工具链配置/ RUST 语法） | 30 | 10 |
| - Coding Standard | - 代码规范制定 | 10 | 10 |
| - Design | - 算法设计（路径搜索） | 140 | 100 |
| - Code Review | - 代码审查 | 60 | 60 |
| - Test Design | - 测试用例设计 | 20 | 20 |
| - Test Implement | - 单元测试/集成测试 | 30 | 10 |
| REPORTING | 报告 | ||
| - Quality Report | - 性能分析 | 15 | 15 |
| - Size Measurement | - 代码量统计 | 10 | 10 |
| - Postmortem & Process Improvement Plan | - 结对过程反思总结 | 15 | 15 |
| TOTAL | 合计 | 360 | 300 |
需求建模和算法设计
→ 📖 Q3.3(P) 请说明你们如何建模这一需求。
不同于上述两问，Q3 引入了其他蛇的存在，需要我们将其视作一个动态移动的障碍物并进行相应的避障检测。
经过讨论，我们认为总共有三大需求需要权衡：
- 尽量吃到多的果子
- 尽量保证自己不被击杀，避免死亡
- 争取将敌人杀掉
→ 📖 Q3.4(P) 请说明针对该任务，你们采取了哪些策略来优化决策。具体而言，怎么避免死亡？怎么吃到更多果子？如何编程实现。
为了更有效地平衡 Q3.3 中所考量的三大需求，我们采用了 Q2.4 中提到的参数化设计理念。具体来说，针对蛇的行为表现，我们设定了生存得分、吃果子得分以及击杀得分，以此实现激进与保守策略之间的权衡（对应的应用场景有 1v1 模式中会激进些，大乱斗时则保守些）。当然，设定参数时我们也有设想借助深度学习进行参数调优，但由于前期代码编写已经快要超过课程组建议的 6 个小时，最终还是放弃了这一计划（我们也实在是写不动了/(ㄒoㄒ)/~~）
- 为了避免死亡我们考虑了：
- 不碰到边界和蛇身
- 尽可能预测其他蛇头的下一步行动轨迹。例如蛇大概率会朝着果子的方向移动。通过这样的预判，提前规避与其他蛇头发生正面碰撞的风险。
- 对于尽量吃到更多果子我们考虑了：
- 采用简单的贪心算法，找到和果子有着最近的曼哈顿距离的蛇头下一位置
- 争取杀人我们考虑了：
- 当走的下一步能够使得在下一回合中，对方蛇头很大概率无路可走时（如逼到角落时），考虑其击杀分
- 统计场上当前蛇的得分，当处在第一且有机会与第二同归于尽时，考虑其击杀分（尤其是在1v1模式中）
为了实现上述需求，我们建模了地图和其他蛇的身体，并通过其他蛇的移动轨迹判断其是否得分，以此来统计场上所有蛇的得分。然后我们通过简单的模拟，考虑我方蛇和敌方蛇的下一步，判断是否会碰触边界和是否有机会击杀敌蛇。
软件度量
→ 📖 Q3.5(P) 请说明你们如何量度所实现的程序模块的有效性，例如：“如何说明我们的程序模块对弈能力很强？”尝试提出一些可能的定量分析方式。
- 我们首先借助 GUI 界面，对程序模块在 1v1 对弈场景下的表现进行直观观测，以此初步判断特定功能是否成功实现。比如在考察攻击策略时，我们会看蛇在分数领先时会不会有尝试攻击敌蛇的倾向。由于我们采用参数化设计，为每个策略赋予了权重，在考察具体策略时我们会将其权重设置一个较大值
- 我们还将不同策略权重的蛇进行自我博弈，考量哪一策略更有利取得胜利。我们得出的结论是：1v1 模式时有必要激进一些，攻击的权重可以调大，大乱斗时则可以保守些
- 当然还有找了其他组的蛇进行“赛博斗蛐蛐”，并通过在不同模式下的胜率来评估（虽然感觉还是很看运气，大部分时候都是五五开）
总结
→ 📖 Q3.6(P) 请记录下目前的时间，并根据实际情况填写 附录A：基于 PSP 2.1 修改的 PSP 表格 的“实际耗时”栏目。
2025/4/1 24:00
PSP表格见 Q3.2
→ 📖 Q3.7(I) 请写下本部分的心得体会。
终于抵达终点，心情既轻松又满足。本次结对编程项目从一开始的单蛇觅食，到最后的多蛇博弈，可以说每一阶段都在逐步加深我们对问题建模、策略设计和程序架构的理解。
在 Q3 阶段，最显著的挑战就是如何在多个目标（生存、得分、击杀）之间进行平衡。我们从最初的“吃果子优先”，逐渐进化到引入参数化策略模型，根据不同场景（1v1、混战）调整策略权重，这种策略函数化的设计思路让我意识到，在不确定、多目标的博弈环境下，灵活性比算法复杂度本身更加重要。
同时，尽管我们的蛇看起来还有点“呆萌”，但我们确实用尽了能想到的方法，比如预测对手移动、主动防撞、甚至试图压迫对手移动空间等等，将有限的规则利用到了极致。虽然未能最终实现使用学习算法进行参数优化略感遗憾，但也意识到开发资源与时间成本同样需要权衡管理，这也是实际项目开发中必须面对的现实问题。
此外，通过持续构建测试、观察 GUI 行为表现、开展“自我博弈”与“互相斗蛐蛐”，我们第一次真正将“程序效果的度量”从主观变得稍微客观了一些。这种从定性到定量的思维转换，也是在其他课程中很难获得的宝贵体验。
更重要的是，这次项目让我第一次在实践中切实体会到了：
- 良好架构与复用性能如何节省未来开发成本；
- 策略建模与动态调整如何让程序具有博弈力；
- 团队协作与分工配合在高压下带来的高效与成就感。
虽然这个项目最后我们都快“写吐了”，但回头看，这的确是一次值得纪念的开发旅程——我们亲手打造了一个活着思考、会决策的“电子蛇”。
结对项目总结
结对过程回顾和反思
→ 📖 Q4.1(P) 提供两人在讨论的结对图像资料。
→ 📖 Q4.2(P) 回顾结对的过程，反思有哪些可以提升和改进的地方。
- 最开始配环境浪费了一些时间，应该直接用 mac 系统
- 为了更快速的完成任务，我们的函数写得有些冗余，这给我们 debug 带来了一些麻烦
- 沟通与角色分工有待加强。每个阶段应明确双方任务，保证驾驶员和领航员的思路一致，有助于提升结对编程的效率与质量
→ 📖 Q4.3(I) 锐评一下你的搭档！并请至少列出三个优点和一个缺点。
优点一：思路清晰，问题建模能力强
在面对复杂博弈逻辑时，搭档总能迅速理清问题本质，将抽象的需求转换为可实现的模型。不管是 T2 的果子可达性，还是 Q3 中多目标策略平衡，他总能提出既实际又高效的方案，带动我一起深入思考问题的底层结构。
✅ 优点二：动手能力强，代码质量高
搭档在 Rust 语言上的上手速度非常快，代码风格清晰统一，结构也非常合理，方便维护和扩展。很多关键函数和数据结构的封装都做得非常优雅，显著提高了整体项目的可复用性。
✅ 优点三：沟通顺畅，合作氛围好
无论是意见交流还是任务分工，搭档都非常尊重彼此的想法，沟通非常顺畅。在遇到分歧或问题卡壳时，我们总能冷静讨论，快速做出决策。这种平等、坦诚的合作氛围让我觉得非常安心且高效。
⚠️ 缺点：容易“上头”，时间控制略有问题
搭档有时候一旦沉浸在调试或优化某个细节上，就会“杀疯了”，忘记原定计划时间表（比如本来打算调试半小时，结果一调三个小时）。虽然这说明他非常投入和认真，但在时间紧张的开发周期里，稍微控制一下节奏可能会更好！
对结对编程的理解
→ 📖 Q4.4(I) 说明结对编程的优缺点、你对结对编程的理解。
- 优点
- 提升开发效率，降低错误率 在两人实时交流、互相审视代码的过程中，能够更快发现逻辑漏洞、边界条件遗漏等问题。许多原本可能花很长时间debug的错误，在搭档的提醒下往往几分钟就能解决。
- 思路碰撞，促进问题建模与优化 结对编程可以让两个人在设计阶段就展开讨论，不容易陷入单一视角。面对复杂需求时，能够一起头脑风暴、交叉验证思路，避免走不必要的弯路。
- 技能互补，互相学习 不同背景、擅长方向的搭档可以在协作过程中互相取长补短。例如一个人更熟悉语言特性，一个人逻辑建模更强，就能在开发中产生协同效应，彼此提升。
- 提升沟通与协作能力 结对开发要求高频沟通、明确分工，这有助于培养团队合作精神和工程思维，也更贴近现实工作场景。
- 缺点
- 效率受搭档匹配度影响较大 如果两人的节奏、风格、技术水平差异过大，可能会导致沟通成本增加，甚至出现“一人写、一人看”的非理想状态，影响效率。
- 需要更强的时间协同能力 结对开发对双方时间安排的一致性要求较高，尤其是当任务复杂、周期较长时，如何合理安排进度、留出同步时间是一项挑战。
- 容易过度依赖他人 若某一方技术明显更强，另一方可能在协作中过于依赖，而不是主动思考与参与，这样反而不利于个人成长。
- 我对结对编程的理解
结对编程不仅仅是简单地一个人写一个人审，它更强调的是一种合作和交流的过程。驾驶员关注代码细节，领航员把控整体架构，这有助于快速完成任务。
代码实现提交
→ 📖 Q4.5(P) 请提供你们完成代码实现的代码仓库链接。
https://github.com/JacckMa/BuaaSE-PairProgramming-SuperSnake
附录
附录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号