BUAA 软件工程 第一次作业

BUAA 软件工程2022 第一次作业

项目	内容
这个作业属于哪个课程	北航 2022 春季敏捷软件工程
这个作业的要求在哪里	作业说明链接
我在这个课程的目标是	了解并提高自己对软件工程的认识和实践能力，加强软件开发技巧与团队协作能力，收获软件工程实践经验
这个作业在哪个具体方面帮助我实现目标	快速了解现代软件工程，学习团队协作的方式，学习源代码管理的方法以及CI/CD的方法

阅读提问

Q1：单元测试真的能产生可重复、一致的结果吗

单元测试应该产生可重复、一致的结果

如果单元测试的结果是错的，那一定是程序出了问题，而且这个错误一定是可以重复的。

在第2章中，有如上的结论，但是以我在OO第2单元时的测试来说，我不认为测试结果可重复，在多线程中，往往出现各种多线程的小问题，而这些小问题都是在程序运行了非常长的时间后，在某一种非常苛刻的情况下触发的bug，而重复运行这一段代码，极有可能不会再次触发这个bug，结果也自然不一致了，我想在现在的各种软件项目中，多线程的项目应该占了绝大多数，这在测试中难免出现一些概率极低的bug且无法复现。

Q2：单元测试应该谁来写？

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

第2章中有如上的说明，但是我认为最适合写单元测试的人应该是最熟悉该模块需求的人，或者说由提出该需求的人来测试，这是因为程序的作者可能只是按需求完成了代码，那么在测试时，也会按自己的代码的理解来完成测试，而如果他在写代码时已经误解了该需求，那么无论如何去测试，都是测不出问题的，因为在他眼中这就是正确的，而在真正的需求上，可能该功能是有问题的，因此我认为应该由最熟悉需求的人来写测试。

Q3：在完成时间上使用六西格玛方法是否正确？

但是从标准方差来看，Al的方差是5.3，而Bob是1。

第3章中有一个比较交付时间的分析，在实际完成时间与估计时间上进行六西格玛来评价，我个人认为不是很妥。我们看看六西格玛的定义：(百度百科)

六西格玛（Six Sigma，6 Sigma）是一种管理策略，它是由当时在摩托罗拉任职的工程师比尔·史密斯（Bill Smith）于1986年提出的。这种策略主要强调制定极高的目标、收集数据以及分析结果，通过这些来减少产品和服务的缺陷。六西格玛背后的原理就是如果你检测到你的项目中有多少缺陷，你就可以找出如何系统地减少缺陷，使你的项目尽量完美的方法。

我们可以看到，这个方法实际上是对项目的缺陷作评价的，6个西格玛=3.4失误/百万机会，也就是说对项目的失误率来作评价，而一个程序员过早完成任务，也能算失误吗，我个人认为用平均时间和超出时间来作评价更恰当。

Q4：真的建议使用goto吗？

问：我们能不能用goto？

答：函数最好有单一的出口，为了达到这一目的，可以使用goto。只要有助于程序逻辑的清晰体现，什么方法都可以使用，包括goto。

第4章中，代码设计规范中，有如上描述。但是在我个人开发来讲，我从未使用过goto，正如评论所说：

goto语句使程序的静态结构和动态结构不一致，从而使程序难以理解，难以查错。

goto语句的结果：在C/C++等高级编程语言中保留了goto语句，但被建议不用或少用。在一些更新的高级编程语言，如Java不提供goto语句，它虽然指定goto作为关键字，但不支持它的使用，使程序简洁易读；尽管如此后来的c#还是支持goto语句的，goto语句一个好处就是可以保证程序存在唯一的出口，避免了过于庞大的if嵌套。

goto往往会使得程序结构变得奇怪，结对的另一方应该也很少使用goto，这就加大了理解难度。我认为goto可以使用其他东西来代替，不是很习惯在代码中看到goto。

Q5：PM是否真的能做到与大家平等？

Program Manager 和一些公司的 Project Manager 的区别:

Project Manager	Program Manager
是团队的行政领导, 带领大家在项目中工作。	和大家平等工作, 推动团队完成软件的功能。
通常是团队和外界打交道的唯一代表	一个团队可以有很多PM
对项目的功能有最后的决定权	和其他团队成员一起形成决议
管事也管人	管事不管人
不一定做具体工作	一定做具体工作

