软件工程第一次作业

项目	内容
这个作业属于哪个课程	2020北航敏捷软件工程
这个作业的要求在哪里	个人阅读作业-阅读和调研
我在这个课程的目标是	掌握团队协作能力、软件开发工具使用技能、开发高质量并且可用的复杂软件能力
这个作业在哪个具体方面帮助我实现目标	对团队协作、工程化方法有初步认知，对软件开发工具有初步了解

阅读提问

基础缺失与技能“字典”

【第3章57页】提到一个故事，讲述的是面试过程中遇到面试者对基础语法掌握不熟练，把时间花费在基础技能的检索中，而没有时间去考虑高级技能（比如算法、设计……）。我觉得在这个故事里，确实是面试生在基础技能上的缺失会严重影响后续工作。

但是，在大多数情况下，人类是难以做到成为一个技能“字典”的，同时，过多的基础技能训练不仅耗费大量时间也会在某些程度上造成思维上的局限性。

那么在一般情况下，我们所期望的是在上面两种极限中间的某一种合适的状态。所以问题就是：

这个合适的状态要如何找到呢？我们是否有一些简单易行的方法去判断自己处于一个什么样的状态呢？

二人合作中的不良影响

【第4章83页】讲述了二人合作过程中可能出现的一系列阶段，提及“二人合作过程中的相互影响”。诚然，二人合作中不断磨合会让两个人成长和进步，但是同样的，一个人的坏习惯也有可能影响另一个人。所以我的问题是：

如何尽量减少自己被搭档的坏习惯影响？或如何避免自己的不良习惯影响到他人呢？

“惊喜功能”的特性

【第8章167页】介绍了基础功能、核心功能、惊喜功能的投资/效益关系。书中提到惊喜功能可能随着时间的推移，会降低竞争力，变成核心功能甚至基础功能。那么在前期投入的时候，我们事实上应该预料到，在长期竞争中，功能的效益会随着时间的推移发生大幅度的降低。

那么在前期计划时，我们该如何去衡量一个功能的效益呢？

设备体验的地域性差异

【第12章267页】提到软件贯穿多种设备的用户体验，在不同的设备上，由于视距的不同，软件的交互体验也各有不同。通过搜索资料，不难发现，这种交互体验差距的影响因素并不局限于设备，其实同一种设备在不同地区，由于生活习惯的差异，人们的使用也会有所差异。比如在一些地广人稀的国家，客厅面积较大，智能电视的视距可能要更大。在一些习惯席地而坐的国家，此类设备还需要考虑视角的变化。

这些地域性差异应该在何时加入设计考虑方案？软件应该如何保持在这些方面上的灵活性？

蚍蜉撼树？

【第16章345页】模块“迷思三：好的想法会赢”中提到两种键盘布局（QWERTY、Dvorak），说明了在很多影响没有那么大的时候，人们不愿意改变旧有的习惯，从而拒绝更好的事物。这其实也就解释了，为什么很多旧有的问题会一直保留下来。

我认为这件事并不绝对的。

从更长远的角度来说，每一项技术都会有走到尽头的一天。不是说只要有了生态，有了客户基础，就一定很难被撼动。“撼树”的容易程度应该与性能的改善成正比，与客户基础成反比，与客户对新事物的可接受程度成正比。

也就是说，“千疮百孔”的树，即使根基深厚，是否也可能很容易被撼动？

调研源代码版本管理软件

有趣的是，GitLab官方给出了GitLab与GitHub的一系列对比：GitLab VS GitHub

GitLab

结合GitLab文档和个人使用体验，我认为GitLab大致有如下优势：

• 更具有实用性的“组/子组”分类。从个人感受上来说，gitlab在“组”上的管理为团队合作完成的作业提供了一种更加舒适的权限管理方案。“组”下有“子组”，“组”、“子组”、单个仓库可以分别设置权限，权限可以逐层继承。仓库归属于“组”，“组”中下辖多个仓库。这些对于一个具有多项目、多小组的组织来说，更具有可用性。
• 可以重复运行单独程序。GitHub只能由触发机制触发某些个制品的重启，然而GitLab可以支持单个任务的重启，更加方便。

