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

项目	内容
这个作业属于哪个课程	26春软件工程
这个作业的要求在哪里	[I.3] 个人作业：结课总结
我在这个课程的目标是	学习软工方法论和相关知识，提高个人代码能力，在项目实践中锻炼团队协作能力。
这个作业在哪个具体方面帮助我实现目标	通过回顾阅读提问、结对编程和团队项目，把需求、设计、实现、测试、发布、维护这些知识点放回真实任务里重新理解。

一、课程回顾

学期初，我在阅读《构建之法》后写下了这篇提问博客：[I.1] 个人作业：阅读和提问：https://www.cnblogs.com/uho3326/p/19690651

当时的问题更多是在顺着书里的材料和查到的资料推理，很多判断类似于“纸上谈兵”。

一个学期之后，我经历了个人阅读&提问和软件案例分析作业、结对项目“花见小路”和团队项目网页搜打撤游戏“杰后余生”。这些项目规模都有限，但十分贴近真实开发中出现的问题：规则（需求）理解偏差会导致判定错误，测试覆盖不足会漏掉边界情况，游戏细节会影响玩家游玩体验，多人协作时每个人对同一个功能的理解也会出现偏差。回头看，学期初提出的问题依然值得讨论，只是我现在能够把它们放到更具体的开发场景里作答。

二、对之前提出问题的解答

问题1：开源项目维护者如何保障开源项目的长期维护质量？

我更倾向于把开源维护理解成一件“长期减负”的事。维护质量很难只靠维护者的责任心维持，真正能持续发挥作用的是清晰的贡献规则、稳定的模块边界、可运行的自动化测试、可追踪的 Issue 和足够准确的文档等等足够具体、能够量化的因素。项目越大，维护者越需要把判断成本前移，让贡献者在提交之前就能发现明显问题。

比如，在团队项目中，我主要负责地图美术、地图资源和地图工坊相关工作和代码编写。Alpha 初期，我的任务集中在地图草图、地板和墙壁贴图、碰撞层、出生点、宝箱点、撤离点等内容，很快构建起了一个大的框架。但到了后期，工作逐渐变成修复地图贴图展示问题、处理大门和墙面 Bug、调整墙壁偏移与人物碰撞箱、修复图形硬编码和地图素材等等细节问题。表面上看，这些是美术和资源问题；放到工程里看，它们都关系到后续阶段中其他同学能否稳定接入资源并继续开发，玩家能否准确理解我们传达的含义。

开源项目中的技术债也类似。技术债除了代码粗糙之外，也可能是由于资源命名混乱、接口约定含糊、文档滞后、方案没有坚持长期主义等。尽管课程项目的生命周期很短，但这些问题已经能明显影响联调效率；换成长期开放的开源项目，影响会更大。

这个问题还需要继续想清楚的一点是维护者激励。测试、文档和规范可以降低维护成本，却很难直接解决“谁长期投入时间”的问题。大型项目可以依靠基金会、企业赞助或生态收益，小型项目往往依赖个人热情。热情衰退之后，项目怎样平稳交接，在我的GitHub stars里就有好几个这样“苦苦支撑”的项目。

问题2：关于使用代码注入分析效能

学期初我对代码注入的疑问，主要来自 IDEA Profiler 这类工具已经能用火焰图和调用树定位性能热点。现在我会把采样分析和插桩分析看成两类观察手段。

采样更适合检索程序运行时把时间用在什么位置，对程序运行干扰小，用于判断性能瓶颈。插桩或代码注入更适合判断某个事件是否发生过或者执行了多少次，找到业务完整流程。在游戏项目里，这种差别比较明显。很多体验问题不能和单纯耗时问题一样去处理，比如玩家位置回滚、碰撞边界异常、贴图层级压住人物、地图对象缺失，单靠耗时图很难解释清楚。此时更有用的可能是针对日志和状态记录的检查，结合视觉呈现、数据信息和玩家操作来复现bug并分析。

问题3：使用 goto 是否有助于程序逻辑的清晰体现？

我认为 goto 在少数底层语言场景中有实际用途，尤其适合统一资源释放、减少重复清理逻辑。但在我这学期接触的 AssemblyScript、TypeScript、前端状态管理和服务端逻辑里，更有价值的做法通常是拆函数、明确状态、写清边界条件。

