工欲善其事——2021软工第二次博客作业

项目	内容
这个作业属于哪个课程	2021春季软件工程（罗杰 任健）
这个作业的要求在哪里	个人阅读作业#2
我在这个课程的目标是	学习软件开发的工程化方法，第一视角体会结对编程、团队协作的软件开发流程
这个作业在哪个具体方面帮助我实现目标	阅读《构建之法》，了解软件工程需要考虑的方面，学习使用CI/CD工具

阅读提问

问题一：为什么要在大学软件工程课上专门实践敏捷开发？

作为一名学生，我从没实践过任何一种软件工程方法论，相信大部分同学也是这样。那么课程组在一门必修课上选择敏捷开发是有什么缘由吗？

问题二：敏捷开发的同步应该怎么管理？

此问题出自第六章《敏捷流程》

各个需求和任务之间是有种种复杂的依赖关系的，除了优先级之外，我们还要考虑相互的依赖关系。

敏捷的团队：

• 自己挑选任务。

• 每个人要联合起来对项目负责，有人工作落后了还要帮助他改进，项目缺少某类资源还要自己顶上去。

• 每个人都全面负责，自己搞定规格说明书，和别人沟通，同时自己搞定测试。

敏捷开发之下，一个项目会被划分成具有一定依赖关系的需求/任务，那么具有依赖关系的两个任务的负责人肯定需要同步，但是，每个人都会有自己认领的多个任务，而且对自己认领的所有任务全面负责，同步关系也是纷繁复杂。

我们试想这样一种情况：AI 完成了一项任务，等待与 BB 同步，但是 BB 的进度落后，AI 和 BB 两部分与另一边的工作也需要尽快同步了，但是，AI 负责的别的任务还在做，另一边的 CC 等着同步，那么 AI 是选择帮 BB ？还是选择自己的另一项任务？又或者说，这个决定是由整个团队来决定？

问题三：敏捷开发究竟敏捷在哪？

我的疑惑在于，冲刺阶段竟然有每日例会，每个人都需要准备这个会议，进度报告、制作图表，这难道不浪费时间？还是说这是必要的牺牲？

能不能少开会，大家约定俗成，反正有看板制度，这样责任明确，任务也可追溯？

问题四：如果一个团队长期担任 PM 的人离职了，团队和新 PM 如何应对？

此问题出自第九章《项目经理》

本章着重介绍了什么是 PM 、 PM 的作用、以及怎样算是一个好的 PM 。我最大的感受是，团队不能没有一个好的 PM ，PM 相当于一个GPS 导航，粘合剂，风险预警装置，除了开发和测试，剩下的“脏活累活”都是 PM 负责的，可见 PM 的重要性。

基于本章以及自己的经验考虑，程序员和 PM 是平等的，需要靠长期的磨合来和平相处，如果在某个项目的开发过程中，原来和大家共事愉快、得到支持、得到尊重、积极影响团队的 PM 离职了，我想会团队以及新 PM 都会面临不小的挑战。那么我们应该怎么应对？

观察到学生实践项目一般是这个模式。由于我们软件工程课程的团队是自由组队，一个队伍的成员水平一般是差不多的，那么我猜测，我们团队项目队伍一般也会是这样的模式。那么有几个问题：

问题五：业余剧团模式“中央指挥”需要怎么选择？

问题六：“中央指挥”面对不同的人希望选择同一个角色的情况该怎么处理？意愿优先还是能力优先?

问题出自这里

业余剧团模式 (Amateur Theater Team):

这样的团队在每一个项目（剧目）中, 不同的人会挑选不同的角色。在下一个剧目中, 这些人也许会换一个完全不同的角色类型。各人在团队中听从一个中央指挥（导演）的指导和安排。在学生实践项目或培训项目中, 这样的事情经常发生。

• 这个“中央指挥”需要怎么选择？
  • 泛化而谈，也就是一个 Team 的 leader 怎么选？
    • 进一步， leader 的职责范围一般是如何的？
      • leader 指导安排太过是否会变成主治医师模式或者明星模式
• “中央指挥”面对不同的人希望选择同一个角色的情况该怎么处理？意愿优先还是能力优先?
  • 意愿和能力如何平衡？

调研源代码版本管理软件

• GitHub

  GitHub 是第一个供“用 Git 进行版本控制系统的软件开发项目”使用的基于 Web 的代码托管服务，是目前全球最大的开源社交编程及代码托管网站。

