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

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

项目	内容
这个作业属于哪个课程	2026春季软件工程
这个作业的要求在哪里	[I.3] 个人作业：结课总结
我在这个课程的目标是	学习软件开发流程，团队协作完成软件开发
这个作业在哪个具体方面帮助我实现目标	总结课程经验教训

提问博客：[I.1] 个人作业：阅读和提问。
链接：https://www.cnblogs.com/327hhhhh/p/19693973

---

五个问题

一、结对编程角色为什么需要互换，何时互换？

Driver 写代码关注细节，Navigator 思考架构和边界情况。超过半小时不换，Driver 疲劳出错、Navigator 注意力涣散。换的时机：定时换（25-30 分钟）、完成一个函数换、Navigator 觉得该换思路时立刻换。

我们结对时第一次没换，50 分钟后 Navigator 完全走神，效率很低。第二次定时换，速度快了不少。Navigator 还发现了 Driver 没注意到的边界 bug。

怎么弄清楚的：实践踩坑后读了《Pair Programming Illuminated》，书里从认知心理学角度解释了注意力资源有限、切换角色等于切换关注维度。跟同学复盘后把"定时换"定成了规矩。

---

二、用户调查做到什么程度有意义？

够验证最危险的假设就行，不是越全面越好。我们最初假设用户要推荐功能，找几个人聊完发现他们真正缺的是理解论文内容的能力，直接改了产品方向。Nielsen 的研究表明 5 个用户就能发现 85% 的问题，再多边际收益很低。后来我们还发现，找身边方便的人测没用，得找真正的目标用户。

怎么弄清楚的：第一轮测试我们找了 8 个身边同学，什么意见都有，不知道该听谁的，结果一个都没改。第二轮只找了 3 个真正做科研的目标用户，每个人聊了 40 分钟——问题立刻聚焦了，三条反馈高度重合，我们改完方向就对了。两轮对比让我们在团队讨论时吵了一架：到底"多测几个"有用还是"测对人"有用？有人坚持统计学要样本量，有人觉得深度比数量重要。最后翻出 Nielsen 的论文和《Don't Make Me Think》里的观点——5 个用户就能发现 85% 的问题，前提是找对人。理论和实践对上了，团队才达成共识：少而精的深度访谈比撒网式问卷有效得多。

---

三、UI 评估原则必须严格遵守吗？

不用。Nielsen 十条是检查清单不是法律，他自己也说是"粗略的经验法则"。原则之间本身就有矛盾，不同场景优先级也不同——医疗设备的防错远比游戏界面重要。冲突时按"安全 > 核心任务能不能完成 > 效率 > 美观"排序。用户实际没遇到问题就不用"修复"。

怎么弄清楚的：读了 Nielsen 原文和《About Face》，都强调理解用户目标比遵守清单重要。实践上发现有些"违反原则"的设计用户根本不在意。

---

四、创新想法起步怎么判断能否吸引大众？

起步阶段判断大众是伪命题。该问的是"能不能让一小群人离不开"。看几个信号：用户是否自发持续使用、他们现在用什么土办法解决问题（有土办法说明需求真实）、会不会主动推荐给别人。

怎么弄清楚的：读了《Crossing the Chasm》和《Do Things That Don't Scale》——创新从早期采用者开始，不是大众。导师也说了：先让 10 个人爱不释手。实践上做了小范围测试，看留存率和自发推荐。

---

五、UX 和产品质量冲突时怎么平衡？

大多数冲突有第三条路，不是非此即彼。判断框架：可逆的决定快速做（后面能改）、不可逆的多花时间（架构决策、数据库变更）。实在要权衡时看影响面——影响所有人的 > 影响少数人的。有时候直接看数据比争论有用。

怎么弄清楚的：《Inspired》的核心观点是好的产品经理不该让团队二选一。Bezos 的"单向门 vs 双向门"框架很实用。实践上有次接口设计争论，去看了眼数据库实际数据量，结论就清楚了——数据比观点有用。

---

六个阶段的"做中学"

需求 — 假设用户要推荐功能，调研发现要的是理解内容。调研从没让你意外，就是在找确认不是找真相。（Pressman《Software Engineering》）

设计 — 1:1 数据是否拆表，看变更频率和生命周期是否独立，不是看是不是一对一。教材教 1:N 拆表，实践里 1:1 也要看。

实现 — 并发模型选线程还是进程，看任务在等 I/O 还是等 CPU。Windows 上 fork 不可用，OS 课的知识到这才真懂。

测试 — 单元测试 mock 不出来的 bug 才是真 bug。外部服务返回格式不可控，集成测试要覆盖真实异常 case，mock 是你想象的假数据。

发布 — 代码能 git revert，数据库迁移回滚要恢复整库。迁移文件必须有验证过的 downgrade，迁移前必备份。

维护 — 技术债不会自己消失，关键是让它可见。加 TODO 标记、每轮迭代留时间还债。排查 bug 花 45 分钟理解代码、5 分钟修，每次多花 5 分钟记一笔能帮后来人。

---

个人 / 结对 / 团队

个人开发学会定期问自己"做这个对用户有没有用"，没人提醒容易在一个细节上钻太久。

结对时 Navigator 的价值不在 review 代码，在看 Driver 没注意到的盲区——Driver 想"怎么写"，Navigator 想"挂了怎么办"。

团队联调最大的成本是认知对齐。后来定了规矩：接口设计时先写真实响应示例，两边看着同一个东西确认再动手，比用文字描述猜对方理解高效得多。