2021软工--个人阅读作业2

软工个人阅读作业2

项目	内容
这个作业属于哪个课程	2021春季软件工程（罗杰 任健）
这个作业的要求在哪里	2021年软工-个人阅读作业2
我在这个课程的目标是	学习软件开发技术，培养团队协作能力
这个作业在哪个具体方面帮助我实现目标	初步了解软工的整个流程以及实际工作中会遇到的问题；尝试持续集成/部署，为之后的团队项目做准备

1.阅读提问

问题1

2. class vs. struct

如果只是数据的封装，用struct即可

——《构建之法》第4章 两人合作

这里是在谈论如何处理c++中的类，作者给出的class vs. struct对比结果也很简单。我对c++中类与结构的对比没有非常系统的认识，平时编程的时候也只是能用struct就不用class。参考这篇博客，很多时候用struct替换程序中的class也不会产生什么问题，但是struct更适合看成是一个数据结构的实现体，class更适合看成是一个对象的实现体，这也算是对书中的话的进一步诠释吧。

问题2

1960年代，程序员Melvin Conway就总结了一个康威定律：

一个机构设计出来的系统，它的体系结构注定会沿用这个机构的内部交流模式

——《构建之法》第5章 团队和流程

如果根据康威定律，那么是否意味着团队在开发不同需求的软件的时候，或者说企业偏向于开发某一种特定需求的软件的时候，会采用不同的团队结构使得开发的效率得到最大化？

问题3

用户调查问卷看似很容易，其实大有门道，下面是调查者一些常见的错误

b.使用含糊不清的形容词、副词描述时间、数量、频率、价格等。

例如：最近、有时、经常、偶尔、很少、很多、相当多、很贵、很便宜。这些词语对不同用户和在不同语境中有不同的意义。

c.让用户花额外的努力来回答问题

——《构建之法》第8章 需求分析

在日常生活中我们总是会接触到很多形式的调查问卷，其中有不少是采用了模糊不清的形容词等，还有一些会引入等级（比如1代表非常讨厌，5代表非常喜欢，从1-5中选择一个数表示对某事物的喜爱程度），其实质也是模糊不清的形容。从用户角度来看，这些问题有时候会让人不知所措，但是采用这种模糊的表述我认为也是有好处的：

1.将程度等级化，利于处理数据得出较为准确的统计学结论

2.过于量化描述会导致出现文中c的问题，让用户花更大精力去完成问卷

我认为比较好的解决方法是尽量将模糊表述用数字范围来表示，例如100~1000元，每周5~10次等。这种描述既存在模糊的余地，又能让每一个用户能准确理解。

问题4

12.1.6 用户体验和质量

好的用户体验当然是所有人都想要的，如果它和产品的质量有冲突，怎么办？牺牲质量去追求用户体验么，用户能接受吗？

——《构建之法》第12章 用户体验

这里作者将这个问题抛给了读者，并在后面讲了一个故事。初读故事我对它的概括是：GE公司总裁韦尔奇曾对核磁共振机提出“牺牲质量去追求用户体验”，专家们讨论后并未执行，最后被竞争对手抢先。看起来作者通过这个故事仿佛有非常强的指向性，即应当“牺牲质量去追求用户体验”，我对这种观点持反对态度。

后来我在重读这个故事的时候发现，中间出现了“他又问，对于那些不需要太高精度的检查，能否牺牲一些成像质量，换取用户的良好体验呢？”，才意识到我没能看清事情的全部。这里还是强调了“不需要太高精度”，即在不需要很高质量的前提下尽可能地提升用户的体验。

我认为这里还是需要针对具体的情况具体分析，不能一概而论，针对不同的产品找到合适的用户体验和质量的平衡点。

问题5

