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

项目	内容
这个作业属于哪个课程	2025年春季软件工程（罗杰、任健）
这个作业的要求在哪里	[I.1] 个人作业：阅读和提问
我在这个课程的目标是	学习软件工程的理论与方法，在实践中提升自身工程能力
这个作业在哪个具体方面帮助我实现目标	了解软件工程中的常见概念与方法

问题一：单元测试由谁来写？

书中提到：

如果忙到连单元测试都没有时间做，那么你也没有时间写好这个功能。

把单元测试的责任和代码作者绑定在一起后，代码作者就能更真切地体会到复杂代码的副作用，因为验证复杂代码的正确性要困难得多。

在面向对象课程中，我体验过使用JUnit为java源程序编写单元测试。但是这些测试可能只帮助我发现了每个单一方法的细节问题，而在多个方法结合在一起时似乎没法起到作用。这揭示了单元测试的固有局限——它更像是显微镜而非望远镜，擅长观察局部细节却难以捕捉系统级交互，其关注点在于验证代码单元在隔离环境下的正确性。

单元测试由代码作者编写，而根据我的个人经验，编写测试用例的时候总会受到先前编码的"惯性思维"影响，在大部分情况下无法发现潜在的逻辑bug。在编写测试时容易陷入"正向路径依赖"，即倾向于验证预设输入对应的预期输出，而对异常分支和边界条件覆盖不足。心理学中的证实偏差（Confirmation Bias）在此体现得尤为明显，开发者会潜意识地构造能证明代码正确的测试用例，而非试图证伪。

面对这样的问题，测试代码的责任应该如何进行合理的划分？

问题二：结对编程能代替Code Review吗？

书中提到：

结对编程让两个人所写的代码不断地处于"复审"的过程，程序员们能够不断地审核，提高设计和编码质量，可以及时发现并解决问题，避免把问题拖到后面的阶段去。

在书中提到结对编程是为了将"Code Review"等良好习惯"推向极限"而产生的一种协作方式。查阅其他资料，维基百科提到，由于导航员实时审查代码，错误可以及早发现；结对编程产生的代码缺陷减少约15%。

但我认为这15%的改进存在明显的边际效应递减。结对双方的认知重叠可能导致"群体盲思"（Groupthink）。当两名开发者采用相同技术栈结对时，容易陷入"模式陷阱"——他们可能共同忽略非典型场景处理，就像两位习惯同步编程的开发者会自然规避异步回调的复杂性。这种现象在2021年剑桥大学的研究中得到验证：结对组在算法题解决中表现出更高的模式趋同性，而独立开发组则呈现更多元的问题解决路径。

从这个角度来看，我认为结对编程是无法代替大团队的Code Review的，因为CR能够引入认知多样性，保障更高层次的的合理性。

问题三：如何"站在用户的角度看问题"？

书中提到：

PM要能理解用户，能站在用户的角度上考虑问题，观察发现用户不善于表达的需求，体察团队成员的言外之意，倾听老板/客户/利益相关人的弦外之音。

"PM当工作需要时能变成完全不懂技术的菜鸟用户"，我认为这是极难做到的。认知心理学上有一个概念叫做"知识的诅咒"（功能固着），它是一种认知偏见，描述了人们在想象不知道已知事物的情况下所面临的困难。

功能固着现象在软件产品设计中体现得尤为明显。当Slack团队新增"频道归档"功能时，工程师默认用户理解归档与删除的区别，结果导致大量用户误操作丢失数据；我成为oo助教之后，虽然我尽力去以"学生视角"来看待问题，但是我还是很难想象到他们为什么会有某些在我看来很奇怪的问题。这种现象揭示了一个残酷现实：专家用户的思维模式与真实用户存在认知鸿沟。神经科学研究显示，当个体掌握某项技能后，其大脑会通过髓鞘化过程固化神经通路，这使得"专家模式"成为不可逆的认知滤镜。

破解这一困局需要建立系统化的共情机制：微软的"轮椅日"要求产品经理体验肢体障碍用户的操作场景；Figma团队每周邀请真实用户参与设计评审；亚马逊著名的"空椅法"在会议中虚拟用户存在。更激进的做法如JetBrains的"Dogfeeding"，强制开发者使用自己开发中的版本处理日常工作。这些实践不是简单的角色扮演，而是通过感官冲击重建认知模式——当工程师亲历自己设计的API需要20次HTTP调用才能完成基础操作时，才会真正理解"开发者体验"的含义。

问题四：技术伦理的薛定谔困境？

书中提到：

正式因为在软件系统开发中起到的重要作用，软件工程师有很大的机会去造福或危害社会，并有能力去促使或影响他人造福或者危害社会。

奥本海默的困境在数字时代愈发凸显：2016年微软Tay聊天机器人被教唆成为种族主义者，2020年Zoom的端到端加密承诺被爆存在技术漏洞。这些案例表明，即便怀着最善意的初衷，技术后果仍可能突破设计者的控制边界。MIT媒体实验室的研究指出，AI系统在部署3个月后产生的社会影响，与初期设计目标的吻合度不足60%。

作为一个软件工程师，在开发产品投入使用之前，即使他的愿景是造福社会，他如何能保证自己的产品不会危害社会？这里的滞后性导致了这种承诺难以实现。

问题五：软件服务要记住用户的选择吗？

书中提到以下两个例子：

国有银行注册账号不能记住语言选择，导致发给外国学者的验证短信始终为中文，带来了不小的困扰。

Windows Live Writer 不能记住用户所选择的字体，导致每次使用都需要在诸多字体中寻找。

作者通过以上两个例子来说明"软件服务始终都要记住用户的选择"，这种观点在我看来是有点绝对的。

用户选择记忆的本质是便利性与自主权的博弈。Netflix的推荐算法在2018年达到78%的内容通过推荐被观看，但同时也导致34%的用户产生"信息倦怠"。这揭示了一个反直觉现象：过度的个性化实际是在剥夺用户的选择权。神经经济学研究显示，当系统推荐准确率超过65%后，用户决策参与感开始下降，最终形成"推荐依赖症"。

破解这一悖论需要建立"可调节的记忆系统"：抖音的"刷新推荐"允许用户重置算法模型；网易云音乐的"发现模式"每周主动推送陌生音乐类型；Notion的模板系统采用"记忆+遗忘"机制，自动归档三个月未使用的自定义模板。我认为，最佳实践是在用户控制面板中提供"记忆强度"滑动条：从"每次都询问"到"完全自动选择"，让用户自主决定系统介入程度。