2023软工第一次作业-阅读和调研

项目	内容
这个作业属于哪个课程	2023年北航敏捷软件工程
这个作业的要求在哪里	个人作业-阅读和提问
我在这个课程的目标是	学习软件工程的理论，亲自实践参与软件工程开发全流程
这个作业在哪个具体方面帮助我实现目标	初步了解软件工程理论

阅读提问

问题一 单元测试由什么人来写？

单元测试必须由最熟悉代码的人（程序的作者）来写。
代码的作者最了解代码的目的、特点和实现的局部性。所以，写单元测试没有比作者更适合的人选了。

书上第25页要求必须由负责实现的人完成单元测试。但根据我的经验，在完成代码的过程中，程序员会不断重复自己的思路来保证代码间的逻辑正确性。在这一过程中，程序员可能会不断受到自己思路的影响，形成思维定式。这样在进行测试，尤其是编写测试样例时就可能会受此影响产生局限性，变成了“当局者迷”。
在我看来，单元测试在多方的协同下进行更为合适。代码作者可以做一些随机生成数据的测试，以保证代码在大多数的运行情况下是正确的。然后由负责测试的人根据其在测试方面的经验，给出一些特殊样例，比如某种条件下出现除数为0的样例来保证测试用例的全覆盖。
另外，在4.5.4 如何结对编程中，也提到了领航员可以设计TDD的测试样例。此时驾驶员（代码作者）还没有完成实际代码的编写，领航员才是单元测试的书写者。

问题二 结对编程的效率问题

领航员：审阅驾驶员的文档；监督驾驶员对编码等开发流程的执行；考虑单元测试的覆盖率；思考是否需要和如何重构；帮助驾驶员解决具体的实际问题。

书上第87页讲述了结对编程时的驾驶员和领航员的工作。其中，领航员起到了监督、指导的作用。诚然，在驾驶员遇到实际问题时，比如算法的实现不熟悉，可以彼此讨论解决。但在监督过程中，二者对于某一部分的实现有不同的想法。如果领航员在过程中经常提问打断，会极大的影响驾驶员的书写效率。如果不打断等到写完后再统一讨论，又没有起到监督的作用（和两个人平行开发然后再互换意见没有区别）。因此，在领航员的监督过程中，如何才能使得结对编程的效率最大化，既能及时发现问题，又能避免频繁提问导致思维不连贯、效率低下的问题？

问题三 投资需求的优先级

书中在第176页用函数曲线图展示了用户满意度和投资力度/产品质量的关系，并提到将三种类型的关系放到一起后就能看出应该投资哪种类型的需求。那么，放到一起后的评判依据应该是什么？对于基本功能，应该达到一个阈值后再考虑对其他功能的投资。比如书中的英汉词典样例，只有单词短语的释义达到一定准确度后，才会有用户使用，值得进行其他功能的投资。这些因素应该如何考虑，并在图中呈现出来？

问题四 “小强扫荡”的收益

书上在第294页讲述了“小强扫荡”的活动，这种方法在现实应用中是否有很大的收益？按照书中描述，这种做法可以找到很多小强，让开发人员忙一阵子。但实际上，每个测试人员都有不同的分工，测试也有不同的倾向性。如果让所有人都测试同一类型的bug，理论上效率应该低于正常的效率（负责其他测试的人熟悉度会低一些），否则按照bug类型不断开展扫荡就能最快的消除所有bug了。

问题五 “全栈”和“精通”的选择

一个工程师的确可以兼顾其他角色的工作，如果取代所有角色的工作，就是一个“全栈工程师”，这样的能力值得钦佩，但是实际效果呢？你见过一个乐团的优秀小提琴手在交响乐演出的时候在台上跑来跑去，搞定其他所有乐器的么？

根据书上324页的描述，作者似乎并不倾向于让一个人变成全栈工程师，而是精通并专注于一项技术。但现在只精通于一项技术已经不足以满足现实的需求，开发过程中时常会遇到单一领域无法解决的问题，需要全栈的帮助。因此，在团队中可能需要一部分成员在精通于自己负责的技术同时，一定程度上的兼顾（不是完全替代）其他角色的工作，使得各个模块可以串联起来。