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

项目	内容
这个作业属于哪个课程	2026年春季软件工程 - 北京航空航天大学 - 班级博客
这个作业的要求在哪里	[I.3] 个人作业：提问回顾与个人总结
我在这个课程的目标是	学习软件工程相关基础知识，通过实践体会完整软件开发生命周期
这个作业在哪个具体方面帮助我实现目标	回顾学期初的疑问，结合一学期的实践进行反思与总结

---

一、前言

学期初的阅读作业中，我在快速翻阅《构建之法》后书写了第一篇博客：[I.1] 个人作业：阅读和提问，它们大多围绕一个核心困惑：当 AI 辅助开发、平台工程、低代码等新趋势冲击传统软件工程时，书中的原则是否依然成立？

如今一个学期过去，我经历了结对项目「花见小路」的规则引擎与 AI 决策开发、团队项目「第四轴」的完整 Unity RPG 游戏开发流程（负责 UI 与视觉效果），以及个人软件案例分析。实践是最好的老师，现在回头看当初的问题，有些有了更清晰的答案，有些依然悬而未决，也有些新的困惑冒了出来。

---

二、对原有问题的解答

问题一：当代码由 AI 生成而非手写时，书中的"单元测试由作者负责"是否依然成立？

原问回顾： 书中强调"单元测试必须由最熟悉代码的人（程序的作者）来写"。但在 AI 辅助编程普及的今天，如果开发者对 AI 生成代码的底层逻辑理解有限，他们还能写出有效的单元测试吗？

我的回答：原则依然成立，但"作者"的定义需要扩展。

在结对项目「花见小路」中，我们使用了 Gemini-3 辅助代码审查和测试样例整理。实践中我发现：AI 生成的代码确实可以快速搭建框架，但边界条件的测试设计仍然需要人来完成。比如在 T1 规则判定模块中，AI 可以帮我们生成"双方同分比最高档位"的测试思路框架，但具体的测试向量——board = [1,1,1,-1,-1,0,0], round=3 期望返回 -1——是我们自己根据对规则的理解构造的。AI 不知道"前两轮未触发胜利条件应返回 0"这条隐式规则，我们必须主动设计覆盖它的用例。

在团队项目中我对此有了额外的体会。我负责 UI 和视觉效果时，部分使用 AI 辅助生成 Unity C# 脚本和 Shader 代码。但 UI 的正确性不仅仅是"代码能跑"——按钮的交互反馈是否符合预期、视觉特效在不同分辨率下是否表现一致、色彩搭配在游戏的黑暗场景中是否仍然可辨识——这些东西 AI 无法自动验证。我必须亲自在不同场景、不同分辨率下反复测试。UI 的"单元测试"不是自动化脚本，而是人的眼睛和手感。

结论：单元测试的责任不应转移到 AI 工具上，而应转移到"定义需求的开发者"身上。书中的原则需要更新为：单元测试必须由最理解需求的人来设计，无论代码由谁编写。

---

问题二：软件开发流程的演进方向是从"个人流程"到"平台工程"，这与书中反复强调的"个人能力"是否矛盾？

原问回顾： 平台工程通过内部开发者平台屏蔽底层复杂性，而 PSP 强调个人精确记录和分析自己的行为。两者是否矛盾？

我的回答：不矛盾，它们是不同层次的问题。

在团队项目「第四轴」中，我们使用 Unity 引擎作为开发平台，Git 作为版本管理平台，WeChat 群聊 + GitHub Issues+任务清单共享文档等作为沟通和任务分配平台。这些"平台"确实帮我们屏蔽了大量底层复杂性——Unity 的 UGUI 系统让我不需要从零实现渲染管线，Git 的分支管理让多人并行开发成为可能。但平台并没有替代个人的流程管理。

事实上，我在参与团队项目的同时辅助维护 Git 仓库，深刻体会到：工具平台的质量取决于使用者的纪律。 我们制定了一套完整的 Git 规范（统一的 commit message 格式、feature/fix 分支命名规则），但规范本身只是文档——真正让它生效的是每个人在每次提交时的自我约束。偶尔有队友忘记按格式提交，就需要在 WeChat 群或 Issue 里提醒。平台的自动化能减少出错，但不能消除对个人责任心的依赖。

