[I.1] 个人作业：阅读和提问
| 项目 | 内容 |
|---|---|
| 这个作业属于哪个课程 | 2025年春季软件工程（罗杰、任健） (北京航空航天大学 - 计算机学院) |
| 这个作业的要求在哪里 | [I.1] 个人作业：阅读和提问 |
| 我在这个课程的目标是 | 学习软件工程的基本知识，了解软件开发流程。在实践中，掌握与团队配合开发，团队管理等方面有关的知识。 |
| 这个作业在哪个具体方面帮助我实现目标 | 通过阅读相关书籍，学习并思考软件开发流程中的各个部分，对软件工程有了一个基本的印象。 |
阅读与提问
1. 结对编程中两人水平不同是否会导致地位不等？
4.5.4 如何结对编程 中提到：
只有水平上的差距，没有级别上的差异。两人结对，尽管可能大家的级别资历不同，但不管在分析、设计或编码上，双方都拥有平等的决策权利。
如果结对编程的两人，在某个方面的水平差异较大，那么在编码相关内容的时候，是否会出现这样的情况：水平较高的一方，在领航的时候，总能指出各种问题；而水平较低的一方，在领航的时候，难以提出建设性的意见；于是分析、设计或编码的相关决策权利倾向于水平较高的一方。
同时，另一方陷入7.2.4 各司其职，对项目共同负责部分提到的，类似下棋中对局者被“旁观者”的意见所左右类似的情景。只不过这里两人的地位正好反转，对局者拿不定主意，旁观者反而成为有责任的一方。这样，虽然达到了前文提到的：“程序各方面的质量取决于一对程序员中各方面水平较高的那一位。”，但却做不到结对编程两人共同承担代码的功能，而且出现水平较高的一方在编程过程中付出太多精力的问题。
上面假设的情况是否会在结对编程中发生？同时如果两个人水平类似，但是对同一问题，两个人分别熟悉两种不同的实现方式，在结对编程中，“平等的决策权利”是否会导致更加复杂、激烈的争执？而选定某个实现方式后，出现上述的不平等问题？
2. 敏捷开发不需要文档吗？
6.2 敏捷流程的问题和解法 中提到：
肯·施瓦伯（KenSchwaber）说：
我还建议，把所有开发过程的附加物件，像设计文档，都扔掉...... SCRUM依赖于团队成员面对面、高容量的交流和合作；每人独立的小隔间、没有必要的文档都增加了疏离和误解的可能性”。
如果项目的所有人都坐在一起，连工位之间的矮墙都没有，那的确很爽，但是在很多公司中那是不可能的，有些团队成员甚至在不同的时区工作，怎么办？他们就不能敏捷了？这时候我们的确需要文档和其他辅助手段来沟通。
该章中的其他部分也总将完善的文档与敏捷开发流程的做法做对比。这难道意味着敏捷开发不需要完善的文档吗？
而在一些定义[1]中：
我国的计算机保护条例[2]中也认为：
第二条 本条例所称计算机软件(以下简称软件)，是指计算机程序及其有关文档。
我可以理解敏捷开发流程中，成员高质量的交流是可以替代掉文档层面的交流的。但是软件总有其维护的需求，没有文档不会导致维护成本极大提高。同时在不得不修改/扩展一段时间前的代码时，由于不清晰的文档记录，错误的调用了某些接口，从而造成更多的bug吗？
所以应该如何看待敏捷开发过程中的“文档”这一内容？是应该对程序写最基本的文档记录，还是直接放弃，全力开发？
3. 敏捷开发中剩余时间会不会被“猜不准”的计划影响？
6.2 敏捷流程的问题和解法 中提到：
另一个改进是，要在每一个任务中记载我们完成这个任务还需要多少时间。已经花了多少时间虽然重要，但那不是关键（那是沉没成本），关键是要看我们离最后目标有多远。
而 8.6 计划和估计 中又对估计做了许多分析：
在敏捷开发的项目中，团队一般不过分强调“估计”的价值，因为它就是一个“猜”字。“猜得准”不是团队的目标。团队的目标是把软件写出来，让用户满意。如果猜错了，没关系，微调项目进度即可，不要为了“猜得准”而不前；或者为了让当初的猜测看起来靠谱而不如实报告进度。
假如我们的项目计划是一个“猜”出来的估计值，那么距离目标的时间不也会成为一个不准的估计值吗？此时日常的进度报告可能就会流于形式。又该如何避免前文中提到的:
约翰·巴克斯在FORTRAN项目启动后，他的上司会定期询问完成日期，他总是给出同样的答复：“6个月。”但实际上，项目一共花了将近3年的时间
这种问题呢？
4. 修Bug门槛越来越高还是Bug清零？
15.1 从代码完成到发布 中提到了几种招数：
项目接近尾声时，要确保门槛越来越高。今天的“Must”（超过门槛的修复）必须比昨天及以前的“No”严重性要高，这样才能不断提高系统的稳定性。
提升Bugbar是放走一些无伤大雅的Bug，换取项目能如期完成。其指导思想是抓大放小，既然没法全解决，就集中精力解决最重要的Bug。避免频繁地到处改动代码而引入新的Bug，是以谓之“稳定”。
又提到15.1.4 招数：ZBB:
团队在Bug数量上上下下的过程中，要注意消灭老的问题，让老的Bug的数量到0，以防止一些问题拖而未决，有些Bug长期拖而未决，有可能掩盖了深层次的设计问题，要尽早把这些问题暴露出来，一个招数是，划定一个时间期限，一定要解决在此之前发现的Bug。
这两种做法是矛盾的吗？抓大放小会不会出现小Bug长期不解决，因而累计出现的严重的Bug？还是说这是对于软件开发不同阶段，不同时期所选用的不同方法？
5. 无法运行到的分支应该如何处理？
4.4代码复审 中提到:
问：有些错误处理的分支我不能执行到怎么办？
答：如果作者都不能让程序执行到那些分支，那谁能保证那些错误处理的正确性呢？
2.1.2 好的单元测试的标准 中也提到:
单元测试应覆盖所测单元的所有代码路径，包括错误处理路径。为了保证代码覆盖率，单元测试必须测试公开的和私有的函数/方法。
在一些防御性编程或是一些代码要求中，写代码中会额外地添加一些无法到达的错误处理的分支，以应对未来可能的变更或是应对某些代码检查（java、C#就有这样的强制要求）。这样看来100%的覆盖率可能是无法实现的。
虽然我找不到一些企业的具体要求，但是就一些博客[3]，知乎问答[4]而言，100%的覆盖率也不是必须的。就我个人理解，我觉得代码覆盖率的要求应该还是要看具体情况分析，如果是涉及安全的代码，可能100%的覆盖率还不够，甚至需要多个分支的组合的覆盖要求。而普通的代码可以适度放宽要求，以满足一些开发周期的要求。这样想对吗？
浙公网安备 33010602011771号