《构建之法》阅读以及工具调研

《构建之法》阅读以及工具调研

项目	内容
这个作业属于哪个课程	2022年北航敏捷软件工程社区
这个作业的要求在哪里	传送门
我在这个课程的目标是	1. 提升自身在技术硬实力上的竞争力 2.体验规范软件开发流程，积累团队合作经验，提升软实力
这个作业在哪个具体方面帮助我实现目标	督促我快速建立对敏捷开发整个流程的了解，并实践常用 CI/CD 工具的用法。

第一部分：阅读提问

下面我会列出来自己在阅读《构建之法》的过程中想到的问题，有些问题不一定与某具体章节有关。

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

在《构建之法》第二章，对于单元测试，有这样一段描述：

单元测试必须由最熟悉代码的人（程序的作者）来写。

代码的作者最了解代码的目的，特点和实现的局限性。所以，写单元测试没有比作者更适合的人选了。

从我目前的经验和经历来看，假如我作为某个事物（不一定是代码）的作者，自己找自己的错误往往会有一种“我没有问题”的心理暗示，而帮别人做一些检查（也不一定是代码）时，因为自己相对作者来说是一个“傻子”，可能都没有理解他搞这个要做什么，所以更容易去给出一些作者从来没有考虑过的“用例”。“当局者迷，旁观者清”大概是这个道理吧。

最近我在一项工作上面临其他同学的检查，在这个期间我们工作小组共同完成的工作被其他组的同学谨慎检查后提出了几十个问题。我个人的体会是，因为我自己预先在心里给这个事情的前提条件设定了一些“期望”，而这些“期望”并不为其他人所知，所以其他人更能 hack 我。

我认为这种检查，和写单元测试属于一类事情，应该拥有类似的经验教训可以吸取，所以我目前觉得单元测试未必要交完全交给最熟悉代码的人来写。熟悉代码的人，比如作者，尽可能地去覆盖自己现有的路径；其他不太熟悉代码的人，可以在原有的单元测试上做补充工作，这些人由于有一个学习的过程，所以思路不是纯白盒测试，而是“从黑逐渐到白”盒测试，这样容易发现诸如原有代码的路径划分过于“粗糙”的一些问题。

问题二：服务于小部分典型用户的idea是否应该被鼓励/继续下去？

在《构建之法》第十章，有一部分是讲述“如何定义典型用户”。其中有一部分这样说道：

注意：我们的软件不是为所有人而服务的。

问：那这样不就是损失了大量潜在的用户，我们至少得争取一下为所有人服务，如果不行，再回到少部分用户？

答：不妥，我们宁可从小部分用户出发，要非常明确地定义出谁是我们的用户。

首先，我对书中相关部分的讲解是认同的，即我们在分析软件的典型用户的时候，需要毫不含糊地定义出自己的“基本盘”，即我们可以拍板说这些人几乎肯定需要用我们做的软件。否则，我们可能连做这个软件的底气都没有。泛泛地去谈自己软件的用户，只会让自己沉浸在一种虚无的安全感和满足感中，纯粹是在画满足不了的大饼，最后做出来的产品很