2021软工-个人阅读作业2

2021软工-个人阅读作业2

项目	内容
这个作业属于那个课程	2021北航软件工程
这个作业的要求在哪里	热身阅读作业
我在这个课程的目标是	掌握软件工程的相关技术
这个作业在哪个具体方面帮我实现目标	了解课程大致流程以及方法论，git，CI/CD

阅读提问

1. 大陆高校中的计算机专业与软件专业是否并不像书中说的那样雷同？

问题出自1.2.2 软件工程与计算机科学的关系：

······大部分老师做的都是偏工程方面的研究（所谓“横向项目”），大部分学生毕业后也投身于解决具体的工程问题，这跟软件学院、软件工程系（院）的研究和培养方案非常雷同。······

这段文字中的大部分老师与大部分学生按上下文指的是计算机专业中的老师与学生。而之所以会对这段描述产生疑问主要是由于它有悖于我自己的直观感受。

首先对于软件工程，当我大致看完《构建之法》后，对其的总体印象更偏向于工程。比如整本书都在向我传授各种工程方面的方法论，丝毫不涉及计算机科学所研究的各种问题（这些问题同样在1.2.2中有所提及）。而对于计算机科学，就我自己在这个专业中的学习经历来看，我们先后学习了计组，操作系统，编译等专业课程，其中每门课程也有对应的编程实验，但关注的焦点都不是如何用“工程化”的方法去实现它，而是如何通过它来加深我们对专业课程的理解。

其次，老师的研究方向以及学生的毕业走向我认为也与书中所说的不大相同。如今正值深度学习大热，学校里各种实验室都在做深度学习相关的研究，学生在研究生阶段甚至本科阶段也都会进入实验室参与到相关方面的研究。

当然，由于当下的学科环境与成书时的学科环境可能已经有所不同了，我用当下的情况去反驳书中的观点可能有些不妥，但总归这也算是我的一个疑惑。

2. 单元测试能由别人来写吗？

问题出自2.1.2 好的单元测试标准:

单元测试必须由最熟悉代码的人（程序的作者）来写。

代码的作者最了解代码的目的、特点和实现的局限性。所以，写单元测试没有比作者更合适的人选了。

我的疑问主要是基于“一个人很难再注意起自己已经忽视的细节”这一想法。即，当我在编码时忽略了一些细节导致程序隐藏着一些错误时，即使让我去写单元测试，我也依然很难在单元测试中体现这些疏漏，也就很难找到隐藏的bug。相反，如果让别人（当然最好这个人也对模块的规格有所了解）来写单元测试，他对这个模块的关注点可能与作者对这个模块的关注点有所不同，或许能更容易地发现那些被忽视的错误。

所以是否由他人来进行单元测试能得到较好的结果。

3. 有关“本函数时间“以及”所有时间“的定义的疑问。

该定义位于2.3 效能分析工具，表2-1中：

调用者（caller）：函数Foo() 中调用了Bar()， Foo() 就是调用者。

被调用函数（callee）：减伤，Bar() 就是被调用函数。

本函数时间（Exclusive Time）：所有在本函数花费的时间，不包括被调用者使用的时间。

所有时间（Inclusive Time）：包含本函数和所有调用者使用的时间。

通过上下文，按照我的理解，”本函数时间“在对应到Foo() 函数中有调用Bar() 函数这个例子时，指的应该是Foo() 函数的运行时间减去Bar() 函数的运行时间所剩下的那部分运行时间。那么相对的（这个相对关系由他们的英文名就可以看出），”所有时间“指的应该是Foo() 函数从第一个语句一直运行完最后一个语句所花费的总时间，这其中包括了Bar() 函数的运行时间，但这样的话就与表中的定义有所冲突。且如果真按照表中关与”所有时间“的定义，也很难理解其究竟想表达什么意思。

4. 给予反馈时，对方接受的难易度是否更基于给予时的态度而不是层次？

问题出自4.6.2 如何正确地给予反馈：

反馈的分为三个层次：

1. 最外层：行为和后果
2. 中间层：习惯和动机
3. 最内层：本质和固有属性
   我们的反馈还是要着重于[行为和后果]这一层面，不要贸然深度到[习惯和动机]、[本质]。除非情况非常严峻，需要触及别人内心深处，让别人悬崖勒马。

书中为了证明在给予反馈时不要轻易进入内层的时候，举了几个例子，但不难看出这些例子专门采用了一种比较”尖酸刻薄“的口吻，比如在被果冻鸽了5分钟后这样说：

果冻，你太自私了，心里都没有别人！你们王屋村的男人没一个好东西！码农都是活该被人鄙视！

但如果我们换种方式说或许不仅能引起别人的重视，还更能让别人接受：

果冻，虽然我不想这么说，但希望你下次还是多注意些吧，心里多考虑考虑别人。

当然，并不是说上面这段反馈有多好（甚至我自己都觉得有点尴尬，但还是认为举个例子比较容易表达清楚意思），但我想表达的中心是：只要你情商够高，你总有办法用合适的手段向别人传达任何层次的反馈。同时，如果你成功地给予了更深层次的反馈，还能从根本上解决别人的问题而不是一次又一次地解决别人的低级问题。

5. 在敏捷流程中，如何保证不同任务间的协调性？

问题出自6.3 敏捷的团队：

以前规划说明书由PM来写······现在每个人都全面负责，自己搞定规划说明书，······

