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

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

这个作业属于哪个课程	北航2026年春季软件工程
这个作业的要求在哪里	[I.3] 个人作业：结课总结
我在这门课程的目标是	接触理解应用现代软件工程常用的开发方式，锻炼自己编写代码以及团队协作的能力
团队项目仓库链接	HexaVigil - GitHub
曾经提问题的博客地址	【I.1】阅读与提问

---

第一部分：提问回顾与解答

在课程开始时，我曾结合教材内容提出了五个关于软件工程方法、团队组织和技术趋势的问题（详见我之前的博客）。经历了一个学期的个人项目、结对编程以及团队项目后，我对这些问题有了更务实、也更贴近工业界真实生态的理解。

问题一：大模型时代下，传统手写底层代码的“肌肉记忆”是否反而会限制向架构师与AI协同者转型？

• 实践中的新理解：
  在开发个人项目和 HexaVigil 的核心状态机时，我深度使用了 AI 辅助工具。最初我以为写代码的“肌肉记忆”不再重要。然而在实际排查一个关于“六天防御循环”状态跳转异常的 Bug 时，我发现 AI 给出的修复代码经常引入更隐蔽的逻辑漏洞。
  我意识到，传统的“肌肉记忆”不应被窄化为“盲打代码的速度”，而是一种对程序运行状态、边界条件和内存模型的直觉。正是因为在个人和结对项目中手动编写过大量的调试代码，我才能在 AI 给出似是而非的代码时，敏锐地察觉到其逻辑漏洞并予以纠正。
  因此，底层练习不会限制向架构师的转型，相反，它是你作为“AI协同者”时进行代码审查和质量把关的底气。没有底层肌肉记忆的协同者，往往会被 AI 的幻觉引入歧途。

问题二：在云计算和持续集成普及的背景下，开发是否正走向“无明显阶段边界的模型”？

• 实践中的新理解：
  在 HexaVigil 的开发中，我们尝试引入了自动化的 CI/CD 流程。代码一旦提交就会自动测试和打包，这让开发和发布看起来确实没有了物理上的时间边界。
  但从管理和认知角度来看，阶段边界非但没有消失，反而变得更加重要了。在项目中期，我们曾因为没有严格划分核心规则设计阶段与功能开发阶段，导致不同队员在编写防御塔和怪物属性时，对六天防御循环结算公式的理解产生了偏差，造成了严重的合并冲突。
  这让我明白，DevOps 和 CI/CD 模糊的是工具链和交付流程的物理边界，但为了降低团队的认知过载，逻辑上的里程碑依然是不可或缺的防线。

问题三：如何建立机制区分高价值核心诉求与低价值情绪发泄？当用户诉求与商业/核心设计冲突时如何权衡？

• 实践中的新理解：
  在我们将 HexaVigil 部署并邀请同学们进行试玩时，收到了很多直接反馈。例如有玩家抱怨：“第三天太难了，怪物伤害太高，根本守不住，建议直接削弱怪物伤害。”
  起初，我们简单地调低了怪物数值，却发现游戏失去了策略塔防本该有的紧张感。后来通过仔细观察玩家的操作录像，我们发现真正的痛点并不是数值不合理，而是因为缺乏直观的 UI 引导，玩家没有理解“六天防御循环”中资源转换的机制。
  这解答了我的困惑：用户反馈往往是直觉的情绪呈现，而工程师的任务是透过现象看本质。我们最终没有削弱怪物，而是增加了一个简易的局内机制指引。对于冲突，我们建立的决策模型是：不盲从用户给出的解决方案，而是去诊断他们遇到的实际阻碍，并用符合游戏核心设计的手段去解决。

问题四：未来的软件团队是否会变成单纯的 "Vibe Coding"？

