个人阅读作业#2——软工模式&CI/CD
| 项目 | 内容 |
|---|---|
| 这个作业属于哪个课程 | 2021春季软件工程（罗杰 任健） |
| 这个作业的要求在哪里 | 个人阅读作业#2 |
| 我在这个课程的目标是 | 从实践中学习软件工程相关知识（结构化分析和设计方法、敏捷开发方法、软件测试、软件项目管理、软件开发工具和环境等），培养合作开发能力 |
| 这个作业在哪个具体方面帮助我实现目标 | 通过阅读全面了解软件工程的方法论和具体模式流程，同时调研版本管理软件和持续集成/部署工具 |
一、阅读提问
1. 软件的行为和用户的期望值不一样，一定是 Bug 吗？
1.2.4 节软件工程的目标中有这样一句话
什么是 Bug 呢？简单地说，软件的行为和用户的期望值不一样，就叫做 Bug。
我想到这个问题：软件的行为和用户的期望值不一样，就一定是 Bug 吗？
我查阅了维基百科，其对 Bug 的描述是这样的
根据我的实践，软件的行为与用户的期望值不同可能是出于开发者与用户的期望并不一致，也可能是受运行环境等因素影响。因此我认为，软件行为和用户期望不一致，并不能直接断定是程序本身的错误，也就不好直接定义为 Bug。
2. 变量的命名方法如何选择？各种场景下命名规范的形成有什么内在的原因？
4.2 节代码风格规范中提到
还有一些地方不适合用“匈牙利命名法”，比如，在一些强类型的语言（如 C#）中，对类型有严格的要求，不同类型的值是不能做运算的...在这类语言中，前缀就不是很必要。
这是“匈牙利命名法”的一个不适用场景的分析，我想知道对于其他语言和命名方法，具体情况是怎么样的，因此有了这个问题。
我查阅了一些资料，主流的变量命名方法有 Pascal、Camel 和匈牙利命名法，在一个程序中，这些方法可能是可以交替使用的，比如类使用 Pascal 命名法，而变量使用 Camel 命名法。在使用 IDEA 和PyCharm 两个 IDE 时，能够发现其对于变量的命名有着不同的规范；同时阿里的开发手册上也有对于变量命名的要求。因此我有这样的疑惑，命名方法的选用需要考虑哪些方面的因素，在不同语言和不同科技公司中不同的命名规范是怎么形成的？
3. 如何理解 TSP 原则中”团队的各个成员对团队的目标、角色、产品都有统一的理解“
5.3.7 节讲述 TSP 的原则有下面一条：
- 团队的各个成员对团队的目标、角色、产品都有统一的理解
在一个较大规模软件系统开发中，不同开发者面对的可能只是其中几个功能模块，那么他需要对产品有全局的理解吗？前文也提到，遵循一些设计原则通常会带来一些高昂的代价，类似地，我认为遵循 TSP 的这条原则也需要付出不小的沟通成本。这条原则是否对于大规模的团队模式不再适用？或者说对产品“统一的理解”只局限在自己需要理解的部分？
4. 采用用户调查问卷进行调查时，是否需要设置有效性检查？
8.3 节讲述用户调研方法时提出，可以使用用户调查问卷进行用户调研
用户调查问卷看似容易，其实大有门道
文中列举了一些常见的问卷设置错误，对我很有启发。我想到在我的实际体验中，用户调查问卷有不小的概率并不会得到用户认真的对待。查阅资料后发现，有些调查者会在用户问卷中加入个别特殊的问题，判断作答者是否是认真完成问卷，但代价是可能会引起少量被调查者的反感。那么我们在发放用户调查问卷时，是否需要设置这样的问题？
5. 二维绩效评定体系是否有普适性？团队贡献如何量化？
17.6 节绩效管理中提到：
有些公司实施过二维的评价体系：
完成任务维度：...
团队贡献维度：...
比起单纯根据代码量或者根据犯错频率评定绩效，这种二维评价体系在全面性和合理性上都有明显的进步，但是我认为团队贡献的量化本身存在一定的困难。在我曾经参与的一个课题中，起步阶段有一个被划分成几部分的论文集，每个人需要阅读其中一部分，寻找可以应用于项目的方案。大家都很好地完成了阅读任务，但是最终只会采用一个方案，那么读到这个方案的人是否对团队有着更突出的贡献？在软件开发团队中是否会有类似的大家分别探路的情况？此时如何对团队贡献分级？
二、调研源代码版本管理软件
主要调研了 GitHub 和 GitLab，比较它们之间的异同
相同之处
- 都是使用 Git 作为代码管理工具的代码托管平台
- 在团队流程中，开发者需要先进行 fork（并不是 Git 原生的功能），以完成服务端的代码仓库克隆
不同点
- GitHub 在很长一段时间里，对私有仓库收费，但 GitLab 一直支持免费的私人仓库搭建
- 从使用现状来看， GitHub 是最火爆的开源项目托管平台，其中不乏知名开源项目Spring、MyBatis、React、Vue等；而 GitLab 是企业端 Git 仓库的首选，也是各种私有化项目的优选
- GitLab 的下列特性，可能使得其在私有化项目管理上更加便利：
- 允许用户选择分享一个 project 的部分代码
- 允许用户设置 project 的获取权限
- 通过 innersourcing 让不在权限范围内的人访问不到该资源
三、调研持续集成/部署工具
选用 2020_oo 第三单元第一次作业进行测试，这是仓库
Pipelines：
点击 Stages 下的小圆圈可以看到详细信息：
这是 GitHub 上的仓库
这是测试效果：
（本次测试内容只是一些简单的 assert）
需要注意的点是，maven 倾向于使用约定而不是配置，在约定下，源代码和测试文件均有指定的位置。当源文件和测试文件没有放置在正确的目录下，就可能出现 No tests to run 或者 Cannot find symbol 错误。（没有自己创建过 maven 项目，以为 reimport 就万事大吉了，不知道还有这种约定，白白耗费了许多时间QAQ）
查阅资料，结合实际体验，得到 GitLab CI/CD 和 GitHub Actions 有如下共同点：
- 工作流由多个任务构成
- 使用简单的 yaml 格式文件配置工作流
- Self Hosted and .com
GitLab CI/CD 还有如下优势：
- CI/CD 整合程度很高，完全不依赖第三方插件
- 可以进行自动化的 CI/CD Pipeline 配置
而在 GitHub 中，可以很方便地集成他人的action。
