[I.3] 个人作业：提问回顾与结课总结

项目	内容
这个作业属于哪个课程	2026年春季软件工程 (北京航空航天大学 - 计算机学院)
这个作业的要求在哪里	[I.3] 个人作业：结课总结
我在这个课程的目标是	学习软件工程的基础知识，在实践中理解和运用
这个作业在哪个具体方面帮助我实现目标	回顾和总结一学期的软件开发经历

旧问题博客链接

[I.1] 个人作业：阅读和提问

上学期初的阅读作业里我提了五个问题，当时没什么实践基础，基本是读书之后的想法。这学期做了结对项目（花见小路）和团队项目（HexaVigil，两个阶段），回过头再看这些问题，有些有了答案，但有些依然没有完全解决。

当初的五个问题，现在怎么看

第一个问题是 AI 时代还要不要自己手写单元测试。现在我觉得重点不在手写还是生成。结对项目里我们让 Copilot 写过测试，团队项目里也用 GUT 测过纯逻辑模块。AI 写测试框架很方便，但它构造出来的测试点未必覆盖全面且有效，很多时候更像是凑数的。具体还得最熟悉这段代码的人来把关。所以谁来写不重要，重要的是正确性要有人负责。我们团队不管用没用 AI，只看交付结果，模块负责人负最终责任。

第二个问题是开发规范什么时候必须严格执行。这个我们组有正反两面的例子。反面是技术规格书里说要画 UML、维护接口字典，实际一张正经的 UML 都没画，文档也长期落后于代码。这正是我在阅读作业里说的形式化执行。正面是分支保护加 PR 强制评审这条我们执行得很严格，确实拦下过一些不应该合入的代码。所以现在我的判断是，规范要不要严格执行，不取决于项目大小，而取决于这段产出会不会被别人读、会不会以后还要改。

第三个问题是成员水平差距大时怎么协作。这个我感受最深，因为大多数核心工作集中在我和另外两三个人身上。我们的贡献分也做出了相应的设置。站在结束之后的角度，我觉得成员的能力不均和各种原因导致的参与积极性不同没办法消除。实践中可行的不是强迫大家平均分工，而是让主要成员分派一些轻量和好做的工作给其他成员，降低自己的工作压力。但是在如今的ai时代，这种分派工作的效率很多时候似乎还不如直接开一个并行的codex线程来的方便，还省去了沟通的功夫。因此对于这个问题我还没有很清晰的答案。

第四个问题是代码行数还能不能衡量工作量。这个答案比较明确：不能了。我们团队基本不看行数，而是看关掉了多少 Issue、完成了多少估点、对游戏的质量提升大不大。我印象比较深的是，在比较临近ddl的时候我做了一批性能优化，改动只有几十行但是价值相当巨大。而我们项目对游戏配置的数据驱动也对其有所影响，比如要加一个新干员有时一行代码都不用写，改改配置就行。所以行数确实没意义了。但纯看issue这些角度也有问题，比如我们 Beta 开的issue的点数估的比较随意，很多工作量和实际情况不完全符合。这方面我感觉很难找到量化的完美指标。

第五个问题是工程那套流程会不会压制创新。做下来我觉得两者不太对立，更像项目不同时期由谁主导。我们几个比较满意的玩法（白天建造、夜晚防守、敌人路线预览、用墙堵路逼怪拆墙）都是前期在自由讨论和尝试中确定的，那个阶段就应该放开尝试。但等框架成型、要团队一起协同修改、要发布给真人玩，就必须按照工程规范来。工程不是来限制创新的，而是把试出来的东西固定下来，避免它在后续改动中退化。

新产生的问题

比如有的同学用 AI 写了代码提了pr之后，另一个人再用ai审，这样的评审能起到多大程度上的作用？一个人对自己没有逐行写过的代码能负多少责任？再比如功能跑起来的效果是个好用的进度指标，但它会掩盖底下的技术债，能跑不代表健康，这种内部质量怎么变成可以被管理的东西？

六个阶段

需求阶段让我明白需求不是功能清单，而是"为谁、在什么场景下解决什么问题"。我们一开始也是不停往上加功能，后来写了具体的用户场景，"敌人路线预览"这个核心玩法才自然出现，它是被场景需要逼出来的，不是硬加的。

设计阶段最大的收获是解耦。多人并行开发又不互相干扰，靠的是事件总线加数据驱动：模块之间发信号通信，不直接互相调用，数值和内容都放在外部配置里。我写战斗的时候不用关心 UI 怎么实现，这是设计带来的。

实现阶段让我意识到性能也是实现的一部分。功能正确不等于可用，最后做的一系列性能优化就是例子，此前逻辑全对但卡顿极大影响体验。

测试阶段让我明白能不能测在设计阶段就决定了——有些内容天然好测，而像UI 和流程只能靠人工和脚本补。

发布阶段我们做得比较满意的是自动化打包发布，合并dev到main分支就能自动导出网页版和桌面版发布在itch.io上。

维护阶段我感触最深的是文档的维护。文档应该要及时迭代，决不能留过时的文本在项目中，无论是对人还是对ai都是一种误导。

最后

个人作业方面，案例分析我选的是 OpenAI 的 Codex CLI，当时花了不少时间实际使用、找 bug、采访同学，还估了一个 16 周的开发计划。现在回看，这个作业对我后面做团队项目有一些帮助，主要是让我习惯了从用户角度去看一个产品，而不是只关注实现。

结对项目和团队项目对我来说差别很大。结对的时候两个人面对面，有什么想法直接说，很多问题在讨论中就解决了。团队项目完全不是这回事，七个人各写各的模块，靠issue和pr推进，很多时候合进去的代码要过几天别人用到了才知道有没有问题。加上大家都有别的课（计网实验和计网理论期末那段时间尤其赶），后期基本就是赶ddl的状态。

一年前我以为软件工程就是写一个大项目，现在觉得写代码本身反而不是最难的部分，怎么在多人协作下维持项目的可迭代性才是。这学期算是有了一个初步的体会。