[2022北航软工第一次作业] 读《构建之法》感想及工具调研
阅读《构建之法》遇到的问题
1. 关于单元测试
在《》中提到在写一个模块之前先写单元测试，而且要达到代码覆盖率100%。但是实际开发的过程中，我们并不只是开发在命令行上运行的程序。比如我们想要编写一个绘图软件，我们画一个长方形出来，在代码中会创建一个长方体类的对象。假设这个类可以自己画自己，可以在鼠标选中他的时候显示周围的八个提示点。那么这样的功能我们应该如何使用单元测试保证100%的覆盖率呢。
另外，我认为“测试”最难搞的是边界条件，而不是代码覆盖率。比如一个二分查找就有奇数个元素、偶数个元素、要找的元素不存在但位于中间、要找的元素比最小的更/比最大的更大、要找的元素是第一个/最后一个。我认为这种边界数据是最难构造也是最容易出错误的，应该如何自动的将这些条件都测试到呢？
2. 关于分工
不同的团队软件开发的方法都有一个共同点：分工。那么应该如何保证负责不同工作的依赖以及同步工作呢？比如说在敏捷流程中，后端数据库部分的“冲刺”总时长小于后端算法的总时长，那么负责数据库部分的队员在冲刺完成之后的这块空闲时间不久浪费了吗？
《构建之法（第三版）》第142页中说：
各个阶段之间会有缓冲区，团队中各个功能组的进度是各有区别的，不必强求一律，但是各个功能组的节奏应该逐渐统一，这样才能处理好团队间的依赖关系，提高整个团队的开发效率。
然而我认为这一段仍然没有对这一问题做出回答，劳动时间的浪费依然存在。
3. 关于杀手功能
《构建之法》第164页中说：
要把用户从竞争对手那里吸引过来，团队自己的产品要有一个差异化的焦点，在这个焦点上，我们的团队能做得比别人好10倍，高一个数量级。这种功能又叫杀手功能。
既然如此的话，问题的关键就在于寻找焦点。这听上去是非常玄学的一个问题，仿佛是在相对论还没有出现的时候说“我们要找到能突破牛顿力学的方法”。
以共享单车为例，为什么在最开始的时候只有小黄车的创始人想到了这一“焦点”呢？难道是因为他运用了什么科学有效的分析方法吗？如果是的话为什么其他公司没有分析出来呢？
4. 关于设计文档与代码
以常用的UML图为 例。我们撰写设计文档的时候，需要具体到类都有哪些方法，然后在设计交互的时候会用到这些方法。那么当编写代码时，我们只能实现这些方法而不能写额外的方法吗？
比如说有一个方法最好由三个子方法组成。而这是在撰写设计文档阶段无法考虑到的。如果我们严格按照文档，则代码会变得复杂冗长；但如果不按照设计文档，则会使得最终的代码与文档有许多出入，造成要其他人读懂代码就必须要读设计文档和代码注释，以及测试人员无法提前得到子方法的信息，也就无法对每个子方法进行测试。
在敏捷开发中，测试大多是由代码编写者自己完成的，所以上述问题还能够解决。但如果是像航空航天等重大工程项目，设计、测试、开发严格分离的情况该如何呢？要在设计阶段就考虑到每个方法具体怎么实现吗？
5. 初创团队以怎样的思路规范自己的源代码管理
《构建之法》11.6中提到了0-11共12个实践中对源代码管理的需求。而在实践过程中将会有更多场景提出别的需求。
一个初创团队在项目经验不足的情况下，肯定没有办法一次性把这些问题全部解决掉，那么应该遵循着怎样的思路逐步完善团队的源代码管理呢？
调研源代码版本管理软件
-
Github
- Github主打开源，由Github公司负责运营。其中有大量的开源库，可以很方便的找到我们需要的资料
- Github多人协作流程：队员git clone当前的项目，新建一个分支并在本地完成开发，然后和主仓库的分支合并，通过Pull Request这一功能请求将已经合并好的分支提交到主仓库中
-
Gitlab
- Gitlab既有所属公司直接负责运营的服务器，也可以向其公司购买Gitlab服务，将Gitlab运行在自己的服务器上。这样保证了数据都存储在自己控制的服务器中，对于需要保密的项目更加可靠。
- Gitlab的多人协作流程与Github基本相同，但是由于并不主打“开源”，“社区协作开发”，所以分支的合并没有“Pull Request这样的功能，而是由master分支的管理者手动进行合并。
-
Gitee
- Gitee是中国国内最大的Git版本管理仓库，Github的核心功能GItee都有。同时，Gitee对于小团队更加友好，免费支持5人及以下的团队进行研发协作。由于是国内软件，Gitee也支持微信/钉钉通知，使用起来更加方便。
CI/CD工具使用感受
-
-
我学习了Github Actions服务的使用方法。凡事从简单做起，所以我随手写了一个斐波那契数列的计算程序，看看Github Actions能为我做到什么。
Github Actions的使用逻辑
- 学习之后我了解到，CI/CD的使用逻辑是：服务提供商在服务器中提供虚拟机，我们通过配置文件控制这个虚拟机执行什么样的操作、何时执行这些操作。
- 比如说，我们可以设置”当master分支推送到仓库时，使用gcc编译项目，然后执行”，可以通过服务桑提供的工具查看项目执行的结果（如命令行输出），以检查项目是否正确的执行了。
特性分析
- Github Actions的使用场景很广泛。
- 比如在远程的服务器端部署前端/后端时，我们可以设置这样的逻辑：每次推送新的commit，就通过ssh链接服务器，让服务器把新的代码pull下来，在服务器上编译部署。
- 这样就能够实现网页的全自动的更新，不需要每一次都手动pull、部署。
- 该工具的核心逻辑就是：提供一个虚拟机，你可以在特定情况下，任意的控制这台虚拟机做出既定的操作。
Gitlab-CI与Github Actions对比
- Gitlab-CI需要自己配置脚本的运行环境，比如自己的服务器或者本地计算机进行连接。
- 这样做的好处是可以自由的配置脚本运行环境，以及可以升级服务器以获得更快的运算速度。
- 而GIthub Actions会由Github公司提供一个已经配置好常见环境的虚拟机，可以执行大部分常用指令。
- 如果我们只需要执行如”ssh连接服务器、控制服务器pull新的分支并编译部署“这种不需要很高性能的语句，那么Gitlab Actions会是更好的选择。
- 另外，Gitlab-CI的runner是受管理员控制的，因此可以放心的把密钥等信息放在上面。Github Actions运行在Github公司的虚拟机当中，不能存放保密信息。