• GitLab

  GitLab 是一个利用 Ruby on Rails 开发的开源应用程序，实现一个自托管的 Git 项目仓库，可通过 Web 界面进行访问公开的或者私人项目。

• Bitbucket

  BitBucket 是 2008 年创建的源代码托管网站，采用 Mercurial 和 Git 作为分布式版本控制系统，同时提供免费账户和商业计划，主要面向慈善企业和企业用户/其主要市场是大型企业。

	GitLab	Bitbucket	GitHub
是否开源	是，GitLab 社区版的源代码在这，可以定制专用的 GitLab ，例如 OO 代码仓库，Ruby 代码仓库。	否，但在购买托管服务的方案中提供了「产品定制」的功能。	否，GitHub 以开源友好而闻名，并且拥有最大数量（19.4M +）的开源项目但其本身不是开源的。
开源项目数量			最多，适合专业人士进行探讨，也适合小白学习。
免费计划	GitLab 的 cloud-hosted plan 允许无限数量的用户在无限数量的公共和私有项目上进行协作，并且每个存储库有 10GB 的空间限制。	Bitbucket 的 Small teams plan 允许 5 个成员加入，公有/私有仓库均免费。当项目大快到达 1GB 时，会有邮件通知。	GitHub 的 Free Plans 允许托管无限的公有代码仓库，随时进行clone, fork 和 contribute，对磁盘使用没有限制。但是，项目不能超过 1 GB和单个文件不能超过 100 MB。
是否支持导入基于多个不同 VCS 的 repos	否（仅支持 Git ）	是	是

调研持续集成/部署工具

点击图片以放大


使用的项目是 OO_2020_pre3_task5 .

GitLab CI

这是代码仓库

使用 Maven 重新构建项目，使用 cobertura-maven-plugin 运行单元测试并导出代码覆盖率报告，捕捉测试率，最终显示在 README .

结果如下：

Pipeline

test

GitHub Actions

这是代码仓库，项目本身与 GitLab 是一样的，不同在于控制 CI 的 yml 文件，以及捕捉代码覆盖率的方式。

结果如下：

Pipeline

test

使用后

• GitLab CI

  这是我在课程学习中用的比较多的。整个工作由 GitLab Runner 执行，用户通过 .gitlab-ci.yml 文件控制。

  我们通过 image 拉取镜像， services 绑定其他镜像，在同一个 GitLab Runner 下使用。

  stages 指定 job 运行的先后顺序，同一个 stage 的 job 是并行的。另外还有 dependencies 用于定义 job 依赖关系。

• GitHub Actions

  GitHub Actions 的配置文件叫做 workflow 文件（官方中文翻译为 “工作流程文件”），存放在代码仓库的 .github/workflows 目录中。

  jobs 定义各个任务 job ， GitHub Actions 为每个任务都提供了一个虚拟机来执行，每台虚拟机都有相同的硬件资源。

  不同的 job 通过指定 needs 来构建依赖关系。

个人觉得 GitHub Actions 更好用

• GitHub Actions 与 GitLab CI 最大的不同在于 action ：

  action 是 GitHub Ac­tions 中的重要组成部分。它是已经编写好的步骤脚本，存放在 GitHub 仓库中。

  对于初学者来说可以直接引用其它开发者已经写好的 action ，可以在官方 action 仓库或者 GitHub Marketplace 去获取。此外 Awesome Actions 收集了很多非常不错的 action 。

  比如 GitHub 仓库中代码覆盖率的徽章需要使用 codecov/codecov-action@v1 ，具体使用参照指导，支持不同语言

  比如配置 java 的 actions/setup-java@v1

  比如用于检出仓库分支的 actions/checkout@v2

  @后面的 vx 指的是版本

• GitHub Actions 相当于为我们免费提供国外服务器。利用其进行编译、构建环境进行测试都会非常方便。虽然提供的虚拟机 OS 只有 Windows Server 2019、 Ubuntu 20.04、 Ubuntu 18.04、 Ubuntu 16.04、 macOS Big Sur 11.0、 macOS Catalina 10.15 ，但是可以利用 docker 镜像搭建其他不同的 OS，例如可以实现runs-on centos

  个人尝试了编译冯如杯项目的软件，环境配置很快；rails 项目的部署， bundle 执行迅速。

各种详细的对比可以参考：

GitLab CI vs GitHub Actions
从 GitLab CI/CD 迁移到 GitHub Actions