结对项目 T1 的核心只是几个 if 分支，涉及分数、标记数、轮次、第三轮平局规则等。这里真正影响可读性的地方，是判定顺序和测试覆盖。我和队友通过 myScore、oppScore、myCount、oppCount 这类中间量把状态计算清楚后，再按规则顺序判断。T2 和 T3 继续复用前面的状态计算和判定逻辑，清晰的状态抽象往往比随意的 goto 这类控制流技巧更加可靠。

所以，goto 这个问题应该放在“可维护性”里看。控制流的形式只是表层，程序员能否让读者快速理解状态从哪里来、经过哪些过程、得到什么结果才是关键所在。

问题4：没有明确目标用户群体时如何调研用户需求？

我们在团队项目中实践了这个问题：“杰后余生”最早的设想是 Web 端 2.5D 像素风多人生存撤离游戏，目标用户大致是校园用户、熟人组局玩家和愿意低成本试玩的游戏爱好者。这是我们通过团队讨论、竞品调研和实际可达用户得到的判断。

实际开发过程中，项目需求调研类似于持续修正的负反馈过程。Alpha 阶段先对基本玩法和流程进行大方面的实现，保证玩家能创建房间、选职业、进黑市、进入地图、开箱、战斗、撤离、结算。到了 Beta 阶段，我们在试玩、测试和开发中发现了固定地图内容有限、人数不足开房时对抗压力不足、对战依赖玩家技术等问题，地图资源也需要更方便地生产和复用，因此把重点放在地图工坊、地图贴图细化、怪物 AI、人机角色上。对游戏来说，需求调研除了问用户想要什么，更需要注重用户在真实游玩中的体验。

问题5：UML 工具是否仍然有价值？

关于UML，我认可 Martin Fowler 所说的“草图”用法。对课程项目来说，严格画完整 UML 的收益有限也无必要，但用结构化文档把状态、模块和资源关系讲清楚很有必要。

我们的功能规格说明书和技术规格说明书承担了road map的作用。Phase 0 到 Phase 3 的阶段划分、房间成员和房主权限、地图资源格式、client/server/shared 的分层、地图工坊如何保存和读取地图，这些关键点如果只散落在代码里，会对团队沟通造成很大障碍。UML 或类似工具的关键价值是让团队在写代码之前拥有同一套概念，对齐颗粒度。

问题6：为什么很多成功创新者出现在后发阶段？

在本学期的团队项目迭代中，Alpha 阶段解决的是构建一个游戏框架和验证游戏可行性的问题，Beta 阶段解决的是“游戏可玩性和提升游戏体验的问题，Beta 的很多改进都来自 Alpha 暴露的问题。

同理，产品创新里也有类似逻辑。先行者早进入市场，可以积累用户和经验，也会承受技术成熟度、需求判断和用户教育上的成本。后发者可以观察前面的失败，避免踩坑，但机会窗口、资源投入和执行速度同样重要。我们的团队项目中，Beta 阶段能做得更好，是因为 Alpha 阶段已经通过探索和测试找出问题；同时 Beta 也必须面对 Alpha 留下的资源、架构，处理和修复其中的缺陷。

三、仍需继续想清楚的部分

开源维护中的长期激励机制仍然较为模糊。流程和规范可以让项目更好维护，但是维护者的持续投入、继任者的培养、社区治理的权力边界，仍然需要更多真实案例和实践来理解。

由UML引申，AI 辅助开发带来的工程变化也值得关注。我们使用 AI 生成或辅助内容时需要人工复核，代码、素材都有部分由 AI 参与完成，对于程序员来说真正关键的工作是需求理解、产物检查、功能确认和测试验证。这是否是之后软件工程开发的普遍模式？应对这种变化我们又该如何适应并在学习阶段进行训练？

四、新产生的问题

1. 当 AI 参与代码、素材生成时，真实开发环境中软件工程团队遵循怎样的规范？
   这关系到后续追责和维护。尤其是美术资源或前端实现，如果只看到最终文件，很难判断它经过了哪些人工处理，是否符合团队的规范流程。

2. 游戏项目中，可玩性和客户端怎样转化成可检查的标准？
   我在团队相关任务中感受到，很多非功能问题会明显影响体验。比如墙和建筑边缘的贴图透视原则，撤离点、宝箱、机关是否显眼，碰撞箱是否符合视觉预期。这类问题只能结合试玩体验、截图记录和玩家测试来判断。

五、项目六个阶段中的知识点回顾

