2021年软工-个人阅读作业2
| 项目 | 内容 |
|---|---|
| 这个作业属于哪个课程 | 2021春季计算机学院软件工程(罗杰 任健) |
| 这个作业的要求在哪里 | 个人阅读作业#2 |
| 我在这个课程的目标是 | 学习软件开发的工业化流程，锻炼团队合作能力 |
| 这个作业在哪个具体方面帮助我实现目标 | 阅读《构建之法》，了解软件的构建方式；调研基代码版本管理软件和持续集成工具 |
一、阅读提问
1. 单元测试必须要程序作者来写吗？
在读了 2.1.2 中的这句话后
单元测试必须由最熟悉代码的人(程序的作者)来写。
我产生了一个这样的疑问，尽管搜索引擎给出的答案都是要由作者来写，但几乎均是引用自<构建之法>的这段材料。而在自己的测试实践中，由于程序就是自己写的，在编写测试样例时很难跳出自己的思路，容易陷入窠臼。而室友就很容易看出其中的错误。而且如果是测试驱动开发，单元测试先行，我个人赶紧应该是由最熟悉需求的人来写。
2. 完成任务的预估时间如何预估？
在 6.2 中有
另一个改进是,要在每一个任务中记载我们完成这个任务还需要多少时间。
这个时间是基于开发人员的经验而预估。但是像软件开发这样复杂的工程项目，墨菲定律总是能发挥它的作用，总是有超出开发人员预料的因素导致实际开发时间和预估时间的不一致，而且一旦这种因素产生，往往会极大背离开发人员的预估时间，使得预估时间的统筹作用大大减弱。那么这种预估时间应该怎么预估才能使这个预估时间更有效地发挥作用。
3. 满足NABCD模型，是否就意味着是一个好软件？
我们的产品<名称>是为了解决<目标用户>的痛苦,他们需要
,但是现有的产品井没有很好地解决这些需求。我们有独特的办法 ,它能给用户带来好处 ,远远超过竞争对手 .同时,我们有高效率的 方法,能很快地让目标用户知道我们的产品,并进一步传播。
例如迅雷，目标用户有下载需要，因为迅雷在享受其他 BT 软件用户上传提供的速度时，自身却只把上传的速度提供给其他迅雷用户，是迅雷独特的办法，给迅雷用户带来了好处，且竞争对手（其他 BT 软件）因为迅雷而衰落，而且迅雷相对于国外的 BT 软件推广更容易。似乎迅雷满足了 NABCD 模型的所有特点，而且迅雷也因此而获益，但是对于所有的用户群体而言，迅雷造就的封闭的生态圈形成了某种意义上的垄断，使得迅雷不能听到用户的需求更迭，因而淹没在时代浪潮中。我们似乎也不能说迅雷是一个好软件。
4. 非典型用户是否不是软件的服务对象？
在 10.1.3 中有
注意：我们的软件不是为所有人服务的。
同时举出了
第一个典型用户，吴石头，好像不喜欢上网，他事实上不太会用电脑，也搞不懂如何上传照片。凡是和网络相关的事情,都交给了他的儿子。所以我们不得不把吴石头从典型用户中删除。
的例子。
我们是不是可以认为因为这部分非典型用户使用软件的概率很小，所以不为他们设计功能。
但是概论中举出的例子：
如果一架民用飞机上有需求，用户使用它的概率是百万分之一，你还要做这个功能么？
指出了小概率使用的功能也应该设计完整，是不是与之冲突。如果说是因为非典型用户接受不到服务损失比较少因而不设计，那诸如支付宝之类的软件是不是不需要为脱离信息时代的老人以及占总人口数目较少的残障人士设计功能。毕竟这部分人无法使用支付宝，对支付宝的收益没有太大影响。
5. 成功团队与创新
在 16.1.7 中有
在产品的生命周期结束后，不免会被新的颠覆性创新淘汰；如果公司主动寻找颠覆性创新，则遭到公司内部流程、价值观和文化的排斥。
成功的团队有固有流程，那么像敏捷开发这样的开发框架应该也是在某些团队中实践并成为了成功的主要因素而被广泛推广的。但是这样的固有流程，也成为了书中所说的“把这些成功经验不加区别地运用到新的市场上，往往会适得其反”。那么我们应该如何既从成功团队中汲取经验，又能不被颠覆性创新而淘汰？
二、 调研源代码版本管理软件
由于个人只用过 GitHub 和 GitLab ，因此调研的重点集中在这两款源代码版本管理软件上。
相同之处
- 二者都是基于 Git 实现的在线代码仓库
- 都能新建项目，clone到本地进行开发，利用 Git 的指令进行版本控制
- 能 fork 已有的项目，并提出 Pull Request（Merge Request）
- 能提出 Issue，对项目中发现的问题进行提问
- 有 star、follow 这样的社区功能
不同之处
注：表格内容有部分引用自 GitHub & Bitbucket & GitLab & Coding 的对比分析
| GitHub | GitLab | |
|---|---|---|
| 是否开源 | 否，GitHub 以开源友好而闻名，并且拥有最大数量（19.4M +）的开源项目但其本身不是开源的。 | 是，GitLab 社区版的源代码开放在他们的网站上 |
| 协作项目 | 开源项目最多，全球顶级开源项目（Linux/ Nodejs/ Swift/ Ruby / Docker）都优先选择在 GitHub 上开源 | 私有仓库免费，对于私有项目更友好 |
| 免费计划 | Free Plans 允许托管无限的公有代码仓库，但是，项目不能超过 1 GB和单个文件不能超过 100 MB | cloud-hosted plan 允许无限数量的用户在无限数量的公共和私有项目上进行协作，并且每个存储库有 10GB 的空间限制 |
| 团队控制 | 缺失较好的团队控制方案 | 团队成员权限明确、设置项较细 |
三、调研持续集成/部署工具
GitLab CI
代码库地址：https://gitlab.buaaoo.top/GitLab_CI_Research/testit
- 以 OO_2020_Pre2Task2 作为测试对象，使用 maven 创建 project 后编写了简单的测试文件：
- 配置
.gitlab-ci.yml上传到 GitLab 触发 Pipeline：
- 在
README.md中添加 badges 以显示 Pipeline 状态和 coverage：
GitHub Actions
代码库地址：https://github.com/NaMoah/GitHub_CI_Research
- 同上将代码上传到GitHub：
- 添加
.github/workflows/maven.yml（注意 on 是 main 还是 master，笔者因为主分支是main，on master 导致不触发actions）后触发 actions：
CI/CD 工具使用感受
CI/CD 是一种通过在应用开发阶段引入自动化来频繁向客户交付应用的方法。 CI/CD 的核心概念是持续集成、持续交付和持续部署。
通过 CI/CD 工具可以使我们在集成新代码时，将众多测试流程以自动化的形式完成，使程序员可以更多地专注在编码。
GitLab-CI 和 GitHub Actions 的区别
| 特征 | GitHub | GitLab |
|---|---|---|
| Docker映像支持 支持Docker样式容器的存储和检索 | √ | √ |
| 容器注册表webhooks 在成功推送到注册表以将Docker Hub与其他服务集成后触发动作。 | √ | √ |
| 容器注册表的高可用性 通过使用所有容器和元数据的多个副本来实现高度可用性，因此，如果计算机发生故障，注册表将继续运行并可以修复。 | × | √ |
| 容器注册表地理复制 通过在多个区域中运行多个注册表实例并在数据中心之间同步来支持分布式团队。 | × | √ |
| 支持私有容器注册表 提供了拥有私有容器注册表和存储库的能力 | √ | √ |
| 映像过期策略 轻松定义，管理和更新项目级策略，以定义应删除和保留的映像。此功能旨在帮助您降低存储成本并防止重要图像被删除。 | × | √ |
| 自我管理的容器注册表提供的 容器注册表可以在组织数据中心，共同托管或在选定的云提供商中进行自我安装和自我管理。 | √ | √ |
| 通过REST API使用容器注册表通过REST API 启用对容器注册表的自动化和集成的支持。 | × | √ |
| 通过运行垃圾收集来降低GitLab容器注册表的存储成本 在Docker注册表的上下文中，垃圾收集是当清单不再引用blob时从文件系统中删除blob的过程。 | × | √ |
| 使用搜索查找容器图像 通过图像名称搜索您的组和项目的容器注册表 | √ | √ |
| Helm图表存储库支持 支持Helm图表的存储和检索。 | √ | √ |