构建之法与CI/CD
| 项目 | 内容 |
|---|---|
| 这个作业属于哪个课程 | 2021春季软件工程（罗杰 任健） |
| 这个作业的要求在哪里 | 个人阅读作业2 |
| 我在这个课程的目标是 | 认识软工，拥抱软工，提升相关能力以便日后与其朝夕相伴 |
| 这个作业在哪个具体方面帮助我实现目标 | 于《构建之法》中理解软工，于实际应用中理解CI/CD |
一、阅读提问
1.什么是Bug？
原文参见《构建之法》第1章第2节
什么是Bug呢？简单地说，软件的行为和用户的期望值不一样，就叫Bug。例如，某聊天软件启动时就崩溃了，用户期望这个聊天软件不能崩溃。例如，某聊天软件不支持视频聊天，用户期望这个聊天软件支持视频聊天。但是该软件的开发人员说，这个软件根本没打算支持视频聊天。
相应问题：
-
如果不同用户的期望值不相同，此时如何比较软件的行为和用户的期望值？“不一样”从何谈起？
-
如果软件行为因为商业盈利而没有达到（或有损于）用户期望，也算作Bug么？
-
软件的行为是否一定要追求和用户期望保持一致呢？
个人理解：
- 比如微信上线的“拍一拍”功能，上线后用户体验有褒有贬，有的人认为很有趣，增加了互动的方式；有的人则认为毫无增益，十分反感，那么此时可以说明“拍一拍”功能是Bug么？笔者认为不能单纯地以软件行为与用户期望值是否一致判定是否为bug，软件的一些基础功能（大部分用户都有相应的期望值的功能，比如书中的启动崩溃的例子）应当毫无疑问地达到用户的期望值，而软件的一些扩展功能（比如“拍一拍”）应当秉持“风物长宜放眼量”的态度，不能因为不能达到大部分用户的期望值就过分苛责软件的行为，当然软件行为也不能因为存在部分用户的肯定而忽视批评的声音，两者应当是不断磨合的关系（比如后续增加了“拍一拍”撤回的功能，反感的用户也逐渐适应并使用拍一拍功能），只有彼此的正向反馈才能促进软件的发展和提升用户的体验。
- 比如大部分用户都期望看视频的时候没有广告，但是各类视频软件都不约而同地为了盈利投放广告，此时软件的行为与用户的期望值并不相符，也并不能算作软件的Bug，毕竟如果软件完全以用户期望为导向，而不考虑自身生存，可能软件本身便会不复存在了，所以笔者认为软件开发设计的导向应当不仅仅局限于用户需求，应当综合多方面的因素和考量。
- 在触摸屏诞生之前，大部分用户对手机的需求（期望）恐怕仍然停留在希望按键手机有更多的功能，可以更加好用吧，所以有时用户的期望存在一定的局限性，但同样不可否认的是，正是少部分用户的需求推动了硬件或软件的发展，进而拓展了大部分用户的期望空间，所以如果置身于历史的长河中，软件的行为和用户的期望更像是一种交替前进的状态，并不是单方面的追求，而是携手共进，此时再回首看一看那些“Bug”，不过是一朵朵浪花罢了。
2.单元测试
原文参见《构建之法》第2章第1节
单元测试必须由最熟悉代码的人（程序的作者）来写。代码的作者最了解代码的目的、特点和实现的局限性。所以，写单元测试没有比作者更适合的人选了。
相应问题：
如果程序的作者在程序的设计实现阶段便忽略了对某些情况的考量，此时再由作者构造单元测试，是否仍然不能注意到这些在程序设计实现上的漏洞呢？
个人理解：
虽然程序的作者最为熟悉自己的代码，可以较快地构造出对应的单元测试，但是这些单元测试只能保证当前已经实现程序的正确性，并不能说明当前的程序设计是完备的，如果此时由他人构造一些单元测试，则有可能发现程序本身的漏洞，才可以让程序尽可能的完备。
3.goto的使用
原文参见《构建之法》第4章第3节
函数最好有单一的出口，为了达到这一目的，可以使用goto。只要有助于程序逻辑的清晰体现，什么方法都可以使用，包括goto
相应问题：
goto是否能有助于程序逻辑的清晰体现
个人理解：
从1968年的一篇名为《 Go To Statement Considered Harmful》的文章，作者Edsger Wybe Dijkstra提出不加限制地使用GOTO语句应当从高级语言中废止，因为它使分析和验证程序正确性（特别是涉及循环）的任务变得复杂，到现如今程序语言的教学中不推荐使用goto语句，这一切已然可以说明在程序中不写goto语句是一份共识，那么再在程序设计实现时使用goto则可能影响团队中他人对代码的理解，对他人而言并不是一种程序逻辑的清晰体现，反而影响团队的开发效率。
4.结对编程
原文参见《构建之法》第4章第5节
结对编程中驾驶员和领航员的角色要经常互换，避免长时间紧张工作而导致观察力和判断力下降。
相应问题：
驾驶员和领航员不应当是各有所长、各司其职么？如果互换的话，会不会不能达到开发效率的最大化？
个人理解：
结对编程的两位程序员存在水平上的差距，程序员A可能更擅长架构设计或构造测试，程序员B可能更擅长代码实现，因而存在驾驶员和领航员两种角色，如果结对编程追求的是1+1>2的效果，那么角色互换则可能让两者在并不擅长的领域内工作，无法达到提升项目质量、提高开发效率的效果。
5.萝卜与白菜
原文参见《构建之法》第17章第4节
由于萝卜的设计有缺陷，导致模块非常复杂，萝卜也成了唯一了解其模块的开发人员......所以我们要让“萝卜快了不洗泥”的人慢下来，这样能减少他们的危害，我们要胡萝卜和大棒并用。我们的大棒就是“小强地狱”
相应问题：
“小强地狱”是否真的合理？
个人理解：
一个团队内的各个成员在完成任务时应当有明确的分工，团队开发过程中也应当有明确的DDL，如果某位成员提前完成开发任务，应当立即进行测试或者探讨更优设计，而不应当着手开发新的功能，项目的每一步进展应当是扎实有效的。所以笔者认为通过小强地狱让萝卜慢下来不如让萝卜在开发的同时更注重提升代码的质量，在开发的过程中尽量通过优化设计减少问题的产生而不是等到问题出现再进行修复，当然这仅仅是笔者目前的粗浅理解，后续结合软工开发经验观点也会有所改变。
二、调研源代码版本管理软件
相同之处
Github/Bitbucket/Gitlab均可以
- 利用git进行版本控制，管理项目
- fork/clone 仓库
- 支持Markdown
- 问题跟踪
- 双向认证
- 高级权限管理
- 提供功能丰富的API
不同之处
| GitHub | GitLab | Bitbucket |
|---|---|---|
| 提供了API用于应用程序开发 | 提供了API用于应用程序开发 | 集成了多个API和服务 |
| 提供错误跟踪系统，用于提高编码质量 | 提供了错误跟踪系统以及基于Web的代码编辑选项，用于提高编码质量 | 使用语义搜索来分析编码语法，以提高编码质量 |
| 支持导入Git，HG，SVN和TFS | 支持Git，Google Code，Bitbucket和FogBugz | 支持Git，Google Code，SourceForge，HG，CodePlex和SVN。 |
| Free Plans允许托管无限的公有代码仓库，随时进行clone, fork 和 contribute，对磁盘使用没有限制。但是，项目不能超过 1 GB和单个文件不能超过 100 MB。 | cloud-hosted plan 允许无限数量的用户在无限数量的公共和私有项目上进行协作，并且每个存储库有 10GB 的空间限制 | Small teams plan 允许 5 个成员加入，公有/私有仓库均免费。 |
调研持续集成/部署工具
Gitlab CI
1.选取OOpre2Task1课程作业作为本次集成的测试，并利用JUnit对代码进行测试
2.配置.gitlab-ci.yml文件，并上传至gitlab仓库（注：当前因没有权限直接在gitlab创建个人公开仓库，目前利用原OO课程作业仓库调试）利用CI在线编译，在线运行，在线测试
Github Action
1.相同程序部署到github的个人仓库中
2.根据文档编写.github/workflows/maven.yml，触发action编译运行
CI/CD相关
CI/CD 是一种通过在应用开发阶段引入自动化来频繁向客户交付应用的方法。CI/CD 的核心概念是持续集成、持续交付和持续部署。作为一个面向开发和运营团队的解决方案，CI/CD 主要针对在集成新代码时所引发的问题
GitLab-CI是一套配合GitLab使用的持续集成系统，从GitLab 8.0后就默认集成了GitLab-CI，并且所有项目默认启用，只要在项目仓库的根目录添加 .gitlab-ci.yml 文件，并且配置了Runner，那么每一次MR / push 都会触发CI Pipeline
actions可以用来作为CI/CD使用，但是它不只是CI/CD，因为它其实是一组docker容器所组成的Workflow，Workflow的触发条件，公共仓库目前仅支持push，私有仓库则支持check_run、create、delete、issue comment， commit comment, pull request等许多事件, 通过这些事件，可以完成除了CI/CD之外的许多自动化操作，例如接收到issue comment之后使用telegram bot发送通知等等
4.CI/CD工具作用分析
- 持续集成中的任何一个环节都是自动完成的，无需太多的人工干预，有利于减少重复过程以节省时间、费用和工作量
- 开发和测试人员可以共用gitlab的pipeline界面或github的workflow界面, 测试人员能够随时把握代码部署的情况，同时还可以通过交互界面手动启动pipeline(workflow)，自己去部署测试，从而节约和开发之间的沟通时间
- 持续集成可以及早的发现代码中的问题，及早解决
- 代码库存越是积压，就越得不到生产检验，积压越多，代码间交叉感染的概率越大，下个
release的复杂度和风险越高，持续集成可以保证团队开发人员提交代码的质量，减轻了软件发布时的压力
5.CI/CD工具对比
Gitlab CI与Github Actions的系统对比详见Continuous Integration Comparison，在此不再赘述
由于Gitlab的Runner已经预先配置且作业要求中提供了最小示例，以及Github actions的文档较为详细，所以在两个平台部署CI的过程较为顺利，希望随着软工课程的不断推进，可以切实感受到CI/CD带来的便利和对项目质量的提升。