• 实践中的新理解：
  在本次团队项目中，我们确实感受到了 AI 工具对单兵作战能力的巨大提升，甚至一个人就能在一下午用 AI 生成数个功能模块。但一旦把这些模块放进多人协作的仓库中，问题就接踵而至。
  每个人使用的 AI 助手编写的代码风格不同，数据接口命名不统一，模块之间的耦合度过高。这让我们意识到，人与人之间的协作成本，并没有随着 AI 的出现而归零。相反，如何定义清晰的接口规范、如何设计合理的 Git 分支管理策略、如何在团队内达成架构共识，成为了项目能否按时交付的关键。
  "Vibe Coding" 在个人玩具项目中或许可行，但在多人协作的软件工程中，传统的团队模式、规范的文档与定期的技术同步依然是维系项目生命线的基石。

问题五：如何从制度和工程文化上防止“鹦鹉”获得决策权？个人如何进行角色切换？

• 实践中的新理解：
  在我们的项目团队中，我们通过 GitHub PR Review 机制和看板分工来实践 RASCI 模型。我们规定，负责某个核心功能的队员是该模块的“猪”。其他队员可以提出修改建议，但如果没有通过负责人的 Review，任何代码都不能并入主分支。
  这种工程机制在一定程度上防止了“外行指导内行”的现象。
  在个人精力的平衡上，我也学到了角色切换的艺术。在核心关卡逻辑开发中，我作为“猪”全情投入，承担高风险；在界面美术素材的整理和导入等边缘工作中，我主动退一步充当“鸡”，按时交付并配合核心开发；而在结课展示和文档撰写时，我则努力做一只合格的“鹦鹉”，将团队的技术成果清晰地表达出来。

---

仍然保留的疑问与思考

在 Q5 中，我们在相对单纯、扁平的学校团队里通过 GitHub 权限和 PR Review 较好地限制了“非利益相关者的过度干预”。然而，在真实的工业界中，层级复杂的组织架构往往会产生大量的多头管理与非技术干扰。在利益冲突更复杂的商业环境中，如何建立一种既能保护一线开发者的决策权，又能兼顾管理层商业愿景的容错机制？这可能不仅仅是一个软件工程问题，更是一个组织行为学与社会学的挑战。

新产生的问题

• 新问题：随着大模型对整套代码重构和迁移能力的飞速提升，传统的为了未来扩展而进行的高度解耦与冗余设计，是否正在失去性价比？在 AI 时代，我们是否应该转向一种易于废弃和重写而非易于扩展的“一次性极简架构”设计思路？

---

第二部分：软件工程各阶段的知识点总结

在 HexaVigil 游戏的生命周期中，我们通过“做中学”在六个阶段中各收获了一个关键的软件工程知识点：

+---------------------------------------------------------------------------------+
|                                 HexaVigil 软件生命周期                           |
+---------------------------------------------------------------------------------+
|  [需求] -> 用户故事                                               |
|  [设计] -> 模块化设计与低耦合                                       |
|  [实现] -> 基于 PR 与代码审查的 Git Flow 策略                       |
|  [测试] -> 矩阵式玩家试玩测试与冒烟测试                               |
|  [发布] -> 基于 GitHub Actions 的自动化 CI/CD 打包                  |
|  [维护] -> 缺陷追踪与热修复机制                                      |
+---------------------------------------------------------------------------------+

1. 需求阶段

• 知识点：用户故事与用例映射
• 实践收获：在设计“六天防御循环”时，我们不再使用空洞的文字描述，而是将其拆解为具体的用户故事：“作为一名防守玩家，我希望在第六天夜晚结束时看到详尽的资源结算清单，以便评估本轮循环的防御效率。”这帮助我们在动笔写代码前，明确了关卡状态机和结算UI所需要暴露的具体数据接口。

2. 设计阶段

• 知识点：高内聚低耦合与模块化设计
• 实践收获：游戏开发极易导致代码高度耦合。我们在设计初期引入了简单的 MVC 架构思想，将底层格子的坐标计算、敌人的属性状态与上层的渲染表现完全分离。这确保了后续我们在重构防御塔的攻击动画和粒子特效时，底层的数值判定和寻路算法不需要做任何修改。

3. 实现阶段