GitHub

GitHub一项很重要的优势是生态。目前支持GitHub的CI很多，如Travis CI, Circle CI, Actions…….。

fork & pull request是GiHub独具一格的工作模式。从开源仓库fork一个到自己的主页，进行发展后，提交Pull request告知原作者。

GitHub的搜索页面很用心，可以提供当下比较受欢迎的主题。

GitHub具有两因素身份验证（2FA）， 这意味着除了要登录的密码外，还将提供其他安全措施。 当您登录Github帐户时，将会生成一个OTP（一次性密码）并通过手机发送（如果2FA已激活）。 登录时要求输入此OTP，然后只能访问该帐户。

Bitbucket

Bibucket为小团队提供较大的免费私人空间（<=5人免费），Bitbucket的一个弊端是搜索页面过于简单，想要找一个项目可能很费力。

gitee

码云，是 oschina 免费给企业用的。gitee与Bitbucket类似，拥有“5人免费”优惠。相比于其他版本控制工具，它的突出特点有：

• Gitee在线IDE
• 仓库自动备份
• 支持仓库访问IP限制
• 支持微信/钉钉通知
• ……

调研持续集成/部署工具

什么是CI/CD

在软件开发的过程中，我们在每次对源代码修改时，往往需要重新进行部署。然后每一次部署往往是重复而又费力的工作。那么我们能不能在每次修改源代码后，一键完成这些重复性的工作呢？

于是，这个世界上有了CI。现在的主流CI一般能够完成：

• 从仓库自动抓取代码
• 提供运行环境
• 执行测试
• 完成构建
• 部署到服务器
• ……

持续集成方便我们对小的、频繁的更改进行快速的测试。

Github Actions

作为支持github的主流CI之一，actions有一个突出的特点：建立actions的官方市场。同时，也可以从awsome actions中找到不少不错的action。这些共享大大降低了工作的重复性。

配置文件

actions的配置文件是yml形式，存储在.github/workflows目录下。详细语法介绍可以参考GitHub Actions 入门教程。

实例

我们对一个简易的vue项目进行部署。大致步骤如下：

1. 配置Github的token、email等
2. 编写配置文件(.yml)
3. 修改vue项目中的publicPath等相关路径信息
4. 推送仓库
5. 从github pages配置中修改域名信息

下面是一个简易vue项目部署的例子：

actions完成部署时的样子：

源代码公开仓库

展示效果

Circle CI

CircleCI是一个基于云的系统，但是也可以提供本地或私有云解决方案。它同样绑定github。Circle CI开箱即用，但是所能覆盖的语言较为有限。Circle CI 和Travis CI还是比较相似的，然而Travis CI 的社区版本近日停止了服务。

配置文件

同样采用yml形式，存放于.circleci/文件夹下。

实例

大致步骤与github actions相似，但是特别的，往往需要向对应仓库加入具有读/写权限的SSH key，以保证Circle CI能够将制品写入仓库的对应分支。

Circle CI完成部署时的样子：

源代码公开仓库

展示地址

gitlab CI

需要自行搭建runner，并在gitlab上配置好服务器相关。部署文件同样采用yml形式。分享一位学长的经验：

Rails大作业管理：Gitlab CI/CD docker部署以及外网访问

gitee go

gitee go（肉眼可见的复杂）支持图形化流水线配置，一目了然。当然，可以图形化编辑的模板是有限的。

笔者目前没有尝试配置，可以尝试阅读官方文档。

相通之处

上述CI/CD工具一般采用.yml文件进行配置，绑定仓库并与仓库的某些操作（如push）相关联。

不同之处

服务器

一些CI/CD提供免费空间和服务器(circle、action等)，另一些则需要自行部署服务器(gitlab-ci等)。

图形化

gitee提供了图形化流水线配置，让结构清晰，方便并行设计。

单任务重启

gitlab-ci提供了单任务重启机制，运行用户单独重启某一个任务，而不需全盘重来。