软工2021个人阅读作业#2——构建之法和CI/CD的运用

项目	内容
这个作业属于哪个课程	2021学年春季软件工程（罗杰任健）
这个作业的要求在哪里	2021年软工-热身阅读作业#2
我在这个课程的目标是	了解和掌握现代软件开发和项目管理技术，锻炼在大规模开发中的团队协作能力
这个作业在哪个具体方面帮助我实现目标	阅读教材，在自学、发问、回答这个步骤中了解软件工程中基本概念；初步学习CI/CD相关概念和运用

阅读提问

问题一：个人在团队中应该只是一个流水线上的机器吗？

教材P47有如下段落：

软件开发有很多个人的、感情驱动的因素……我总觉得灵感是属于业余爱好者的。我们职业人士只是每天持续工作。今天你继续昨天的工作，明天你继续明天的工作，最终你会有所成就。

在作者关于团队对个人的希望这一小节中，为了说明个人需要在工作中保持理性，引用了Chuck Close所说，但是在我看来，灵感更是一个专业人士所需要的素质，固然在一个团队的合作中，按照规定的代码风格、项目流程来进行开发是极为重要的，但这与灵感和创造力并不冲突。在教材P51页中谈及了人们对职业的态度有哪些等级，对于那些处于第五层——理想的呼唤的人们而言，这不仅仅是工作，更是一种创造。

问题二：结对编程对于在二者能力有一定差距的情况下，其作用到底在“代码复审”还是在“人肉教程”？

教材P79有如下段落：

每个人在各自独立设计、实现软件的过程中不免要犯这样那样的错误。在结对编程中，因为有随时的复审和交流，程序各方面的质量取决于一对程序员中各方面水平较高的那一位。

结对编程是代码复审的一种极致，在两人成组的代码开发中，“领航者”能够更好的监督正在编写程序的一方以免“偏航”，然而，面对能力较为悬殊的两人，能力较弱者在行使审查机制时，是否真的能高于能力较强者的自我审查的作用呢，而能力较弱者在进行代码实现中，能力较强者的审查机制有极大的可能成为另一种编写代码的方式——即你说一句，我写一句，这无论从对于二者的公平性上，还是对开发的效率上，抑或是结对编程所期望的复审机制上，都无从谈起，倒不如是说“带新人”。

问题三：激励一个敏捷的团队的动机是什么？

教材P116有如下段落：

自主管理：以前领导布置了任务，我们实现就可以了，现在要自己挑选任务；每次Sprint结束之后，还要总结不足，提出改进，并且自己要实施这些改进。“自主管理”不等于“没有管理”。

敏捷团队能够不断迭代开发，及时跟进用户需求并保证进度推进和质量，其最重要的能力在于自主管理，然而，对于一个敏捷团队而言，什么是激励他们自主管理和不断迭代的动机呢，或者说，该怎样对敏捷团队整体的贡献进行评价呢，团队内部可以从分工和任务中评判个人贡献度，但是从一个公司的角度，对于敏捷团队的的贡献，应该是用户的满意程度，抑或是迭代开发的次数，还是完成项目的时间花费呢？从哪种角度进行考核，来产生一个既能够激励敏捷团队跟进用户、不断迭代、自我纠错，又能够合理的评价其贡献的方法。

问题四：WBS在分而治之中如何避免子节点的相互覆盖？

教材P178有如下段落：

做好WBS的几个要点：

保证所有子节点覆盖了全部父节点包含的内容。

保证各个子节点不要相互覆盖。

我们在实际的项目划分中，很难做到真正的将子节点任务完全划分开来，在有些任务中，会出现“我中有你，你中有我”的情况，例如，假设在用户注册部分，输入密码中必须包括大小写字母，然而，这一部分的实现可以在前端进行处理后提示用户，也可以在后端处理后反回拒绝注册的信息，在此时，二者在划分中就产生了重合。上例描绘的较为牵强，但是在笔者进行开发的过程中，常常出现分配任务中有着不可避免的重叠而发生类似“三不管地区”的情况，因此，产生了是否真的能够保证WBS进行子节点划分时不产生重叠的方法。

问题五：渐进发布对于用户使用体验和市场评价的影响？

教材P331有如下段落：

又如微软公司在Windows10的发布过程中，同样采用了不同目标人群+不同发布频率的方式：……