阶段	我学到的知识点	结合项目的理解
需求	需求分析要划定可交付范围	团队项目早期想法很多，但课程时间有限。我们最终把重点放在 Web 端多人搜打撤、三局制、黑市、撤离、地图和少人局体验上。对我负责的美术与地图资源来说，需求分析还包括判断需要哪些视觉元素，比如墙体、门、草丛、宝箱等地图素材。
设计	设计要把沟通成本降下来	结对项目中，T1 需要先把胜负判定的中间量和分支顺序理清楚；团队项目中，地图草图、碰撞层、出生点、宝箱点、撤离点和资源命名都需要提前对齐。设计文档和示意图能够于让前端、后端、测试和美术能围绕同一问题进行讨论。
实现	实现要给后续修改留余地	结对项目里，T2 复用了 T1 的结算思路，T3 又复用了 T2 的状态计算；团队项目里，地图贴图、地图对象和地图工坊也经历了多次接入与修补。早期把资源和代码逻辑写死，没有预留接口的话，后面修改都会很痛苦。
测试	测试要覆盖真实边界	我在结对项目 T1 中主要负责编写测试样例，而在团队项目里，地图测试更依赖真实操作，需要在修改代码后反复试玩和截图确认。
发布	发布要考虑用户实际进入路径	Alpha 和 Beta 的展示让我意识到，发布并非只把服务跑起来。试玩链接、地图选择、演示路线、资源加载、展示材料和临时故障处理都会影响最终效果。地图资源在发布时也要平衡卡顿，支持现场试玩，处理好并发和同步问题。
维护	维护要减少后来修改的成本	Beta 阶段我持续处理了地图墙与建筑墙图层的问题，这是源于其与地图其他功能高度耦合，容易出现bug，我通过提取核心逻辑，减少了代码重复问题，降低维护成本，其他成员接入时也只需要复用即可。

六、项目心得

1. 个人作业：用工程视角看软件

个人作业让我开始从更完整的角度看软件。以前评价一个工具，我通常会直接说“好用”或“难用”；做案例分析后，我会思考它的目标用户，功能优先级排序，Bug 严重程度，后续迭代怎么进行。这种思考对团队项目有较大帮助。做游戏时，有些功能技术上很有意思或实现很复杂，但玩家感知很弱；有些交互逻辑十分细节，却会实际影响玩家游玩体验。

2. 结对项目：测试样例和状态抽象更为重要

结对项目开始前，我对 Wasm 只是听说过，对花见小路的桌游规则也是从零开始。在实际工程开发中，很多任务接手时，我们对技术和业务都需要重新学习。

T1 “七色之缨”中，我主要负责测试样例。我设计了分值达到 11 分获胜、标记数达到 4 个获胜、前两轮暂时继续、第三轮总分比较、最高档位标记比较、最终平局等样例。写这些测试时，我对于规则的理解也更为深刻。

T2 “不祥之影”需要根据历史记录推出当前状态，难点主要是字符串解析和状态更新。我们把算标记的逻辑抽出来，使用类似 T1 的结算机制处理结果。T3 “道途之荆”进一步走向策略决策，我们讨论过蒙特卡洛树搜索、CFR 等方案，最终选择启发式加贪心的方案：优先锁定高分关键标记，再用一步模拟评估“赠与”分法，通过测试和逻辑分析不断调整策略顺序。

结对编程过程中，一个人写代码、另一个人检查规则和补充测试，确实能减少低级错误；但开发周期拉长后，上下文恢复成本很高，十分考验团队默契，有时一个人在写，另一个人的时间利用也一般，又或者是没有跟上思路导致需要停下来继续讨论。

3. 团队项目：细节直接影响工程质量

团队项目中，我是美术 / 副 PM。实际工作集中在地图美术、资源贴图、地图工坊相关支持上。这个角色看起来偏美术，实际和前端渲染、地图数据、玩家碰撞、玩法设计联系都比较紧密。

Alpha 初期，我的主要工作是完成地图素材绘制、角色设定文档，把地图资源接入代码、修复贴图图层相关问题。游戏项目的美术资源有很强的工程属性，很多时候，我的工作需要修改前后端代码，在真实对局中进行验证，处理细节问题并保证整体质量。

Beta 阶段，我的工作继续围绕地图和地图工坊展开，处理地图工坊分享流程、地图资源整理、贴图拼接、地图美术与交互支持。这些工作具体而细节，让我对维护和迭代有了更实际的理解。项目真正消耗时间的部分是把已有内容打磨到更好的状态，这个过程中，资源、玩法和代码是一起迭代的。

软工完结撒花！