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

项目	内容
这个作业属于哪个课程	2026年春季软件工程（北航计算机学院）
这个作业的要求在哪里	[I.1] 个人作业：阅读和提问
我在这个课程的目标是	锻炼团队协作开发能力；学习一套完整的项目开发范式；学习完成一个复杂性较高内容较多的完整项目
这个作业在哪个具体方面帮助我实现目标	提高独立思考能力，锻炼批判思维，同时学习一些软件开发过程中的设计理念

问题一

提问

既然代码覆盖率作为衡量指标具有局限性，在软件工程的知识体系中，是否存在一种更强的指标来补充单纯的代码覆盖率？

章节与上下文

我阅读了第2章 个人技术和流程，重点关注了2.1.2 好的单元测试的标准以及代码覆盖率的相关讨论（第27-28页）。
书中明确指出：“100%的代码覆盖率并不等于100%的正确性”，并举了 DoFoo 和 DoBar 的伪代码例子（第27页），说明即使所有代码行都执行了，如果逻辑判断条件（如 func1() 或 c 的取值）没有覆盖到特定组合，依然无法发现逻辑漏洞。

事例

在大二的课程学习中，课程要求我们进行单元测试并达到一定的覆盖率，而事实上即使测试覆盖到的代码部分也在后续的测评中被测出了问题。

提问原因

书中虽然指出了覆盖率的缺陷，但在后续的 PSP（第35页）和 CI/CD 流程中，覆盖率依然是自动化流水线中唯一的量化门槛。

问题二

提问

在提倡敏捷流程的团队中，如何界定“必要的文档”与“繁文缛节”？“敏捷”二字在实际执行中，是否经常被开发人员作为“不写文档”、“不设计架构”直接写代码的挡箭牌，从而导致项目后期维护成本剧增？

章节与上下文

我看了第6章 敏捷流程，特别是6.1 敏捷的流程简介（第115页）以及关于敏捷宣言的讨论。书中提到了敏捷开发强调“可用的软件胜过完备的文档”（Working software over comprehensive documentation），并介绍了Scrum、Sprint backlog等概念。

事例

Stack Overflow上关于“Technical Debt（技术债务）”的讨论中，很多开发者抱怨因为过分追求Sprint的速度，牺牲了文档和代码规范，导致后期重构极其痛苦。

原因

我的困惑在于敏捷宣言的边界。我想知道在工业界，一个真正成熟的敏捷团队（如微软的团队），究竟会保留哪些“不可或缺”的文档？是否存在一个具体的标准来平衡“敏捷”与“可维护性”？

问题三

提问

PM“不做开发”在学生团队或初创小团队中是否会导致“外行指挥内行”的问题？

章节与上下文

我阅读了第9章 项目经理，特别是9.1 PM 是啥和9.3 PM 做开发和测试之外的所有事情（第191-194页）。
书中明确指出 PM不同于行政领导，也不同于单纯的开发人员。书中提到 PM 的职责包括规范说明书、与用户沟通、由“强梁”变“桥梁”等，甚至引用了微软的观点：PM 是“做开发和测试之外的所有事情”。

事例

在学校部分课程的大作业中，如果团队里有一个人只做 PPT、画原型图、写文档，而不写一行代码，他通常会被其他写代码的同学认为是在“划水”。

原因

我对作者关于PM角色绝对独立性的隐含假设特别是对于小规模团队存在困惑，PM 的专业化分工是否只适用于微软这种巨型企业？对于我们这种5-7人的学生团队，如果一个人完全脱离代码去空谈“流程”和“需求”，往往无法获得开发人员的尊重，也无法准确预估技术难度。书中的 PM 模型是否过于“理想化”或“大厂化”，而缺乏对小型全能型团队的指导意义？

问题四

提问

用户体验是否是可以被量化的工程学？

章节与上下文

我阅读了 第12章 用户体验，特别是12.3 评价标准中关于费茨定律的内容（第272页 / PDF第137页）。

书中列出了一个明确的数学公式：\(T = a + b* log_2(D/W + 1)\)，用来计算用户移动光标到达目标所需的时间。作者用这个公式来解释为什么Windows的“开始”按钮放在左下角是效率最高的（因为目标大小相当于无限大）。同时书中也提到了“认知阻力”这种心理学概念。

事例

我查阅资料发现，很多大厂（如字节跳动、Google）会有专门的 A/B Test 平台，用数据（点击率、留存率）来验证体验，而不是靠公式计算。

提问原因

我的困惑在于部分工程理论的实用性。在现代软件工程体系中，UX 的“工程化”程度到底有多高？工程师在开发阶段，是真的会利用这些认知心理学公式（如费茨定律、希克定律）来预判设计的好坏，还是说这些公式只是事后用来解释“为什么这个设计好”的理论依据？

问题五

提问

关于“先发优势”的否定，是否会误导我们在激烈的同质化竞争中失去先机？

章节与上下文

我阅读了第16章 IT 行业的创新，重点是16.1.4 迷思之四：创新者都是一马当先（第351-352页）。
作者列举了 Apple 的 iPod 并非第一个 MP3，Google 并非第一个搜索引擎，微软 Office 并非第一个办公软件等例子，来论证“先发优势”往往并不存在，甚至可能因为技术不成熟成为“先烈”。书中提到“大部分成功的创新者都不是先行者”。

事例

在移动互联网时代，很多应用是“唯快不破”。例如“吃鸡”游戏（PUBG vs 其他仿品）、共享单车大战。往往是先占领用户心智和市场份额的产品（即便有缺陷）能活下来，后来者很难再有机会。

提问原因

我的困惑是：作者的样本是否具有幸存者偏差？作者列举的都是“后发成功”的巨头（微软、苹果、谷歌），但在当前的应用开发环境下，技术壁垒越来越低，如果我不追求“一马当先”去抢占市场，而是等待技术完美再发布，难道不会直接被动作更快的竞品直接通过运营手段挤死吗？