软件工程第一次阅读作业
| 项目 | 内容 |
|---|---|
| 这个作业属于哪个课程 | 北京航空航天大学2022春季软件工程（罗杰 任健） |
| 这个作业的要求在哪里 | 个人阅读作业-阅读和调研 |
| 我在这个课程的目标是 | 学习软件工程的基础知识和基本流程，通过团队合作开发一个较大型的软件工程项目并争取能够上线 |
| 这个作业在哪个具体方面帮助我实现目标 | 1、通过阅读《构建之法》来了解软件工程的全部流程和一些基本概念；2、调研git、持续集成/部署工具来帮助以后更好地开展协作 |
阅读《构建之法》后的思考与疑问
1、证明软件可继续发展
能证明所开发的软件是可以维护和继续发展的。例如，对用户需求的分析有详细的文档说明，包括对将来发展的分析和计划。
——P17
我赞同软件开发需要有长远规划的观点，因为一个产品不可能永远停留在一个阶段，要想成功一定需要紧跟时代的步伐。
但是在最初开发的阶段“证明”一个软件是可以继续发展的似乎不太容易。也许在当前的社会背景下，某种应用能够取得不错的市场，但是当社会的风向标转变时，一个比较庞大的软件很难做到迅速转型，而其最初指定的持续发展的目标方案在这时候就不一定行得通了。所以我对书中的这段描述有些疑惑。
2、软件工程师的成长
初级软件工程师如何成长呢？我认为有下面几种成长：
1、积累软件开发相关的知识，提升技术职能。
2、积累问题领域的知识和经验。
3、对通用的软件设计思想和软件工程思想的理解。
4、提升职业技能。
5、实际成果。
——P45
作者在文中提到的软件工程师的这几种成长，侧重了不同的维度，有专业技能、职业技能、思维技能等，那请问这几种维度是否有主次之分？哪一种或哪几种显得更为重要？
另外，像第四点的职业技能，似乎比较抽象，这方面的能力的提升有时候并不容易（相比于技术上的能力通过一般的学习和理解能够掌握来说），那请问这应该如何快速提升呢？
3、爵士乐模式与敏捷开发
爵士乐模式有以下特点：
- 不靠谱（演奏时没有谱子）
- 没有现场指挥
- 也有模式
- 人数较少
这看上去跟“敏捷的开发模式”有点类似。
——P94
首先，我不认为这和敏捷的开发模式类似，在书中的第六章详细介绍了敏捷流程，其中一开始就介绍的敏捷开发的原则中有许多方面与爵士乐模式相违背。
其一，敏捷开发中，文档还是非常重要的，并不是像爵士乐模式中的即兴发挥就可以；另外，爵士乐模式的没有指挥似乎在敏捷开发中也行不太通，一个开发团队还是需要一个leader的。因此我认为这两者并不是“类似”的关系。
4、敏捷流程与28定律
程序员写完功能的时候，我们感觉好像项目完成了80%，殊不知后面的20%往往要花费80%的时间，敏捷流程没有明确表明到底何人何时以何种优先级来完成这20%的任务。
——P115
我们的课程采用的是敏捷开发流程，那么如果在开发过程中遇到了这20%的任务，应该如何处理呢？如果我是项目负责人的话，当开发时间有限时，我也许不会去考虑那20%；如果还有时间，我可能也会选择去提升优化产品的其他方面（如推广等）而不是死磕这20%。不知道我这样的做法在敏捷开发中是否合理？
5、PM所需要的的能力
成为一个合格的PM，需要哪些能力呢？
- 观察、理解和快速学习的能力
- 分析管理能力
- 一定的专业能力
——P188
结合文中这段话后面提到的PM的具体任务，我认为PM所需要的的能力还应该包括“沟通与号召”能力，PM作为项目经理，需要得到成员和客户的支持，如何得到支持，那就是经常与成员和客户沟通，了解双方的需求，同时有一定的号召力能让项目成员一起向着目标前进。因此，我认为文中这部分的介绍还有上面这些可以补充的地方。
源代码版本管理软件的调研
GitHub
GitHub是世界上最大的代码存放网站和开源社区，是通过Git进行版本控制的软件源代码托管服务平台，用户可以创建公开或私有的代码仓库，此外，还支持文档、问题追踪系统、Wiki、任务列表、创建静态网站或博客等功能。
GitLab
与GitHub相似，GitLab是一款基于 Git 的完全集成的软件开发平台，通常用于企业团队内部协作开发。GitLab也具有wiki以及在线编辑、issue跟踪功能、CI/CD 等功能。
Gitee
Gitee（码云）是开源中国于2013年推出的基于Git的代码托管和协作开发平台，提供中国本土化的代码托管服务，是中国境内规模最大的代码托管平台。
Bitbucket
Bitbucket是Atlassian公司提供的一个基于web的版本库托管服务，支持Mercurial和Git版本控制系统，它提供的服务类似于GitHub（仅支持Git），目标用户是开发专有软件的专业开发者。
相同点
作为git版本控制管理软件，他们的功能都有一定的相似之处，具体来说，都会提供一下几种服务：
- 代码的储存、克隆和复制
- 拉取请求
- 文档系统
- 内联编辑
- 问题跟踪
- 安全性保障
- ……
不同点
| GitHub | GitLab | Gitee | Bitbucket | |
|---|---|---|---|---|
| 导入种类 | Git、SVN、HG等 | Git | Git、SVN | Git、CodePlex、SVN、HG等 |
| 收费情况 | 私有仓库和企业版收费 | 企业内部，收费 | 企业版先试用再收费 | 免费和付费服务都有 |
| 仓库容量 | 不超过1GB | 可以自定义 | 社区版500M | 没有限制 |
| 使用人数 | 7300万+（截至2021年） | 未知 | 800万+（截至2021年） | 500万+（截至2020年） |
持续集成/部署工具的调研
GitLab CI
将一份生成全排列的python代码上传至GitLab仓库，并编写 .gitlab-ci.yml ，进行CI测试。
代码仓库为：
测试结果为：
编译成功
Job通过
GitHub Action
将同样的一份代码上传至GitHub仓库，并编写 python-package.yml ，进行测试。
代码仓库为：
测试结果为：
正确输出
workflow成功运行
使用过后的看法
1、工具的特点
GitLab的CI/CD可将每次运行分为多个Job进行处理，并且对每个job能够反馈成功（passed）或失败（failed）的标志，进入每一个job后可以看到运行的详细信息，用户可以根据给出的信息找到错误的位置。
GitHub的Action更为便捷，许多Action可以复用（可以找到其他开发者编写的Action，稍加改动以适应自己的项目），其可以在云端或者本地运行，并且进入job的详情页面也能看到运行的信息。
2、使用场景
当前，GitLab CI/CD的关注度较高，但GitHub Action的开源性更好。由于GitLab CI/CD的管理更加简便，因此对于中小型项目或较简单的项目更推荐使用。而GitHub Action的插件较多，更为复杂，因此对于大型项目或是功能较为复杂的项目更为合适。
982
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