阅读第9章项目经理篇时，有如上的表格，其中描述Program Manager为与大家平等工作、与其他成员一起形成决议、管事不管人。但是在我大学里实际的项目中，我认为这是很难做到的。在我第一次当项目组长时，我最初的想法也是大家应该是平等的，共同对项目提出建议，然后投票决定项目的走向等等，我应该起到一个类似于主持人的作用，项目会议应该是所有人一起参与进来，各抒己见，然而，实际上，大部分项目到了最后都是我开一个会，全程也是我在说明，这个地方应该如何去完成，这个地方应该需要注意什么细节，这个地方有前人的博客可以借鉴，其他人可能基本不发言。就算这样，已经把相关博客找好了，实现的功能输入输出描述好了，干起活来，还是得催，比如我曾经有一个项目，在寒假便安排好了任务，要求两周内完成后给我看一下效果，但是这个任务硬是拖到了暑假，最后我花了一个晚上把之前发给他的博客复现了一遍，实际上按那篇来做根本不会出现很奇怪的问题。我认为不管人的话，至少在大学是很难完成一个类似于PM的任务的。当然在工作上可能不一样，但是我还是对PM可以于大家平等表示怀疑，PM理应对每一个项目中的人进行管理，对没有跟上进度的也理应去push，如何才能实现真正的平等呢？

调研源代码版本管理软件

参考wiki、知乎，此处主要选取了以下代码版本管理软件作分析：Github、GitLab、Gitee、Bitbucket、Plastic SCM。其中除了Bitbucket外本人均使用过，Github、GitLab、Gitee主要是在写课程代码时使用，不过目前Github在国内连接不稳定，体验不如之前了；另外Plastic SCM是在做unity开发时使用的，这是由于游戏中往往有大量的模型文件，这在其他不支持超大单个文件的代码版本管理软件中很难进行版本控制。

相同点

实际上目前大部分版本管理软件都实现了这些非常基础的功能：

• 拉取请求
• 代码审查
• 内联编辑
• 问题跟踪
• Markdown支持
• 双向认证
• 高级权限管理
• 托管的静态网页
• 功能丰富的API
• Fork / Clone Repositories
• 代码段
• 第三方集成

不同点

• 使用人数

从下表中可以看出，单从使用人数来说，Github和Gitlab都远远超过其他软件，其中Github最多。（该表格摘自wiki）

Name	Users	Projects
Assembla	Un­known	526,581+[47]
Bitbucket	5,000,000[48]	Un­known
GitHub	65,000,000[49]	200,000,000[49]
GitLab	31,190,000[50]	546,000[51][j]
GNU Savannah	93,346[52]	3,848[52]
Launchpad	3,965,288[53]	40,881[54]
OSDN	54,826[55]	6,294[55]
Ourproject.org	6,353[56]	1,846[56]
SourceForge	3,700,000[57]	500,000[57]

• 开源与收费（部分借鉴博客）

	GitHub	GitLab	Bitbucket	Plastic SCM
导入种类	支持导入Git，SVN，HG，TFS（但是除Git外的貌似需要插件）	支持导入Git	支持导入Git，CodePlex，Google Code，HG，SourceForge，SVN	仅支持Plastic
大小限制	项目不能超过 1 GB，单个文件不能超过 100 MB	每个存储库有 10GB 的空间限制	当项目即将达到 1GB 时，会有邮件通知	免费版本项目最高5GB，单文件最高可支持1TB
收费策略	GitHub 的企业版起价为 $2500 /10人，每年计费一次	收费为$10 /10人，每年收费一次	每位用户$39 ，对用户数没有限制，每年收费一次	免费供最多3个用户；每增加25GB文件 $5 ，每增加一个人$7（每月）
是否开源	否，GitHub 以开源友好而闻名，并且拥有最大数量（19.4M +）的开源项目但其本身不是开源的。	是，GitLab 社区版的源代码开放在他们的网站上	否，在购买托管服务的方案中提供了「产品定制」的功能	否，主要为unity开发提供版本控制服务。

• 缺点与优点

软件	优点	缺点
GitHub	1. 是当前最大的开源免费代码仓库，现在private仓库也免费使用 2. 提供开发者一个交流合作的平台，通过pr和issue帮助拥有者维护开源程序 3. 提供了发布的模块给开发者进行发布的版本管理 4.兼容性，源代码位于GitHub的项目可以轻松地定制到任何云主机服务	1.GitHub的服务不是完全免费的，如果想要享受GitHub提供的所有功能，需要付费。 2.大小限制：文件大小不能超过100Mb，存储库可以托管信息1Gb。
Gitlab	1.与LDAP(轻量级目录访问协议)集成，允许在Internet上定位和访问各种资源。GitLab EE支持多种LDAP服务和组同步。 2.免费，这意味着用户可以拥有无限数量的私有存储库。	1.界面相对较慢 2.存储库常见的技术问题。
Bitbucket	1.提供无限的免费私人仓库 2. 支持中文	1. 功能相比Git少很多 2. 对于开源不够彻底
Plastic SCM	1.单个文件无限制 2.完全分布式，开发人员可以在他们的本地机器上克隆存储库，并在不连接到主服务器的情况下签入、分支和合并。 3.图形用户界面和可视化	1.免费仅支持3人，5GB的团队项目 2.仅支持Plastic，受众较小，功能有限，一般用于unity游戏开发