平台工程解决的是"团队间的一致性"问题，PSP 解决的是"个人的持续改进"问题。 平台让团队用统一的工具链和流程协作，PSP 让每个人在自己的环节里不断优化。两者是互补的：平台提供了标准化的"跑道"，PSP 帮助个人在这条跑道上跑得更快。

---

问题三：当"无代码/低代码+AI"让业务人员成为开发者时，书中的"软件工程师成长路径"是否需要重新定义？

原问回顾： 无代码/低代码平台结合 AI 后，非专业开发者也能构建业务系统。传统软件工程师的不可替代性在哪里？

我的回答：成长路径的大方向依然有效，但需要加入"系统设计"和"AI 协作"这两个新维度。从我的角色来看，还需要加上"审美与体验设计"的维度。

我们的团队项目「第四轴」是一个很好的例证。这个游戏的核心视觉需求和UI没有任何低代码平台能自动生成。我需要设计一套在 场景中打开关闭的 UI 面板，让玩家在进行标签操作时能看到视觉反馈（如标签使用获取提示）；需要确保标签系统的 UI 交互清晰传达"剥离-粘贴"的核心玩法，而不是让玩家对着满屏文字不知所措。还有在进行教程和引导界面，需要考虑玩家的思维方式，不能完全以开发者的视角看待，逐步引导玩家熟悉操作和系统。

以上这些不是"拖控件"层面的工作，而是信息架构与视觉叙事层面的工作。低代码平台可以生成表单和按钮，但它无法替你决定：什么样的配色方案能保持UI的整体一致？什么样的动效和提示能暗示"标签被剥离"的反馈感？什么样的 UI 布局和操作引导能让玩家在第一次进入游戏时就理解基本的游戏操作和接下来的游戏方向。

未来软件工程师的核心能力确实在从"代码编写"向"复杂系统设计"和"AI 协作管理"转移。 而对我从事的 UI/视觉方向而言，不可替代的能力是审美判断+交互直觉+对玩家体验的共情——这些是 AI 目前无法真正做到的。

---

问题四：书中提倡使用 goto 实现函数单一出口，这与现代编程规范中"避免使用 goto"是否矛盾？

原问回顾： 书中建议使用 goto 实现函数单一出口，但自 Dijkstra 以来主流观点反对 goto。在 2020 年代的开发中，goto 是否仍应被视为可接受的实践？

我的回答：原则（单一出口）是对的，手段（goto）在现代语言中已有更好的替代方案。

在团队项目中使用 C#（Unity）开发 UI 时，我们从未使用过 goto。C# 提供了 try-catch-finally、using 语句等机制来保证资源清理。例如，在实现 UI 面板的动画状态机时，我们使用协程（Coroutine）和 yield return 来管理动画序列，配合状态枚举来保证单一出口——代码比用 goto 清晰得多。

但这不意味着 goto 完全一无是处。在结对项目的 C 语言环境（WebAssembly 编译目标）中，如果我们需要手动管理内存，goto 用于错误处理的统一跳转确实是最简洁的方案。Linux 内核中大量使用 goto 进行错误处理也证明了这一点。

结论：语言特性决定了最佳实践。 在有 RAII/异常处理的语言中用 goto 是坏习惯；在 C 语言中用 goto 做错误处理的统一跳转是合理选择。书中"只要有助于程序逻辑的清晰体现，什么方法都可以使用"的原则是对的，但需要补充：前提是了解你的语言提供了什么更好的替代机制。

---

问题五：如果 AI 能让"重写"比"维护"更便宜，书中强调的"可维护性"原则是否还成立？

原问回顾： 当 AI 能够在一小时内重写整个模块时，投入大量精力去"维护"现有代码是否还有必要？

我的回答：在当前阶段，可维护性依然至关重要——但理由变了。对 UI 代码尤其如此。

