软件工程-个人阅读作业#2
个人阅读作业#2
一、阅读提问
-
教材中2.1.2节对好的单元测试的标准中提到
单元测试必须由最熟悉代码的人（程序的作者）来写。代码的作者最了解代码的目的、特点和实现的局限性。所以，写单元测试没有比作者更适合的人选了。
单元测试必须由代码的作者来写吗？如果说这是作者对自己的代码的负责，那我觉得合理；但是如果说这是因为作者对自己的代码最熟悉，我认为有点欠妥。确实，了解代码局限性的情况下能有针对性地进行测试，但是并不是所有人都能认识到自己代码的局限性（更进一步说，我觉得只有少部分优秀的程序员有这样的自知之名）。其次，单元测试并不一定要十分了解代码，而只需要清楚被测模块的功能正确性，如黑盒测试。让了解功能定义，测试经验丰富的人去设计单元测试，反而有可能找到作者察觉不到的代码缺陷。
-
教材中3.1节中提到团队对个人的期望，其中第7条
- 理性地工作：软件开发有很多个人的、感情驱动的因素，但是一个成熟的团队成员必须从事实和数据出发，按照流程，理性地工作。很多人认为自己需要灵感和激情，才能为宏大的目标奋斗，才能成为专业人士。著名的艺术家 Chuck Close 说：我总觉得灵感是属于业余爱好者的。我们职业人士只是每天持续工作。今天你继续昨天的工作，明天你继续今天的工作，最终你会有所成就。
对于艺术家Chuck Close所言，我有个疑问，灵感不是职业人士必不可少的一部分吗？在我看来，我们在设计系统时思考出的新的架构，对新问题的解决方案，都算是一种广义上的“灵感”。从这个视角来看，职业人士并不缺乏灵感，只是灵感往往与实践结合，在几番洗刷下只剩下经得住现实检验的作品。不知这样想是否算咬文嚼字，但我认为在职业人士的坚固经验和知识基础上诞生的灵感，也许稀少，但难能可贵。
-
教材3.3节在讲解专与精的关系时提到三种人：单人乐队、交响乐作曲家和只研习某一乐器的乐手。我认为这三者代表这不同的“广”与“精”的程度（这里我并不确定教材中的“专”是否为技能广泛的意思，故用“广”代替）：单人乐队代表各类技术都能实用，不过并不能将它们系统性的结合；交响乐作曲家代表能利用各类技术设计系统，但并不清楚实现的细节；只研习某一乐器的乐手代表精通某一技术。对此，我有一个问题：只研习某一乐器的乐手这样的角色能否适用于计算机领域呢？
-
教材中6.1节对敏捷的流程简介中对冲刺阶段有介绍
冲刺期间．团队通过每日例会（Scrum Meeting）来进行面对面的交流，团队成员大多站着开会，所以又称每日立会大家依次报告：
我昨天做了啥
我今天要做啥
我碰到了哪些问题
每日立会强迫每个人向同伴报告进度，迫使大家把问题摆在明面上。同时团队要启动每日构建，让大家每天都能看到一个逐渐完善的版本。这样的每日立会是否会适得其反？毕竟会议的时间开销并不能忽略，每个人在会议中关注的问题也不尽相同，有的人可能在会议结束后疑惑仍然存在。这样久而久之可能会产生抵触心理，工作的推进单纯为了应付会议。如果每位成员将进度和问题报告给同一个能对项目进度有总体把控的负责人，由这位负责人来衡量哪些信息应该直接公布，哪些问题需要开会解决，会议需要哪些人参与，这样是否有更高的效率呢？
-
邹欣老师的博客园讲义的结对编程中提到
要避免的误区——
- 不分情况强迫每个任务都用结对编程的方式, 或者固执地遵守一些教条 (例如 "结对的成员必须水平相当..." 等等)
对于课程中的结对项目而言，结对的成员水平可以不相当吗？虽然说结对编程会出现两人的水平一高一低的情况，但这往往是水平高的人进行指导，水平低的人进行学习，有培养的目的在其中。但我认为如果是效率和质量优先的项目开发上（我认为课程中的项目符合这个特征），水平不等的两人往往会变成一重一轻的局面，一人编程一人旁观。
二、调研源代码版本管理软件
相同之处
GitHub、Gitlab、Bitbucket三者都是基于 Git 做版本控制的代码托管平台，支持基础的仓库拉取、克隆、分支、推送等功能，团队协作流程基本相同。此外还有代码审查、进行问题跟踪、仓库的权限管理、第三方集成等功能。
不同之处
GitHub：
- 如果是开源项目的开发，GitHub无疑是最优的选择。
- GitHub的仓库、用户基数大，可以对仓库watch、star、fork、follow，有评论、搜索、共享等功能，庞大的社区中有着各式各样的经验和技能分享。
- GitHub支持导入Git，SVN，HG，TFS。
- GitHub本身并非开源，可拥有免费的私有仓库但同时最多只能有三个协作者。
GitLab：
- GitLab没有像GitHub那样强大的社区功能，因此代码的私有性更强；
- GitLab在团队协作上更细致，比如Private、Internal、Public三种不同的访问权限，以及Guest、Reporter、Developer、Master、Owner五种不同的角色。
- GitLab只支持导入Git。
- GitLab本身是开源的，可以用来部署在个人的服务器上。
Bitbucket：
- Bitbucket集成了Jira工具，对习惯Atlassian服务的人十分友好。
- Bitbucket支持导入Git，CodePlex，Google Code，HG，SourceForge，SVN。
- Bitbucket并不开源，对最多5名成员的团队的仓库免费，适合小团队开发。
三、调研持续集成/部署工具
1.GitLab-CI
本次使用的是OO课程的pre2_task0仓库，由于刚学OO课程时没有使用maven进行项目管理，所以新建了pre2_task0分支进行GitLab-CI的配置。
-
build和test的运行结果
-
build的详细信息
-
test的详细信息
通过在仓库中配置.gitlab-ci.yml文件，可以在每次pull/push等操作后触发CI流程，通过GitLab Runner进行构建和测试，实现自动化。此外，CI的所有流程在GitLab上都是可视化的，不仅提升了效率，也有利于开发部门和测试部分之间的沟通交流，提高了团队协作效率。
2.GitHub Action
GitHub的yml文件配置与GitLab略有不同，这里根据GitHub提供的模板并进行少量修改，同样达到简单地构建和测试的目的。
-
build和test的运行结果
-
build的详细信息
-
test的详细信息
利用GitHub Action，同样能实现项目编译、测试、部署的流程。利用GitHub庞大的开放社区，对一些常用的、通用性强的CI/CD操作，开发者可以直接引用他人现有的Action。此外，GitHub Action还支持开关issue，添加label等事件触发。
3.GitLab-CI与GitHub Action对比
GitLab和GitHub的CI/CD总结对比（参考GitLab vs GitHub）
| GitLab-CI | GitHub Action | |
|---|---|---|
| Yes | 支持非第三方的内置CD | No |
| Yes | 自我管理的网站 | Yes |
| Yes | 拥有良好的生态 | Yes |
| No | 拥有市场 | Yes |
| Yes | 无需第三方插件/工具的CI/CD充分集成 | No |
| Yes | 内置的Kubernetes部署和监控 | No |
| Yes | 自动CI/CD Pipeline配置 | No |
| Yes | 无需第三方插件/工具的内置CI-CD安全性扫描 | No |
| Yes | 允许团队安全协作的Security Dashboard | No |
| Yes | 无需第三方插件/工具的，集成在CI-CD Pipeline容器注册表 | No |
对于适用区间，也许可以从GitLab和GitHub的开放性考虑：如果是要进行开源项目的开发，GitHub Action可能更适合；如果是私有性更强的项目，应该多考虑用GitLab-CI。就我当前的使用手感来说，两者的配置方式略有不同，但也相差不大。此外，GitHub Action对运行过程有着分层次的记录，速度也更快。
