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

项目	内容
这个作业属于哪个课程	2026年春季软件工程（北航计算机学院）
这个作业的要求在哪里	个人作业：结课总结
我在这个课程的目标是	了解以团队完成软件开发的流程，承担自己角色的责任，吸取团队软件开发经验
这个作业在哪个具体方面帮助我实现目标	总结回顾这一学期的经历，提升对软件工程团队开发的认知

问题回顾和解答

链接到以前提问题的博客

个人作业：阅读和提问

问题1：通过记录随机数种子，不就可以重复测试的结果么？

我不太明白为什么教材会说在单元测试中使用随机数在一般情况下不好，而不是一般情况下可以。

单元测试应该提供快速、确定、无副作用的测试结果，使用固定值来保证每次运行结果100%确定，运行快。
随机种子方法适用于模糊测试，能发现没想到的边界情况，但是随机测试需要运行海量数据，耗时较长，可能会漏测某个关键逻辑。如果发现报错，需要找到当时的种子再切换到对应分支，维护成本高，并且根据该种子修复代码后，又可能因为另一种子报错，可能没有根源性地解决问题。
因此在单元测试中使用随机数在一般情况下不好。

问题2：一条错误处理路径很难到达真的可以考虑删掉吗？

一条错误处理路径很难到达真的可以考虑删掉吗？我感觉这跟课上提到的，飞机上发生事故的概率极低，却一定需要有安全须知是差不多的，不能因为一条错误路径很难到达就不去写，万一真到达了可能会产生无法预料的结果。

教材中的很难到达的错误处理路径指的应该是“逻辑冗余”的部分，对代码健壮性作用很小且容易造成认知负担，让人怀疑其存在的必要性。飞机安全须知的例子对应的是“环境上难触发”，虽然概率低但是物理意义上是始终可能发生的，因此此类路径不能删除，而“逻辑冗余”路径可以考虑删除。

问题3：新手PM的试错成本应该由谁承担？如何在不牺牲个人职业信誉的前提下获得成长？

我认为想要优秀地完成这些任务不是一朝一夕可以做到的，那在成长的过程中所需的成本和造就的后果应该如何/由谁承担？教材提到的“拍屁股走人”并用“谁没年轻过”轻描淡写，如果第一次作为PM负责第一个项目就有如上行径不会让自己的业内声誉产生不好的影响吗？

一位新手PM不可能独自承担全部成本，否则没人敢当PM。在本课程中采用的方法是由导师和助教通过课程交流和Scrum Meeting跟进进度，可以给PM和团队提出建议，减轻PM的犯错概率和严重程度，并且同学们都还在学习阶段，因此可以相互理解。
信誉崩塌的唯一途径，是“突然在截止日告诉所有人做不完了”，而不是“过程中不断报错”，因此当一个“虽然有风险，但始终保持透明、积极复盘”的PM即可保护个人职业信誉。

问题4：有了AI的加入后，结对编程的存在的必要性和有效性是否还存在？

知识和经验的交流是不是也会从如何编码变为如何写提示词，如何审查AI的代码，如何养好龙虾？

人与人之间的结对编程是抵御AI幻觉的一种手段，在AI变得更普遍的情况下，反而人与人之间的配合尤为重要。在代码出现问题时，AI不能站出来解决问题，而是要由程序员来负责，因此基于职业信任和压力的相互审视是AI无法取代的。并且人与人之间意见相左时产生的摩擦是发现设计漏洞的最佳时机，因为AI往往会迎合提示词，完成我们要求完成的工作。
知识和经验的交流内容会更加复杂，除了原始的编码，还会有问题拆解、工具使用、提示词编写等。

问题5：UI设计的深度体现在哪里？是否有规范和流程让UI设计达到让产品有“越用越顺手”的用户体验感？

像是软件工程这门课教我们软件团队开发的规范和流程，那UI呢，感觉上UI包括了艺术性，所以在设计过程可能会更难被规范。

UI设计的深度体现在对人类认知行为模式的深刻理解。其分为一下三层：

• 表层（表现层）：视觉风格、色彩、字体、圆角。这是大家常说的“画图”，它决定了第一印象。这种审美确实带有主观性和艺术性，难以完全量化。
• 中层（行为层）：交互流程、信息架构、导航逻辑。它决定了用户能不能找到想要的功能，涉及逻辑推理和任务分析。
• 深层（心智模型层）：“越用越顺手”，要求设计者深刻理解用户的“肌肉记忆”和“任务频率”。

现代互联网大厂已经摸索出了一套“框架内的艺术”，通过严格的流程来解决这个问题。UI 设计的流程本质上和软件工程流程是完全平行的：

软件工程流程	UI/UX 设计流程	产出物
需求分析	用户研究与任务分析	用户画像、场景地图（Scenarios）
概要设计	信息架构与流程设计	流程图（Flowchart）、站点地图
详细设计	交互原型与视觉设计	高保真原型（Figma）、设计稿
编码实现	设计系统	组件库、UI 规范文档
测试验收	可用性测试	测试报告、眼动追踪数据

在这其中，规范负责兜底，艺术负责破局，因此艺术性其实并不影响规范性。

知识点

需求

在写需求文档前，需要充分地对我们的选题进行调研，防止产生认知错误。在需求文档中，我们采用了教材中提到的NABCD方法，对选题进行充分的分析，从而写出需求文档。

设计

在确定设计时，我们进行了两轮比较重大的讨论，一个是讨论低代码如何设计，另一个是服务端和客户端的通信如何设计。低代码部分我们定义了多个模块的json格式，通信部分采用了WebSocket定义了信息内容。

实现

实现过程中，我反复地去确认需求和设计文档保证自己的实现没有跑偏，并与PM讨论实现细节。

测试

我大概了解了测试同学采用的自动化测试方法，每次创建PR时都会自动运行测试代码。

发布

我大概了解了怎么租服务器和申请域名。

维护

我学会了怎么在网站中使用创造者模式来确认出错部分，以在后续进行修复。

理解和心得

个人项目

个人项目中，通过课程组给的lab教材，我对规范的需求文档等工作文档应该长什么样有了认知，学习了如何把文档写得规范、严谨。

结对编程

结对编程的过程中，我们阅读需求后，会互相讨论要如何完成任务。有些时候，一些方法在自己提出时不一定能意识到其可行性，而与他人讨论可以发现问题或者得到肯定。

团队项目

在团队中，我负责了前端开发的部分工作。在过程中，我认为消息回复的及时性、透明的沟通可以有效地减少团队间的信息差，提升开发效率。一些工作文档如API文档，可以减少前后端对接的难度，也能避免大量的无效工作、后期大量修改等。