在团队项目中，UI 代码有一个特殊之处：它和"视觉呈现"强耦合。AI 可以重写一个 UI 按钮的点击逻辑，但它无法重写"这个按钮在游戏交互场景中必须足够明显才能被玩家看到"的设计意图。这类决策通常不会写在注释里——它们存在于设计稿、WeChat 聊天记录、以及 Issue 讨论串中。如果让 AI 重写 UI 代码，它会丢失所有这些隐性知识。

更实际的问题是：UI 的调整往往是高频、小粒度的。比如一开始说"这个标签面板往左移 20px"，几轮迭代后又说"这个颜色饱和度降 10%"，这些微调如果用"重写"来应对，每次都要重新验证整个 UI 的交互流程，反而比直接修改更慢。

可维护性的核心价值不在于"方便以后改代码"，而在于"让团队成员之间能够相互理解对方的意图"。 在 UI 开发中，这一点加倍成立——因为 UI 代码同时承载了程序逻辑、视觉设计和交互意图三种信息。

---

三、仍未解决的问题

坦白说，问题五（AI 重写 vs 可维护性）我还没有完全想清楚。在结对项目中，我确实遇到过"花两天理解旧代码 vs 花两小时让 AI 重写"的情况。但在 UI 工作中，我的体感是 AI 重写 UI 代码的风险远高于重写纯逻辑代码——因为 UI 的正确性包含大量"看起来对不对"的主观判断，这种判断目前还无法自动化。

---

四、新产生的问题

经过一个学期的团队项目实践，我产生了以下新问题：

问题六：在 Scrum 框架下，当团队成员能力差异较大时，"自组织团队"的理想能否真正实现？

在我们的 Alpha 阶段，团队中有成员对 Unity 完全零基础，而另一些成员已有游戏开发经验；有的没有美术基础，有的资源只有一个成员会制作。Scrum 强调团队自组织、成员认领任务，但实践中我们发现：新手往往不敢认领核心模块，有经验的成员则承担了不成比例的大量的工作量。我们通过 PM（蒋渝）在 WeChat 群和 Issue 中的主动协调分发任务、以及同学互相委托缓解了这个问题，但这实质上是一种"半自组织"——方向由 PM 牵引，细节由成员自行协商。

问题七：异步沟通（WeChat + GitHub Issues）能否替代面对面交流？

我们团队的主要沟通方式是 WeChat 群聊和 GitHub Issues。异步沟通的好处是信息留痕、可追溯——我可以在任何时候翻聊天记录找回某次设计讨论的结论。但代价是：文字沟通缺乏语气和肢体语言，容易产生误解，开发过程多次出现因为微信描述不严谨导致的功能理解偏差，造成了不必要的开发延误；复杂的设计讨论（比如标签系统的 UI 交互方案）在文字里来回几十条消息，远不如线下五分钟的面对面讨论高效。对于一个以视觉设计为主要产出的角色来说，这种沟通损耗尤其明显——"这个动效感觉不对"用文字永远说不清，必须画出草图或者示意图。

---

五、六个阶段的知识点举例