调研持续集成/部署工具

采用本人之前数据库的后台管理系统，该系统由vue编写，可实现线上编译并将编译结果保存至仓库，同时可设置在线访问该系统（由于后端未部署目前只能看到首页，无法登录）。下面作详细示范。

Github Action

这里我采用了推荐博客的教程，只是该教程是部署一个react应用，实际上大部分的操作是相似的。

首先，我们需要编写一个action的workflow文件，如下：

name: Build and Deploy
on: [push]
jobs:
  build-and-deploy:
    concurrency: ci-${{ github.ref }} 
    runs-on: ubuntu-latest
    steps:
      - name: Checkout 🛎️
        uses: actions/checkout@v2

      - name: Install and Build 🔧 
        run: |
          npm install
          npm run preview
      - name: Deploy 🚀
        uses: JamesIves/github-pages-deploy-action@v4.2.5
        with:
          branch: gh-pages # The branch the action should deploy to.
          folder: dist # The folder the action should deploy.

这里我借用了开源库，其可以将生成的文件push到一个新的分支，这样我们就可以通过GitHub pages来进行在线查看我们的网站了。该代码主要是先将我们的代码拉下来在虚拟机中build（即npm install && npm run preview），之后再将生成的html、css等等静态网页资源push到指定分支上。

当我们对库进行了push操作时，将会自动重新build，并覆盖在gh-pages分支中，如下所示：

在这一步中值得注意的是，我们需要更改一下vue的配置文件：将publicPath: ‘/’,修改为publicPath: ‘/admin_frontend/’,否则网页无法正常显示（因为找不到css等文件）

之后配置一下pages，将source改为之前设定好的分支（gh-pages）。

于是访问该网站即可看到build好的项目：

Gitlab CI

同理，使用相同的项目，把库转移到gitlab上，在线编译+在线展示，CI脚本如下。这里我借鉴了博客、vue官方文档。

image: node:latest   # 表示使用有 nodejs 环境的 docker，python等也有其他的 docker。

stages:     # 定义阶段顺序
  - build   # 先 build
  - deploy  # 再部署

build:                   # 定义一个 job 叫 build
  stage: build           # 它属于 build 阶段
  tags:
    - "runner1"
  script:                # 该 Job 要执行的命令行
    - npm install        # npm 安装项目依赖
    - npm run preview      # build 项目

pages:                   # 定义一个 job 叫 pages，最后一个阶段一定要叫 pages，这样 gitlab-pages 才会开始工作
  stage: deploy          # 他属于 deploy 阶段
  tags:
    - "runner1"
  script:                # 该 Job 要执行的命令行
    - mv public public-vue # GitLab Pages 的钩子设置在 public 文件夹
    - mv dist public 	 # 重命名 dist 文件夹 (npm run build 之后的输出位置)
  artifacts:             # 定义工件，在 jobs 执行完了后，gitlab-pages 会把工件目录下的文件自动部署到 pages 服务器中
    paths:               # 将项目中的文件夹定义为工件目录
      - public           # 要想部署到 pages 服务器中，这个文件夹必须叫 public ,所以前面一定要把打包结果复制到 public 文件夹
    expire_in: 30 days   # 工件有效期为 30 天，工件到期不会影响 pages

cache:                   # 定义缓存文件，从一个 job 到另一个 job ，除仓库外的文件都会被删除，然后把缓存文件复制到下一个 job
  paths:                 # 定义缓存文件的路径
    - node_modules       # 这里要缓存 node_modules，在下一次触发 gitlab-ci 时，缓存会被还原，就不用重复安装依赖。
    - dist               # 同时把 build 阶段生成的 dist 文件夹也缓存起来，在 deploy 阶段会用到。

不过仅仅如此是不能运行的，因为我们没有runner，原本是有共享的免费runner，但是这需要一张银行卡认证，所以只能自己部署一个本地的runner了。部署过程也比较简单：（这里对一些本人的token就作打码处理了）按这个token注册后可以在列表中看到我们的runner，使用他就可以了。

之后一旦对库进行了更新，就会自动build并发布至gitlab pages上。

待build完成后自动将页面部署至gitlab pages。得到下面页面：

使用总结

在此调研中我使用了自己数据库课设的库（两个库均在上面已给出），同时也阅读了前几届大佬们的笔记，测试了一下两种工具在库上的使用，实现了自动build的功能，并在线访问build后的结果，简化了开发过程中反复手动build的过程，实现了持续集成部署功能。下面简要说说两者的优缺点：