文中在第13章“软件测试”中提到一种“探索式”的测试，大多指随机进行的、探索性的测试。文章中也提到“探索式测试太多是团队管理不佳的一个标准”。尽管是随机进行的，“探索式”的测试应当主要放在软件开发和测试的什么阶段能取得最大效益？还是说对于软件开发的每个阶段都进行一定的探索式测试？

问题6

成功的公司有价值观——追逐利润

——《构建之法》第16章 IT行业的创新

我认为这里的观点有些以偏概全了。或者说这里所说的“公司”特指自由市场下不受政府影响的公司，或者说这里的“利润”应当理解为广义上的利益（尽管书中所举例子均为狭义的利润）。华为花很大精力在自主芯片以及自主操作系统上，这绝不是在追求短期的利润，确是在追求长期的利益。成功的公司和企业也要担负一定的社会责任。

2.调研源代码版本管理软件

参考这篇文章

相同之处：都能采用git作为分布式版本控制系统；都有Group方便小组成员共同进行代码管理、测试以及部署；都有拉取请求、代码审查、内联编辑、问题跟踪等功能；都支持Markdown

不同之处：

• Github：GitHub 是第一个供“用Git进行版本控制系统的软件开发项目”使用的基于Web的代码托管服务，是目前全球最大的开源社交编程及代码托管网站。GitHub 的 Free Plans 允许托管无限的公有代码仓库，随时进行clone, fork 和 contribute，对磁盘使用没有限制。但是，项目不能超过 1 GB和单个文件不能超过 100 MB。对于开源项目十分友好。

• GitLab：GitLab 是一个利用 Ruby on Rails 开发的开源应用程序，实现一个自托管的 Git 项目仓库，可通过 Web 界面进行访问公开的或者私人项目。GitLab可以在上面创建私人的免费仓库。GitLab让开发团队对他们的代码仓库拥有更多的控制，允许设置项目获取权限，不让所有人都看到所有的代码。

• Bitbucket：BitBucket 是 2008 年创建的源代码托管网站，采用 Mercurial 和 Git 作为分布式版本控制系统，同时提供免费账户和商业计划。Bitbucket 的 Small teams plan 允许 5 个成员加入，公有/私有仓库均免费。Mercurial更好上手，而Git提供了更为丰富的操控细节。

3.调研持续集成/部署工具

3.1.GitLab CI

选取OOpre2Task0课程作业作为本次集成的测试

仓库地址：https://gitlab.buaaoo.top/oo_2019_homeworks/oo_2020_preview2_18373110_pre2_task0

3.2.Github Action

相同的项目上传到github仓库中

仓库地址：https://github.com/zzy18373110/oo_pre_task2_0

3.3.CI/CD理解

• 什么是CI/CD

  • CI：持续集成注重将各个开发者的工作集合到一个代码仓库中，通常每天会进行几次，主要目的是尽早发现集成错误，使团队更加紧密结合，更好地协作。
  • CD：持续部署是一种更高程度的自动化，无论何时代码有较大改动，都会自动进行构建／部署。

• GitLab CI的特点

  • 主要由两部分组成
    • gitlab-ci server ：负责调度、触发 Runner，以及获取返回的结果，无需用户配置。
    • gitlab-ci runner ：负责执行自动化 CI 的宿主，需要用户自己配置，Runner 可以存在多个。
  • Gitlab CI的触发为Git提交检索.gitlab-ci.yaml文件触发
  • Gitlab CI本身设计为Config as Code将CI/CD配置托管在项目中，避免每个人手工配置的CI或还有不一致带来的问题。

• Github Action特点

  • GitHub Action 通过将持续集成的原子操作封装成 Actions，再基于 Workflow 流程定义，将多个 Action 组装成可复用的模板，实现 GitHub 事件更新后自动触发执行 Action 流程。

• 实际使用体验

  GitLab CI 相较于Github Action更加容易上手，.yml文件相对简单。现在只是能照葫芦画瓢，也没有进行什么实质有意义的部署，希望在今后的学习中能够真正掌握这些。