阶段	学到的知识点（举例）	具体说明
需求	NABCD 需求分析框架	在选题评审中，我们用 N（Need，需求）、A（Approach，做法）、B（Benefit，好处）、C（Competitors，竞争）、D（Delivery，推广）五个维度系统性地分析了《第四轴》的可行性。作为 UI 负责人，我特别关注了竞品分析环节——研究《Baba Is You》《Outer Wilds》等游戏的 UI 风格，帮助我们确定了"极简rpg+功能可见性优先"的视觉方向。
设计	UI 原型先行于代码	在团队项目中，我学到的一个重要经验是：在写任何 UI 代码之前，先出低保真原型。 我们用简单的unity内置ui确定了标签面板、属性面板、设置面板等的布局关系，验证了交互流程之后才开始 实际带像素资源Unity 实现。这避免了"写了一半发现交互不合理，连代码带视觉全部推翻"的返工。
实现	Unity UGUI 的锚点与自适应布局	具体到 Unity UI 开发，我深入理解了 UGUI 的 RectTransform 锚点系统和 Canvas Scaler。游戏需要在不同分辨率（16:9、16:10、21:9）下正确显示，我通过合理设置锚点和 Canvas 的缩放模式，实现了 UI 的一次布局、多分辨率自适应，而不是为每种分辨率单独调整。
测试	视觉走查与多分辨率测试	UI 的测试不同于逻辑测试——除了功能测试（按钮是否可点击、面板是否可拖拽），还需要视觉检查。我在至少三种分辨率、sdr和hdr设置下逐一检查每个 UI 面板，确保文字不被裁切、颜色在暗场景下可辨识、动效帧率稳定。这让我意识到：UI 测试需要一张 checklist，而不是靠记忆。
发布	版本管理与发布流程	团队采用了 Git Flow 分支模型（main → release → dev → feature/fix），每次发布前从 dev 合并到 release 进行验证。我辅助维护 Git 仓库，体会到规范的 branch 策略对多人并行 UI 开发的价值：我在 feature/ui-tag 分支上开发标签 UI，另一位队友在 feature/tag-system 上开发标签系统，互不干扰，通过 Pull Request 合并时再由团队一起 Review。
维护	UI 资源的模块化管理	Beta 阶段我们发现，早期 UI 的图片资源和 Prefab 散落在项目的各个角落，找资源浪费时间。一位成员花了一个下午整理，按功能模块和类型重新组织 UI 资源目录，并统一了命名规范。UI 的"可维护性"不仅是代码层面的，也是资源管理层面的。

---

六、个人项目 / 结对编程 / 团队项目心得

个人项目（软件案例分析）

分析 Moonlight V+ 的过程中，我最大的收获是学会了从多个维度评价一个软件：不只是"好不好用"，还要看数据量、界面设计、功能完整性、准确度、用户体验等维度。这对我后来的 UI 工作有直接帮助——在设计「第四轴」的界面时，我会有意识地审视：这个 UI 在"功能可见性"维度上是否清晰？在"视觉一致性"维度上是否统一？在"新手引导"维度上是否友好？这些评价维度成为了我自我审查的框架。

另一个意外收获是第一次真正参与到了开源社区的协作中。在分析过程中，我发现了校园网场景下设备列表无法过滤的问题（Bug 2），并于 2026 年 1 月 4 日向开发团队提交了 Issue #145。让我惊讶的是，开发者 @qiin2333 在 24 小时内就完成了从确认问题到提交 PR 再到合并发布的完整闭环。这次经历让我直观地感受到：一个好的 Issue 报告（包含复现步骤、环境信息、改进建议）能极大提升沟通效率；而开源社区的高效响应机制，也让我看到了"用户反馈→快速迭代"这一闭环在真实项目中的力量。后来在团队项目中，我也借鉴了这种模式——用 Issue 模板规范 Bug 报告格式，附截图和复现步骤，减少沟通成本。

此外，用户调研环节也让我印象深刻。我对同学张某某进行了约 15 分钟的采访，了解他作为目标用户对 Moonlight V+ 的真实看法。调研结果与我本人的使用体验高度吻合——V+ 在界面美观性和中文本地化上的优势是吸引用户的核心差异点，而服务端与客户端版本依赖关系未在应用内显式说明则是影响新用户体验的关键问题。这次访谈让我意识到：开发者自己的体验不能替代用户调研，有些问题只有真正去问、去观察用户的使用过程才能暴露出来。这一认知在后续团队项目中同样适用——设计 UI 交互时，我会主动找不懂开发的室友试玩，观察他们是否能在无提示的情况下理解操作逻辑。

结对编程（花见小路）

结对项目是我这学期技术密度最高的阶段。从零开始学习 WebAssembly、用 C 实现规则引擎、再到用蒙特卡洛树搜索实现 AI 决策——坦白说，这些和我的 UI 方向关联不大，但它教会了我两件事：