• Github Action
  • 从使用体验上来说，我认为Github Action更方便，特别是对于手里没有服务器的开发人员来说，因为其只需要我们写一个脚本，他便会提供服务器运行脚本，与Gitlab CI不同，Gitlab CI需要自己部署一个runner，这花费了我大量时间，相比之下，如果我没有提前部署好一个runner的话，我肯定是会选择Github Action来作为自己的持续集成部署工具的。
  • 从运行速度上来说，Github Action也运行的更为迅速。
  • 另外Github上提供了很多action的集成插件，可以直接使用他人写好的插件来完成自己的功能，无需自己重复编写。
• Gitlab CI
  • 对流水线的管理要更加简单易懂，各阶段的定义和阶段之间的依赖关系显式列在配置文件中，因此可以有多种自定义选择方式，而Github Actions则显得较为复杂
  • 没有国外银行卡的话无法使用共享的runner，因此只能在自己部署自己的runner，虽然麻烦了点，不过这在某种意义上也实现了我们可以使用更强大和符合我们要求的服务器来当作runner，同时也有了一定的保密性。

下面给出更详细的对比（来源）

	Github Action	Gitlab CI
独特的功能	可能实现最佳GitHub 集成	AutoDev Ops / 允许将代码管理和 CI 保存在同一个地方
提供免费计划	内部部署计划（尚不可用）将是免费的，免费云计划中包含 2000 分钟构建时间。开源项目的完全免费计划。	SaaS 版本和内部部署版本都有非常慷慨的免费计划。
可预测的定价	虽然很清楚成本是多少（按构建分钟计价），但计算成本可能会很麻烦，特别是因为价格可能会因项目的提交而有很大差异。GitHub Actions 的一个优势是层级定义了最大分钟数，因此更容易预测最终成本。您还可以购买价格取决于平台（MacOS、Linux、Windows）的其他运行器	SaaS 和自托管版本的价格清晰且价格合理。
支持/SLA	社区支持适用于任何级别，不清楚何时以及是否提供专门的支持。可以放心地假设企业客户可以获得技术支持。	所有付费计划都包括下一个工作日支持。
并行	允许并发作业，甚至是多平台。	通过 YML 配置文件 (gitlab-ci.yml) 轻松配置要并行运行的作业
分布式构建	不适用。没有具体提及，但鉴于任务可以在多个平台上运行，分布式构建很可能也可用。	是的
容器支持/构建环境	Linux、macOS、Windows 和容器，或直接在 VM 中运行。	Docker Container Registry 默认集成到 GitLab
分析/状态概览	绝对可用的最小状态概览，带有实时日志和 GitHub 集成。不清楚能走多远。	是的
管理支持 管理用户/项目/分配角色和权限等有多容易	不适用，从可用文档中不清楚	是的
自托管选项	即将推出，尚不可用。	是的
托管计划/SaaS	是的	是的
构建管道 （持续交付管道是对软件从新代码提交、测试和其他静态分析步骤一直到产品最终用户的过程的描述。）	是的。称为 GitHub Action Workflows，它们使用 YAML 语法在单独的 Docker 容器中定义（它们曾经支持 HCL，但现在正在迁移）	是的。通过 YML 配置文件定义
报告 （报告是关于查看特定报告（如代码覆盖率或自定义报告）的能力，但不一定与更大的仪表板相关联。）	不适用。从可用文档中不清楚	是的
生态系统 （除了官方文档和软件，是否有大型社区在使用该产品？您可以使用任何社区驱动的工具/插件吗？）	是的。由于大量的追随者，GitHub Actions 已经享有各种可用的预制工作流程，您可以在主页上直接浏览：https://github.com/features/actions	是的
集成 （对常用工具的第一方支持（如 Slack 通知、各种 VCS 平台等））	是的。通过可用的共享第三方工作流程（AWS、Azure、Zeit、Kubernetes 等）实现集成	是的。GitLab 中提供了大量第三方集成，最著名的是 Kubernetes 和 GitHub，还有很多其他集成：https://docs.gitlab.com/ee/integration/README.html
API 自定义集成是可用的，通过 API 或其他方式，它被单独提及，因为它允许比任何生态系统/集成选项进一步自定义	不适用。目前尚不清楚，但假设 GitHub Actions 将与 GitHub GraphQL API（可用的更成熟的 GraphQL API 实现之一）集成	是的。提供 REST API 和（新的）GraphQL API，并计划仅在未来维护 GraphQL API。允许做几乎任何可以通过接口完成的事情，至少在 CI 需求方面。
审计	不适用	是的

综上所述，就目前我个人的使用体验来看，我更倾向于使用github action。主要是其无需部署服务器即可一键使用，而且也有大量的action开源库可调用（调包侠罢了）。