自从Windows10以来，微软改变以往大版本更新，采用每半年进行一次小幅度更新的方法提供最新的操作系统，与此同时，也带来了Canary、Windows Insiders等体验版本，然而，这些版本在使用中不够稳定，在我平日的使用中，常常出现蓝屏等现象，大大降低了使用体验，并且，在20H1稳定版本中依旧出现了大面积严重Bug的问题，导致微软更新不得不设置门槛，在这种渐进发布和小版本迭代中，虽然确实能够看到系统在功能上的不断丰富，但操作系统作为个人电脑使用的基础和核心，稳定性是其核心竞争力，然而，在Insiders版本的大量使用和正式版依旧不够稳定的状况下，确实影响到了用户对于这款操作系统的评价，因此，渐进发布的弊端该如何去降低，又如何达到一个利弊的平衡点呢。

问题六：创新者不是一马当先吗？

教材P345有如下段落：

其实，大部分成功的创新者都不是先行者，例如搜索引擎，Google是很晚才进入这个领域的。又如Apple的音乐播放器iPod……

创新不仅仅在于你是否是这个领域的开拓者，Google能拥有世界绝对优势的市场份额，只是因为他很幸运？其搜索引擎依靠算法优势，依靠对用户需求的把握，依靠自身建立起来的Gmail、YouTube等等产品所打造的巨大王国所支撑着，这些都不是创新吗？Apple依靠对美和艺术的产品抓住了用户的心，虽然音乐播放器、手机等早已出现很久，但设计感这种创新依旧让他成为巨鳄。创新不是狭义的仅仅开创了这个领域的产品才叫创新，更何况，如果智能手机的开创者是先行者，大哥大对于智能手机而言又是什么呢。

问题七：刷课软件是否合乎道德和公平？

教材P410有如下练习题：

刷课软件和刷票软件

……

大家都喜欢给分高又可以摸鱼的大水课，然而，这种课总是人满为患的，以前，大家准时等待电脑屏幕面前拼手速，现在，大家一个个写起了脚本软件拼技术。对于这个问题，没有一个法律规定抢课是违法的，但从道德的角度思考，抢课软件是否合乎我们的道德观念呢。有人说，不是所有人都会写脚本软件，只有你这种计算机学院的同学学过这个，这种技术上的不公平，难道真的合适吗？但也有人说，我花了时间学习技术，花了时间实现软件，这就是我应得的报酬，有什么不合适？你行你上啊？而且又不是没课选不能毕业了，有能力就值得更好的。这个问题真的很矛盾，双方各自站在自己的利益上考虑，又谈什么公平与否呢，如何对这种行为的道德或公平与否下结论，真的很让人迷惑。

调研源代码版本管理软件

Github和Gitlab的相似之处

Github和Gitlab都是基于web的git仓库，在很大程度上gitlab是仿照github来做的，它们都提供了分享开源项目的平台，为开发团队提供了存储、分享、发布和合作开发项目的中心化存储的场所。
GitLab和GitHub提供了一个简单的问题跟踪器，可让您同时更改多个问题的状态和受让人。
GitLab和GitHub均提供了广泛的第三方集成。将版本控制系统与其他应用程序集成在一起可以充实您的工作流程，并可以提高开发人员和非开发人员的工作效率。

Github和Gitlab的不同之处

GitLab与GitHub之间的最大区别之一是GitLab的内置持续集成/交付。对于许多开发团队而言，CI可以节省大量时间，并且可以作为一种质量保证的好方法。GitLab免费提供自己的CI，无需使用外部CI服务。

Features	GitLab	GitHub
released	September 2011	April 2008
Free plans	Unlimited public and private repositories	Free for public repositories only
Paid plans	Starts at $39 per user per year	Starts at $84 per user per year
Code review features	yes	yes
Wiki	yes	yes
Bug & issue tracking	yes	yes
Private branch	yes	yes
Build system	yes	yes (with 3rd party service)
Import projects	yes	no
Export projects	yes	no
Time tracking	yes	no
Web-hosting	yes	yes]
Self-hosting	yes	yes (with enterprise plan)
Popularity	546.000+ projects	69.000.000+ projects

调研持续集成/部署工具

GitLab CI

使用OO第一单元第一次作业
新建Maven项目并部署在GitLab仓库
push到远程仓库，开始运行pipeline

GItHub Action

依旧使用OO第一单元第一次作业进行部署
GitHub仓库
配置WorkFlows并push入远程仓库开始部署

使用CI和CD工具后的看法

GitHub Actions的每个job中的steps更像GitLab CI中的stages，二者这种细分、渐进式的持续部署方式，简化了大规模部署的复杂性。
CI/CD工具利用git仓库帮助我们同步、管理源码，并且在此基础上持续集成、部署，让迭代开发更加自动、方便。同时，也提供了相应测试代码覆盖度显示等功能，更人性化、自动化的帮助测试人员进行回归测试、单元测试等等。
个人觉得GitHub Actions还不够完善，且在使用中不如GitLab CI容易上手。