书中提到，在scrum/sprint流程中，会将整个产品划分为几个互相关联的”冲刺“，这里的冲刺也就是之后会被不同人领取的任务。对于这种相互之间存在联系的任务，我认为任务之间的接口是十分重要的，书中前几章介绍的开发流程也强调了一个完整且独立的架构设计的重要性。那么，当由不同人去全面负责一些有关联的任务时，该如何去保证这些任务之间仍然有清楚且明确定义的接口呢。换句话说，是否这种做法相较于那些有独立架构设计的做法，系统的稳定性会变差。

6. 为何课程要求结对项目不能出自同一团队？

这个问题是当我看完4.5 结对编程后产生的。

章节中对结对编程有以下描述：

在结对编程模式下，一对程序员肩并肩、平等地、互补地进行开发工作。他们并排坐在一台电脑前，面对同一个显示器，使用同一个键盘、同一个鼠标一起工作。他们一起分析，一起设计，一起写测试用例，一起编码，一起做单元测试，一起做集成测试，一起写文档，等等。

依据这段描述我认为，结对编程的两个人应该要是在生活中较为熟悉的，否则长时间呆在一起多多少少令人觉得有些难受，而较为熟悉的人一般早就组成一个团队了，那么课程是有意让我们与不那么熟悉的同学进行结对编程还是有其他考虑？这是我的一个疑惑。

此外，如果同属于一个团队的同学通过结对编程先进行一段时间的磨合，那么之后在团队项目中的合作不也会更顺畅一些吗。书中也有提到结对编程对团队的益处：

同时，结对编程避免了”我的代码“还是”他的代码“的问题，使得代码的责任不属于某一个人，而是属于两个人，进而属于整个团队，这样能够帮助团队成员建立集体拥有代码的意思，在一定程度上避免了个人英雄主义。

所以为何无视团队内成员进行结对编程对之后团队项目的好处，而选择禁止团队内成员进行结对编程是我的零一个疑惑。

7. 有关快速阅读教材与”做中学“宗旨的疑问。

这个疑问来自于书中的以下内容：

1. 经过2007年以来的探索，我总结了在16周内让同学通过”做中学“，掌握实用软件工程技术的教学方案。
2. 本书内容具有以下特点：······面向实战，强调做中学。

可以看出来，作者是很看重”做中学“的，但这本教材基本上只介绍了各种方法论，而要求我们在短时间内看完这本教材就意味着我们基本上没有任何实践机会来了解这些方法论的内涵。很令人无奈的一点就是，当我花一周时间终于把这本教材看完之后，我的整个软件工程的轮廓还是十分模糊的，对各种方法论所保留的印象也是非常的浅。所以为何不将阅读教材的任务布置在将要进行相关环节之前，这样不是能在阅读教材用通过相关实践来加深印象，更符合”做中学“的理念吗。

调研源代码版本管理软件

这部分参考自：GitHub & Bitbucket & GitLab & Coding 的对比分析

相同之处：

• git作为分布式版本控制系统
• 拉取请求
• 代码审查
• 内联编辑
• 问题跟踪
• Markdown支持
• 双向认证
• 高级权限管理
• 托管的静态网页
• 功能丰富的API
• For/Clone Repositories
• 代码段
• 第三方集成

不同之处：

GitHub	GitLab	Bitbucket
项目本身不是开源的	是开源的	不是开源的，但提供付费的「产品定制」功能
只支持git作为分布式版本控制系统	只支持git	除了支持git，还支持Mercurial
允许从以下版本管理系统导入：Git，SVN，HG，TFS	只允许导入git，但能从一下平台导入：GitHub，Bitbucket，Google code，Fogbugz	允许导入：Git，CodePlex，Google Code，HG，SourceForge，SVN
允许「follow」其他开发者	不允许「follow」	允许「follow」
Free Plans只允许公有仓库，且项目大小不能超过1GB，单个文件不能超过100MB	cloud-hosted plan 允许无限数量的用户在无限数量的公共和私有项目上进行协作，并且每个存储库的空间限制为10GB	Small teams plan允许公有或私有仓库，但只允许至多5个成员，项目大小快到1GB时会有邮件通知

调研持续集成/部署工具

Gitlab CI

仓库使用OO第三次作业，其中为了配合本次博客作业创建了一个se_hw_2分支.

1. 使用JUnit编写单元测试：

   

2. 配置.gitlab-ci.yml，其中获取覆盖率部分参考了构之有道，建之有法——软工个人阅读作业#2：

   

3. 上传到Gitlab触发CI：

   

4. 查看覆盖率：

   

GitHub Actions

仍然使用OO第三次作业进行测试，将其上传到了GitHub仓库。

1. 在.github/workflows配置workflow：

   

2. 上传至GitHub触发CI：

   

使用CI/CD工具的看法

1. 工具特点、特性描述

CI/CD工具在进行相关配置后，能够自动地为我们进行项目的构建以及测试。

通过对配置文件的设置我们还能针对不同场景（比如不同针对不同分支或不同标签）进行不同的操作，这也为团队的分工以及合作提供了便利。

2. Gitlab CI与GitHub Action对比

就目前对这两个工具的使用来看，我的第一体验是Gitlab CI使用起来流程更加清楚而GitHub Action使用起来更加灵活。

首先课程组为Gitlab CI提供了比较完整的入门教程（而且教程讲的内容与我们的任务十分一致），所以按部就班就下来就好了。而对于GitHub Action，其在自己写配置文件的基础上还可以调用很多已经实现好的Action，在合理的使用下似乎可以更灵活地实现更多的功能。

参考文献

1. 《构建之法——现代软件工程》，邹欣，人民邮电出版社，第三版.
2. GitHub & Bitbucket & GitLab & Coding 的对比分析
3. 构之有道，建之有法——软工个人阅读作业#2
4. GitHub Actions 入门教程
5. github actions初体验(一) ----如何自动化构建maven项目并打包上传docker镜像