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文件相对简单。现在只是能照葫芦画瓢,也没有进行什么实质有意义的部署,希望在今后的学习中能够真正掌握这些。

posted @ 2021-03-17 19:56  MadokaHomura  阅读(148)  评论(1编辑  收藏  举报