软工第二次阅读作业
| 项目 | 内容 |
|---|---|
| 这个作业属于哪个课程 | 2021春季软件工程（罗杰 任健） |
| 这个作业的要求在哪里 | 个人阅读作业#2 |
| 我在这个课程的目标是 | 完整的体验一次软件开发，和同学合作做出一个有用户的软件项目；在开发过程中学习工程化方法；在体验中明确自己的想法与目标 |
| 这个作业在哪个具体方面帮助我实现目标 | 阅读《构建之法》，系统性的初窥软件工程；调研并使用持续集成和持续部署工具，为后面的软工学习和训练打下基础 |
阅读提问——阅读《构建之法》之后
1. 单元测试谁来写？
单元测试必须由最熟悉代码的人（程序的作者）来写。
代码的作者最了解代码的目的、特点和实现的局限性。所以，写单元测试没有比作者更适合的人选了。
——2.1.2 好的单元测试的标准
作者认为单元测试最好是由程序作者来写。但是我认为仅由代码作者来写单元测试实在是存在很大的局限性。首先需要明确的是，单元测试是为了让自己负责的模块功能定义尽量明确，以及模块的质量能够得到稳定的、量化的保证。而往往程序的作者在构思和编写代码时就已经定型了大致的流程和细节，那么无论是在编写程序还是在构建单元测试时，往往会有高度一致的思路，换句话说就是如果程序作者在最初未考虑周全的地方，那么往往会一直受限无法弥补之前未思考周全的地方。就好比一个厨师按自己的想法做了一道菜，然后自己尝试感觉很不错，但是给顾客或者同事品尝时，虽大体口味一致，但难为会有一定的辅料是厨师为考虑到的。因此，除非是程序作者要求调用模块的人只能按照自己的思路调用之外，最好是不仅要程序的作者来编写单元测试，更需要团队中和此作者开发相近的其他人来辅助编写单元测试，这样或许才能最大程度的保障达到单元测试的目的。
2. 结对编程中角色互换
驾驶员和领航员不断轮换角色，不要连续工作超过一个小时，每工作一小时休息15分钟。领航员要控制时间。
——4.5.4 如何结对编程
按照作者的说话，驾驶员和领航员之间的角色应该进行频繁的轮换，但是我认为如此频繁的轮换是否会影响正常的程序编写的进行？驾驶员主要进行编码和单元测试，而领航员主要进行审阅文档，设计测试用例等相关事项。从我自身而言，一个小时或许是编码刚刚上头的时候，也是代码编写最顺手的时候，此时如果中断并且更换职责和任务，那么思路将会被打断，且再回来继续进行编码时会需要时间来重新"找感觉"，会造成一定程度上的不必要的损失。因此，对于驾驶员和领航员而言，驾驶员在编码上刚刚渐入佳境就被打断，职责和领航员进行交换，对于驾驶员而言，编码的感觉被打断，等一段时间之后在上手编程就又需要时间来缓冲，有一定的时间损耗。其次，二人的编码习惯会有一点的差异，如此频繁的交换编程，或许会造成代码在细节上产生差异，反而会产生不好的结果。
3. 推动信息共享与沟通
第一个原则，就是所有信息都保留并公开，讨论要包括所有涉及的角色，决定要公开并告知所有人。当人，对牵涉到的技术机密、安全性等信息要采取必要的保护措施。
——7.2.1 推动信息共享与沟通、
作者在此部分提出在项目开发时所有的信息都要保留下来，甚至是自己修改的低级bug也要保留下来，以便共享和学习所有的经验。我的问题就是真的有必要去保留所有信息吗？首先，一个项目，多个开发人员，多次开发和修改必定会产生极为大量的信息，不可否认的是信息必定会有很多重要信息，但是同样也会包含大量的冗余的信息，例如，我今天修改了这个“笔误”，他明天也修改了一个“笔误”，这些信息的存在是否会有使信息冗余使总结复盘工作量无意义的增加的嫌疑呢？其次，文档、交流、决定等基本就用于团队的不断迭代开发查阅上，团队项目总结上，或许也需要给用户一份实时的总结文档，那么我们是否应该对所有的未经过处理的记录进行一系列的总结，以便更轻易和系统来分析和总结项目，而不是去翻阅以往所有的记录，这是否存在浪费时间的嫌疑？然后，信息的共享和沟通，也会用于给后来的同事学习经验，相比于一份完整不加以处理的信息，经过总结和归纳的文档或者说信息是否会更好，以及是否会带来更高的效率呢？所以我觉得或许经过分析和总结删除掉同类型和无意义的信息后的文档或许或是一个更好的选择。
4. 典型用户
我们宁可从小部分人出发，要非常明确地定义谁是我们的用户。
——10.1.3 怎样定义典型用户
我赞成作者所说的软件不是为所有人服务的，那么考虑用户群体就是一个非常重要的问题。一款软件，一款带有商业和盈利性质的软件，从商业的角度来看，当然是用户群体处于一个较广阔的范围最好，以保证最大的收益。即使是一款针对特定用户群体的软件，用户群体有一定的范围，但是我认为也不至于到作者所说的小部分人的程度吧。毕竟软件的评价包括这款软件的商业价值，从小部分人出发而瞄准的用户群体真的能够带来较大的商业价值吗？
5. 赢者通吃
这个游戏规定第一名得到全部的分数，第二名（不管多接近）到倒数第二名都是0分，最后一名还要倒扣分。软件行业就是一个赢者通吃的环境，最后一名还要把自己的身家倒贴进去。
——16.2 创新的时机
虽然在软件这个行业竞争激烈而且残酷，但是真的已经是到了一种赢者通吃的环境下了么？中小型创业者几乎不可能出现通吃某个巨头公司在相同方向上的产业吧，亦或者说赢者通吃，巨头公司能够扫荡某一方向上的所有中小创业公司，那么中小型创业公司出路又在哪里？
调研源代码版本管理软件
GitHub / GitLab / Bitbucket相同点：
- 均基于git进行代码管理；
- 均能够fork和pull request；
- 具有issue追踪的功能；
- 能够编写wiki文档；
- 提供功能丰富的API；
- 支持代码片段分享；
不同点在于：
| GitHub | GitLab | Bitbucket | |
|---|---|---|---|
| 版本控制系统 | 仅有git | 仅有git | Mercurial和git |
| 免费情况 | Free Plans允许托管无限的公有代码仓库；但是项目不能超过1GB和单个文件不能超过100MB。 | cloud-hosted允许无限数量用户在公共和私有项目上合作；但是每个存储库有10GB的限制。 | 无限制的所有仓库个数；无限制的磁盘空间；Small teams plan允许5个成员加入。 |
| 私有性 | 开源，支持搭建私有的gitlab服务，确保数据安全；私有性更好。 | ||
| 适用对象 | 均适用 | 均适用，尤其对于注重代码私密性的企业和个人适用 | 一般用于小型团队；依赖Bitbucket其他项目的大型团队也适用 |
调研持续集成/部署工具
Gitlab CI尝试
本次调研选取oopre2第二次作业为测试代码，仓库地址，先学习Maven相关并完成配置，并用Maven重构此次作业，且依据Junit构建测试样例。
根据作业中所给的yml样例，编写yml文件，并上传至对应gitlab仓库，并运行gitlab-CI进行在线编译，在线运行，在线测试。
ps：在GitLab上尝试CI时，自作主张使用自己私下的gitLab账号，然后运行CI总是报错，试错了好久，最后和同学交流发现他们直接用的原oo作业仓库，然后我换了仓库后也直接秒过，我……我直呼好家伙！
Github Action
使用与上文相同的源程序，并根据相关文档编写.github/workflows/test.yml文件，上传至github仓库尝试使用github action，得到如下图所示结果。
CI/CD分析
CI/CD
- CI/CD可以帮助开发人员更加频繁地将代码更改合并到共享分支或“主干”中。
- CI/CD能够通过自动化测试发现新代码和现有代码的冲突，使其快速得到修复；
- CI/CD的关联步骤有助于降低应用的部署风险，更便于以小件的方式发布对应用的修改。
Gitlab CI特点
- 只要在项目仓库的根目录添加.gitlab-ci.yml文件，并且配置了Runner，那么每一次merge或者push都会触发CI pipeline；
- 跨平台支持，只要支持go语言的平台均可以在上面进行CI；
- 多语言支持，构建时是通过脚本触发，因此基本支持所有的语言；
- Pipeline，可以通过不同的阶段形成工作流。
Github Action特点
- 支持多平台，虚拟机及容器运行环境，支持多语言和框架，支持矩阵构建，实现多平台多环境并行兼容测试，提高软件测试集成效率；
- GitHub Action 针对公开仓库及自主托管的 runner 是免费的，针对其他 GitHub 规格有免费的存储及任务运行时长，超额后按量收费；
- GitHub Action 使用 YAML 脚本编写，它们可以像代码片段一样被编辑和复用；
Gitlab CI和Github Action对比
其实通过自己简单的编写样例测试体验，并不能深刻的感受到二者的差异，同时此篇文章已经详细的将二者进行了对比，因此此处引用来作为该问题的解答。
参考文章
《构建之法——现代软件工程》邹欣著，人民邮电出版社，第三版
