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

项目	内容
这个作业属于哪个课程	2025年春季软件工程
这个作业的要求在哪里	[I.1] 个人作业：阅读和提问
我在这个课程的目标是	在实践中熟悉软件工程的各个环节，提高合作能力与编程素养
这个作业在哪个具体方面帮助我实现目标	形成对于软件工程的基本认识，理解辨析基本概念

1 单元测试中高覆盖率是否有必要性

P27 中存在表述：

要注意：100%代码覆盖率并不等同于100%正确性！

既然代码覆盖率达到了 100% 仍然无法确保正确性，那么仅仅单元测试无法确保我们代码的质量，必须加入其他测试方法来保证测试效果。

如果一份代码通过了详尽的单元测试仍然有可能会出问题，那么似乎可以不在单元测试中投入大量精力，而是在后续的测试中一并处理bug。我们在项目实际开发时应该花费比较多的时间保持非常高的覆盖率，还是只用简单单元测试保证代码基本可用？

2 结对编程为什么可以提升开发效率

P85 中有相关解释:

在结对编程中，因为有随时的复审和交流，程序各方面的质量取决于一对程序员中各方面水平较高的那一位。这样，程序中的错误就会少得多，程序的初始质量会高很多，这样会省下很多以后修改、测试的时间。

参考书中的描述，结对编程通过随时复审来减少程序错误，从而减少后期修 bug 的时间。但即使用了结对编程，仍然需要通过一系列的测试程序来确保代码质量，并且仍然有bug需要解决。在这一套流程中，bug的修复从经验上来看并不会花费太多时间（如果不进行大规模重构的话）。但是结对开发时两人使用同一台电脑，代码编写的效率就打了折扣。
而且，刚刚开始结对的两人需要互相磨合，因此结对初期效率是低下的。由于人事变动或者项目需要，原有的搭档可能被拆散，而新的结对又要重新磨合。因此我认为结对编程对于环境的变化的适应性不如两人分工编程，这也进一步限制了结对的效率。

查阅资料后，发现结对开发效率明显优于单人开发，但往往低于单人开发效率的两倍。这说明结对是有效的，但没有解释为何结对相对传统的分工有效率优势。

3 如何提高我们对于项目时间估计的能力

P181 中给出了时间估计的经验公式：

软件工程师在长期的实践中，摸索出一套经验公式：实际时间花费主要取决于两个因素—对某件事的估计时间X,以及他做过类似开发工作的次数N。
Y=X±X÷N //注：Y是实际时间花费。中间的±表示加上或减去。
例如软件学院刚毕业的学生果冻估计某网站的用户管理模块需要3天，但是果冻从来没有做过，那么这件事情实际花费的时间有两种可能：
Y=3±(3÷0)

但对于我们来说，在开发软件工程课程的项目时中很有可能并没有类似的开发经历，因此无法应用书中提到的公式。我们在实现自己的项目时需要适当的时间估计，避免估时过短影响后续项目开展，或估时过长导致资源浪费。

在查阅资料时，我了解到可以通过将任务分解为更小的粒度来降低估测的偏差；还可以通过PERT方法等方式通过最乐观时间、最可能时间、最悲观时间来给出估计时间。为了避免错误估计对项目进度的影响，对于我们来说是否有更加合适的方式来为估计提供客观依据？

4 如何理解敏捷流程中的“敏捷”

P114:

敏捷开发的原则是：
1.尽早并持续地交付有价值的软件以满足顾客需求
2.敏捷流程欢迎需求的变化，并利用这种变化来提高用户的竞争优势
3.经常发布可用的软件，发布间隔可以从几周到几个月，能短则短
4.业务人员和开发人员在项目开发过程中应该每天共同工作
5.以有进取心的人为项目核心，充分支持信任他们
6.无论团队内外，面对面的交流始终是最有效的沟通方式
7.可用的软件是衡量项目进展的主要指标
8.敏捷流程应能保持可持续的发展。领导、团队和用户应该能按照目前的步调持续合作下去
9.只有不断关注技术和设计，才能越来越敏捷
10.保持简明—尽可能简化工作量的技艺—极为重要
11.只有能自我管理的团队才能创造优秀的架构、需求和设计
12.时时总结如何提高团队效率，并付诸行动

P128:

用户辛辛苦苦写的微博丢了，这属于很严重的数据丢失问题。如果这是一个实际的股票交易系统，用户能容忍这个系统有时候丢失几笔交易么?如果这是一个航天项目，开发团队希望航天员突然从太空报告氧气泄漏的重大问题么?我们需要敏捷(Agile)的开发流程，但是不需要匆忙(Rushed)或忙乱(Chaotic)的开发流程。

在实际情况下，有许多号称敏捷的项目好像也敏捷不到哪里去。要记住，有许多最佳实践在各种开发方式下都在使用，所以各种开发方式并不是井水不犯河水、老死不相往来的那种关系。

书中给出了关于敏捷开发的的原则。敏捷流程适应变化的需求和增量开发，可以提高团队的效率。

但是，将“敏捷”简单的认识为“快”是不合适的。与传统的瀑布模型相比，敏捷流程做到了持续交付、快速反馈，这提高了软件开发时的灵活性。因此，敏捷还包含灵活适应等含义，因此相比传统方法也实现了效率上的提高。但书中也提到“许多号称敏捷的项目好像也敏捷不到哪里去”，敏捷流程可能并不敏捷。是否有一种更全面的方式来认识敏捷流程中的“敏捷”？

5 PM 的工作存在显著不同，如何衡量工作量

P193:

随着软件复杂度的提高，用户需求的多样化，市场竞争的日益激烈，光有程序员和销售人员是不够的。销售人员当然可以把顾客的需求直接告诉开发人员，但是开发人员往往听不懂。我们需要专人来把市场/销售人员那一套MBA的套路语言翻译成程序员能懂的规格说明书(Spec)。也就是说，我们需要专门的人才来做下面的事，而这些事往往是程序员不愿意花时间去做的：
1. 和客户交谈，组织用户调查，发现用户需求
2.了解和比较竞争对手的产品
2. 怎么让软件变得可用(Usable)、有用(Useful)
4.怎么改进团队的流程

P194:

PM做开发和测试之外的所有事情。

书中认为 PM 的职责是多样的，不仅要与技术人员打交道，还要对接商业与客户。这样，在我们的项目中，PM的工作与其他成员的开发任务存在明显区别。

在工业生产中，可以使用一套专门的标准来评估PM的工作量。但在我们的团队作业中，PM的工作量却需要与开发/测试同学的工作量进行对比。以往按照代码行数确定工作量的方式不再适用，使用任务时间作为参照也不太合理（劳动密集的工作对于项目的意义可能不如技术密集的工作）。是否有一个客观的方式来衡量PM的工作量，使得小组内的工作量分配更加合理？