个人阅读作业#2
个人阅读作业#2
| 项目 | 内容 |
|---|---|
| 这个作业属于哪个课程 | 2021春季软件工程（罗杰 任健） |
| 这个作业的要求在哪里 | 个人阅读作业#2 |
| 我在这个课程的目标是 | 初步掌握软件开发技术 |
| 这个作业在哪个具体方面帮到我 | 阅读与思考《构建之法》，了解git和CI/CD |
阅读提问
Q1：结对编程中如何选择搭档
我认为结对编程中搭档的选择很重要，那么选择与自己能力互补的搭档比较好还是与自己能力相近的搭档比较好？
在结对编程中，因为有随时的复审和交流，程序各方面的质量取决于一对程序员中各方面水平较高的一位。（《构建之法》 4.5.2）
从这段话可以看出结对编程是取长板，两个人可以优势互补，对程序各方面质量的提升很有帮助，而且在自己不足的方面遇到比自己优秀的人，对自己这个方面的能力提升有很大帮助。但是这样可能会导致在一个人特别强的方面会占主导地位，另一个人出于心理压力或者能力劣势插不上什么话，违背了结对编程的最初目的。
选择与自己能力相近的搭档就像驾驶飞机的驾驶和副驾驶，两个能力相近的人可以实现角色的互换，避免长时间紧张的工作，这对效率也是一种提升。两个人水平相当，在交流中更加能取得一种对等的状态，更加可以放松的表达自己的观点、参与决策。但是同时，如果两个人对问题的理解深度相同，即使有很大程度上的交流可能只能停留在当前的层次，所以我认为相似的两人结对编程对程序质量提升的效果不如互补的两个人。
Q2：敏捷团队中的测试人员的作用
了解到在敏捷团队中，队员的工作内容与传统团队有较大的不同，书中对Scrum Master和开发人员介绍得很详细，所以我对测试人员的工作还有一些疑问。
以前规格说明书由PM来写，测试由测试人员来做，现在每个人都全面负责，自己搞定规格说明书，和别人沟通，同时自己搞定测试。（《构建之法》 6.3）
有敏捷专家建议测试人员可以担负起产品负责人的部分责任，同时掌握验收测试流程，对产品的最终质量负责。（《构建之法》 6.2）
从这两段话，可以看出在敏捷开发中测试人员主要工作是在冲刺验收期，那么在敏捷开发的初期和中期，测试人员需要做哪些工作？敏捷团队中的测试人员与传统团队中的测试人员有什么区别？
Q3：如何平衡软件产品的利益相关者之间的矛盾
在《构建之法》8.2中介绍了很多软件的利益相关方，每一方提出的需求和意见很有可能是有冲突的，书中并没详细说明如何平衡这些冲突。例如，客户的需求是便宜好用的软件，系统/应用集成商需要从软件中牟利，两者需求相悖。当软件需要支付较高费用时，往往会出现盗版软件、破解版软件，反过来伤害了商家的利益。
可以看出，如果不能很好平衡各方的需求反而会对各方利益造成损害，那么应该如何平衡各方需求的尺度，减少类似这种事件的发生呢？或者说，这种平衡应该视具体情况而定，那么是否有一些需要遵循的标准呢？
Q4：“小强地狱”这种按照小强的数量判断是否需要修复bug的评判标准是否合理
我们都是按优先级来进行的，开发新功能的优先级远大于修复小强的。
如果开发人员的小强（Bug）数量超过一规定值，则此君被送入“小强地狱”，在地狱中，他唯一能做的就是修复小强，直到小强数量低于此阈值。（《构建之法》 11.5.5）
可以看出，“小强地狱”的唯一评判标准是小强的数量。我的理解是，数量不能成为判定是否必要修复小强的唯一标准，有一些bug会影响产品的总体运行，比如导致测试人员不能测试一些相关的技术点，或是对其他人的开发流程产生影响，比如在思路、数据上对他人有误导，我认为这些bug即使数量很少，也需要立即修复，否则会影响团队中其他成员的进度。一些bug不会导致严重的连锁反应，可以考虑积攒起来，用一段时间集中修复，避免在修复bug和开发新功能之间来回横跳，提高效率。
Q5：公司的短期实习生应该怎么培养
在项目开始之前, 有很多队员还没有接触过编程语言（例如C#），导致PM在分配任务时很难用时间来衡量，就拿写一个Web Service这一模块来说，一个熟练的程序员可能只需要两个小时，而对于初学者来说，就得先花两天来理解Web Service的实现机制和原理。在有限时间的催促下，导致一些紧急的任务不断向高手集中，而初学者的任务越来越少。这时应该怎么办？ （《构建之法》 11.6）
这种现象在实习中非常常见，实习生对公司的项目不了解，需要花一段时间上手，但是学生往往利用假期进行实习，实习的时间很短，所以很多同学去实习只被安排做一点很基础的工作，甚至与实习项目无关，像是做excel，做ppt，可能对公司而言没有影响公司的正常效率，但是对实习者来说不能从实习中收获什么，白白浪费时间。
IT行业是一个强调效率的行业，像这种短期的实习生，既不能让其像老员工那样高效的完成任务，花精力培养也不能给公司带来什么效益就实习结束了，所以短期实习生的处境挺尴尬的。也有很多公司干脆不提供短期实习，实习时长至少都是3个月、6个月，平时课业繁重的同学可能只有大四才有机会实习。那么有什么方法可以让公司愿意花精力培养这种短期实习生呢？
调研源代码版本管理软件
目前使用较广泛的源代码版本管理工具有：GitHub、GitLab、Bitbucket
三者都具备以下基础功能：
- 拉取请求
- 问题跟踪
- Markdown支持
- Fork/Clone Repositories
三者的团队协作流程一般为：
-
创建开发分支
一般使用两个分支，master分支一般用来发布稳定版本，dev分支用来发布开发版本。
除此以外，还有一些常用的临时分支：feature分支用于开发某种特定功能；release分支用于预发布版本；hotfix分支用于bug修补。
使用git创建分支的操作
git checkout -b branchname -
Fork项目到个人的仓库
fork相当于创建这个仓库的副本，这个副本也是一个远程仓库，自己对这个远程仓库有完全控制权。如果没有这一步操作，而是直接
git clone，在本地修改后提交是不能成功的，因为提交到的仓库不属于自己，不具有修改权限。 -
clone项目到本地
-
和团队项目保持同步
设置分支的upstream，与团队项目的远程分支做关联，用途是将此分支设置为拉取远程分支的分支，可以用
git remote -v查看是否设置成功。用
git fetch upstream获取团队的最新项目，用git merge upstream/dev把最新版本合并到本地分支。 -
push修改到自己的项目上
-
请求合并到团队项目上
-
团队项目负责人审核及同意合并请求
项目管理方面
github：是目前全球最大的代码托管平台，同时提供公共仓库和私有仓库，但是私有仓库需要收费，所以对于开源项目而言，github是较好的选择。
gitlab：允许免费设置仓库权限；允许用户选择分享一个project的部分代码；允许用户设置project的获取权限，进一步提升安全性。所以，对于企业等保密性要求较高的项目，gitlab是较好的选择。
bitbucket：对于五人以下的小的团队项目，共有和私有仓库均是免费的。并且拥有集成Jira工具，方便管理团队与项目。
调研持续集成/部署工具
GitLab CI
使用之前的oo pre3task0作为演示，gitlab仓库地址在这里
1.创建maven项目，编写Junit单元测试文件
2.在项目根目录创建gitlab-ci.yml文件
3.push项目，触发CI
GitHub Action
使用之前的oo pre3task0作为演示，gitlab仓库地址在这里
在根目录创建.github/workflows，根据github中的模板以及.gitlab-ci.yml编写action.yml，push到github仓库即可触发。
CI/CD工具使用感受
CI是持续集成，工作原理是将小的代码块推送到Git仓库中托管的应用程序代码库中，并且每次推送时，都要运行一系列脚本来构建、测试和验证代码更改，然后再将其合并到主分支中。
CD是持续交付和持续部署，相当于更进一步的CI，可以在每次推送到仓库默认分支的同时将应用程序部署到生产环境。
只需要编写一次脚本，就可以在每次push后自动检查和部署代码，确保代码符合规范，且整个过程不需要人工干预。
从技术考虑，某种程度上来说CI/CD的测试比人工测试更加可靠。
从产品考虑，CI/CD的使用可以提高代码质量，其往往可以提供代码检测功能，对代码不规范的地方会有提示或者报错。
从需求考虑，CI/CD的使用可以解放重复性劳动力，自动化部署无需人工干预，降低了时间和劳动成本。
| content | gitlab | github |
|---|---|---|
| support for CD-Build in and not third party | yes | no |
| marketplace | no | yes |
| CI/CD fully integrated - no 3rd party Plugins/tools need | yes | no |
| built in Kubernetes Deployment and Monitoring | yes | no |
| Auto CI/CD Pipeline Configuration | yes | no |
| Built in CI/CD Security Scanning-no 3rd party Plugins/tools needed | yes | no |
| Security Dashboard enabling Security Team collaboration | yes | no |
| Container Registry integrated within the CI/CD Pipeline - no 3rd party Plugins/tools needed | yes | no |
