[I.3] 个人作业：结课总结

项目	内容
这个作业属于哪个课程	2025年春季软件工程
这个作业的要求在哪里	[I.3] 个人作业：结课总结
我在这个课程的目标是	学习现代软件构建的工程方法，锻炼团队协作能力。在团队的共同合作下产出符合流程的高质量软件。
这个作业在哪个具体方面帮助我实现目标	对一学期的课程进行全面的总结

曾经提问的解答

问题博客

https://www.cnblogs.com/Daytoy1014/p/18760181

问题再解答

一、回顾我曾提出的问题

在学期初的作业中，我提出了数个问题，在学期末，我都这些问题都有了新的理解。

问题1：结对编程是否只适用于技术水平相仿的成员？

在结对编程的项目任务 中，我和队友在能力上确实存在差异。实践中我发现，当水平较高的队员做领航员时，虽然会提升效率，但交流压力很大；当水平较低的队员做领航员时，容易陷入单方面输出。这与我原来的设想一致。

但令人惊喜的是，我们通过频繁角色互换和任务拆分，在交流中逐步缩小了技能差距。实践让我认识到：结对编程是否有效，取决于交流机制而非绝对水平差异。未来我更倾向于动态调整角色，强化同步机制。

问题2：规划产品就是找到用户痛点吗？

在 Alpha 阶段我们曾尝试“拍脑袋式”地设计功能模块——比如复杂的卡牌技能机制、沉重的叙事系统、冗长的对局流程。当时我们以为这些“酷炫特性”正是对用户痛点的响应，但测试后却发现玩家反而感到负担大、上手门槛高、游戏节奏拖沓，严重影响了体验。

Beta 阶段我们转向以“场景驱动”的方式重塑产品结构：设想典型用户在典型场景下的真实需求，重新定位玩法重心，如引入“乱斗狂欢”模式来满足轻量化社交对战需求，并大幅简化机制与操作门槛。

实证结论： 产品的核心是解决场景下的实际需求，而不是单纯用户痛点本身。展示产品价值需要有“多维评价+[场景与规划]”。

问题3：PM在小队伍中需要亲自上手编码吗？

PM能够在其他方面对整个团队产生深刻影响。但事实上如果不参与编码，自身能力在团队中难以得到有效提升。

问题4：新技术是否真能改善用户体验？

阅读《构建之法》时，我提出这一问题，是因为当时我思考到了技术创新与用户体验之间的张力：

• 新技术往往带来更高性能或更先进的能力；
• 但用户已经习惯了现有界面、交互和操作模式，一旦改变，可能会出现“不适应”、学习成本升高，甚至流失。

因此我疑惑：是否在项目中应该优先保守性设计，维持旧习惯？还是拥抱新技术，即使短期牺牲一些体验？

在《Battle of BUAA》的 Beta 阶段，我们进行了几项涉及“新体验”的尝试，正好验证了这个问题的现实意义：

加入乱斗狂欢模式

• 我们尝试引入玩家参战机制，让玩家在回合内亲自控制角色进行战斗。这种玩法与原有自走棋完全不同，需要用户临时学习操作和掌握新节奏。
• 反馈结果：我们通过引导页优化 + 玩法说明改善了体验，最终这一模式成为最受欢迎的新增玩法之一，解决了Alpha阶段玩家反馈的问题。

实证结论

技术演进应服务于体验，而不是让体验被技术裹挟。

新技术不是不能用，但必须：

• 明确价值：新技术/新机制要解决真实痛点，而不是“为了创新而创新”；
• 平滑过渡：通过引导、渐进式替换、保留旧入口等方式减少用户抵触；
• 尊重习惯：核心操作应保持一致性，否则会让用户陷入“认知重建”的痛苦。

换句话说：不是放弃新技术，而是要让技术“长成用户习惯能接受的样子”。

项目阶段收获

需求阶段 ——场景驱动的需求提取

有效的需求来源不仅仅是用户的“表层表达”，而是要通过典型场景、用户画像等方式挖掘“隐性需求”。

项目体会：

在Alpha阶段，我们主要靠头脑风暴式的“想当然”制定玩法，但实际测试发现，部分设计如“技能升级”与“特效卡槽”并未真正对用户有吸引力。

Beta阶段我们转向场景式需求提取——设计了更加具体的用户角色，并围绕这些场景设计玩法与系统。

这一转变让我们理解了“用户需要的未必是他们说出来的，而是他们在场景中真实渴望的”。

设计阶段 —— 模块解耦与职责分离

软件设计应强调低耦合高内聚，让每个模块有清晰边界与职责划分，提升可扩展性与维护性。