• 知识点：基于 PR 与代码审查的 Git Flow 策略
• 实践收获：团队开发中，多人直接推送 main 分支是灾难性的。我们制定了规范：任何新功能必须在独立的 feature/xxx 分支开发，完成后向 dev 或 main 提交 Pull Request，且必须有至少一名其他队员的 Review 通过。这不仅减少了代码合并时的冲突，也让团队成员对彼此的代码逻辑保持了同步。

4. 测试阶段

• 知识点：矩阵式玩家试玩测试与冒烟测试
• 实践收获：游戏软件的动态性极强。除了单元测试外，我们设计了一张“测试矩阵”，涵盖了不同的关卡配置、防御塔摆放组合以及极限波次的怪物刷新。每次合并重要代码后，我们都会进行一次冒烟测试，确保最基本的游戏循环不会崩溃，再邀请外组同学进行试玩，记录并归档各种异常的系统边界状态。

5. 发布阶段

• 知识点：基于 CI/CD 的自动化构建与多平台制品分发
• 实践收获：以往打包游戏需要开发人员在本地手动编译、压缩再打包上传。我们配置了 GitHub Actions 自动化工作流，当 main 分支有代码合入时，流水线会自动拉取代码并在云端执行 WebGL 版本的编译打包，生成可直接在线预览和下载的制品。这大大降低了我们向测试人员分发新版本的成本。

6. 维护阶段

• 知识点：缺陷追踪与热修复机制
• 实践收获：在游戏供同学们体验后，有反馈称在特定操作下怪物会卡在 hexagonal grid 的边缘无法移动。我们通过 GitHub Issues 建立缺陷卡片，定位为寻路网格更新不同步的问题。我们迅速在 hotfix/pathfinding 分支进行了修复，测试通过后合并发布。这让我体会到，维护阶段的关键在于快速响应反馈与缺陷生命周期的闭环管理。

---

第三部分：个人、结对与团队项目的经历与心得

回顾这一个学期的软件工程课程，从单打独斗的个人项目，到相互磨合的结对编程，再到多人协作、最终交付 HexaVigil 的团队项目，这不仅是技术栈的累积过程，更是一次关于“如何在约束条件下与人、与机器协作”的认知升级。

• 个人项目：
  在个人项目中，没有协作的摩擦，所有的痛苦和快乐都来源于自己。在这个阶段，我最深刻的体会是“规范不仅是写给别人看的，更是救自己命的”。在起初偷懒不写测试用例、不写详细注释的情况下，面对中后期复杂的逻辑 Bug，我不得不花数倍的时间去重构。个人项目让我建立起了对版本控制、单元测试和代码规范的敬畏之心。
• 结对编程：
  结对编程是一次非常奇妙的体验。当两个习惯、风格不同的人坐在同一个屏幕前时，编码不再是纯粹的智力输出，而变成了高频的沟通与妥协。在结对过程中，我们学会了在敲键盘前先用草稿纸画出逻辑草图，学会了如何建设性地指出对方代码中的潜在缺陷。这种“领航员-驾驶员”的模式，帮我戒掉了盲目堆砌代码的坏习惯，也让我体会到“他山之石可以攻玉”的快乐。
• 团队项目：
  团队项目则是真正的“硬核生存挑战”。在 HexaVigil 的开发过程中，我们面临着学业压力、技术瓶颈、艺术资源匮乏等多重考验。我们曾为了关卡设计的趣味性争论到深夜，也曾为了在截止日期前交付一个稳定的版本而主动砍掉一些过于复杂的机制。
  在这个过程中，我最深刻的领悟是：完美的架构只存在于教科书中，而优秀的软件工程则是在有限的时间、人力和资源约束下，做出最合理的权衡与妥协，并坚持把最核心的体验交付给用户。 看着原本只存在于讨论草图上的“六天防御循环”最终在 hex 棋盘上流畅运转、看着同学们在电脑前专注地部署防御塔，那一刻的成就感，让我真正理解了这门课“做中学”的深层含义。

感谢在这条路上并肩作战的队友们，感谢老师与助教的悉心指导。软件工程是一门需要终身修行的实践艺术，而我们在 2026 年春天迈出的这一步，踏实且充满力量。