1. 代码复审的价值远超预期。 在结对互审中，我帮搭档发现了一处测试样例错误，搭档帮我优化了状态转移的效率。两个人的视角确实比一个人全面。

2. 分层设计是复杂系统的救命稻草。 从 T1 到 T3，代码复杂度指数级增长，但因为我们坚持了分层设计，T3 复用 T1/T2 的逻辑时几乎零成本。这个分层思想后来被我应用在团队作业的 UI 系统中——把 UI 拆成"数据层-展示层-交互层"，每个面板独立管理自己的状态，前后端分离，我只负责显示后端传来的数据。并且还有统一的UIManager管理。

团队项目（第四轴）

团队项目是我这学期收获最大的部分。作为 UI 与视觉效果负责人，我真正体验到了一个完整游戏的 UI 从零到一的全过程。

在角色分工上，我负责了游戏 Logo 的手绘设计、全部 UI 面板的布局与实现（HUD、标签系统界面、提示和教程、菜单、对话框）、以及部分视觉特效（场景切换时的画面处理效果）。同时我辅助团队维护 Git 仓库，确保分支规范和提交规范被正确执行。前期由于ui系统从零开始搭建，进行了大量代码工作，后期细化ui和修复bug工作提交内容就较少了。

在沟通协作上，我们日常用 WeChat 群聊进行快速讨论和进度同步，用 GitHub Issues 进行正式的任务分配和 Bug 追踪。这种"WeChat 即时 + Issue 归档"的模式在实践中效果不错——日常琐事在群里快速解决，需要记录和追踪的事项落在 Issue 里，不会丢失。但也如我前面所说，复杂的设计讨论在纯文字沟通中效率不高。

在技术心得上，最大的收获是对 Unity UGUI 系统的深入掌握，以及"UI 设计不是美术的附属品，而是玩法传达的核心通道"这一认知。在「第四轴」这样一个以"修改世界规则"为核心玩法的游戏中，标签系统的 UI 设计直接影响玩家能否理解"剥离标签 → 粘贴标签 → 世界变化"这一因果链。我设计的标签拖拽交互（从物体 A 拖到物体 B 完成标签转移）经过了三版迭代才达到满意的直观性——第一版用纯表，玩家完全不懂；第二版加了图标但瞬间替换的拖拽反馈不清晰；第三版加入了拖拽时效果和标签"吸附鼠标"动画，测试玩家的理解度才明显提升。

同时大量使用后端传出的事件进行前端响应，这样前后端分离就可以随时修改后端的操作，而前端确定好内容布局就不需要大幅度的修改。使得大部分项目内容可以并行化进行。

另一个收获是学会了用 Issue 管理 UI bug。UI 的 bug 往往比较琐碎——居中对齐、按钮热区太小、某种分辨率下面板被裁切——如果不记录就会被遗忘。我养成了"截图→标红→开 Issue"的习惯，让每个视觉问题都有一条可追踪的记录，既方便自己复查，也让队友了解 UI 的状态。

---

七、总结

学期初我带着五个"质疑性"的问题开始阅读《构建之法》，试图用 AI 时代的新趋势去挑战书中的旧原则。一个学期的实践让我明白：好的原则经得起时间的考验，但需要根据技术发展不断重新诠释。 "单元测试由作者负责"是对的，但"作者"的定义从"写代码的人"扩展到了"定义需求的人"；"可维护性很重要"是对的，但其价值从"便于改代码"扩展到了"便于团队理解彼此的意图"——这对 UI 开发者尤其重要。我还学到了一条属于自己方向的原则：UI 的正确性既包含逻辑正确，也包含视觉正确，后者需要人的眼睛和反复的实际检查来保证，这是 AI 目前无法替代的。

软件工程不是一门能通过看书学会的学科——它必须在实践中感受。在完整走完"需求→设计→实现→测试→发布→维护"全流程之后，我不仅学到了技术，更重要的是学会了如何在团队中协作、如何用工具和流程保障质量、如何在沟通中传达视觉设计的意图。感谢这门课和「码上搞定队」的五位队友，让这段旅程既有挑战也有收获。