项目体会：

我们在设计过程就注重软件设计，在后续添加卡牌以及转换模式的过程有了极大的便利

这个过程让我们深刻认识到：良好的架构不是“能跑起来”，而是“能跑很久”。

实现阶段 ——版本控制与协作流程规范

在多人协作开发中，Git版本管理+任务分支机制是保证效率与质量的基础设施。

项目体会：

我们采用了规范的流程：每个功能点创建对应分支（如feature/ui-redesign）、Pull Request 审查合并、issue联动开发任务。这一实践不仅让协作更清晰，也让调试和历史回溯更高效。

我们意识到：写代码不是一个人的事，而是要让团队“看得懂、接得住”。

测试阶段 ——黑盒测试与场景测试结合

测试不仅是代码无错，更是“功能在特定使用情境下符合预期”。

项目体会：

我们构造了多个典型场景：如“2人快节奏对局”、“非战斗阶段卡牌拖拽”等，测试其完整流程是否符合预期、是否存在UI卡顿或数据不同步。

这让我们体会到：测试不仅是发现错误，更是验证价值。

发布阶段 ——出口条件与用户引导机制

发布不仅是“版本上线”，还要符合明确的出口条件(Exit Criteria)，并配套好用户教育机制。

项目体会：

我们为发布设定了清晰的出口条件，如“无致命Bug”、“核心机制完整运行”、“新增机制引导完整”，并准备了引导页和快捷反馈通道，确保用户不会在初次上手时迷路。

这帮助我们意识到，发布是一次产品价值的交付仪式，不是“上传按钮点一下那么简单”。

维护阶段 ——日志与数据驱动的回溯优化

软件上线后的维护必须建立在数据与反馈机制基础上，包括日志记录、用户数据分析、快速修复闭环。

项目体会：

在公测过程中，建立了反馈群，第一时间收集用户意见并修复问题。

维护不再是“被动修Bug”，而是“主动调优体验”。

个人心得

结对编程

合作编码的真实挑战与益处

在结对编程中，我深刻体会到“两人一键盘”的效率与挑战并存。尽管会因为编码习惯不同或思路冲突而陷入讨论甚至争执，但这些摩擦反而帮助我们更全面地思考问题、权衡不同方案。

例如，在我们实现贪吃蛇 AI 的过程中，我作为“驾驶员”负责编写核心逻辑，而搭档则担任“领航员”，不断审视设计细节、提出优化建议。我们尝试了 A* 搜索和启发式路径规划，不断迭代策略。在这过程中，我学习到了很多原本自己不会去触碰的算法技巧，也更理解了“看代码”与“写代码”本质上的不同。

实时沟通显著降低 Bug 密度

相比独立开发，结对编程中我们每一步都在即时讨论与复查，这种高频的同步沟通让许多潜在问题在“刚冒头”时就被发现并解决，显著提高了代码质量。结对不仅仅是效率问题，更是代码健壮性与思维盲区的双重保障。

对软件工程流程的真实体验

通过结对，我第一次完整体验了“从需求分析到代码落地”的完整微型开发闭环，尤其是小而精的模块开发场景下，如何快速迭代、如何把控代码质量、如何进行最小可行版本（MVP）实现等，成为了我后续团队合作的重要参考。

团队项目

真实大型项目协作的深度参与

相比结对编程，团队项目的复杂度呈现指数级上升。成员数量的增加意味着职责划分、接口协调、需求对齐都必须有“制度化”的工程规范。这让我深刻意识到文档、项目管理工具（如飞书甘特图、Issue 分配）在中大型开发中的不可或缺性。

项目管理意识的建立

作为团队的 PM，我参与了从需求排布到任务分发的全过程。在不断地迭代与复盘中，我学会了：

• 如何对不同性格、技术栈、任务节奏的成员做出差异化安排；
• 如何在进度落后时有效调整资源，设定优先级，避免“火烧眉毛”；
• 如何通过集中开发日缓解团队效率瓶颈，平衡技术债与交付目标。

用户导向的敏捷迭代观

Alpha 阶段我们过于自嗨，功能杂、上手难、交互差。而 Beta 阶段，我们从用户角度出发，围绕“轻策略+社交”核心重新设计产品形态，包括：

• 引导性更强的新手教程；
• 模式入口更聚焦的 UI 设计；
• 提高代入感的“玩家加入战斗”机制。

通过内测与公测，我们收集用户反馈，驱动每一轮版本迭代。这让我理解到，“敏捷开发”不是口号，而是“用用户反馈倒逼产品改进”的真实流程。