软工第一次作业

Q	A
这个作业属于哪个课程	2020春北航计算机学院软件工程(罗杰 任健)
这个作业的要求在哪里	个人博客作业
我在这个课程的目标是	掌握一个实际项目开发的工具、过程，并总结经验，为以后的工作打好基础
这个作业在哪个具体方面帮助我实现目标	快速了解软件工程并深入思考；了解主流的版本管理工具

1.看书的问题

1、关于第一章中的“软件的非连续性”

非连续性（Discontinuity）

人们比较容易理解连续的系统：增加输入，就能看到相应输出的增加。但是许多软件系统却没有这样的特性，有时输入上很小的变化，会引起输出上极大的变化

不太明白这里的“非连续性”是如何影响软件的开发成本？即上文提到的“这种输入上的极小变化引起输出上的极大变化”是如何影响开发的速度与成本？

2.第二章---单元测试应覆盖所有的代码路径

单元测试应覆盖所测单元的所有代码路径，包括错误处理路径。

我对这一点持不同观点。

当一个项目非常庞大的时，对代码所有路径的100%测试覆盖需要编写的测试代码量可能比代码本身还大，测试工作量非常大；而其中的很多很多简单的代码，这种情况下我觉得不必为其编写测试代码。如何平衡测试效率和测试覆盖率是测试人员需要磨练的东西

3.第三章---软件工程师思维误区之过早泛化

软件的“软”还表现在它可以扩展

作者在书中提到了过早泛化的问题，但我想现实中更多的可能是项目扩展性的不足。比如OO课上，我自己包括身边的一些人在完成一个专题的编程作业时，常常都会因扩展性不够而重构。这种给项目扩展性的度如何把握？

4.第四章-----关于结对编程的如何落地

在结对编程中，任何一段代码都至少被两双眼睛看过，被两个脑袋思考过

在我看来，结对编程的复审可以以一个函数为单位，这里说的“任何一段代码”不必细化到每一行代码，在复审时对方只需要对这个函数的功能做一定的单元测试+了解这个函数的实现思路即可。在开发前设计好各个函数的输入输出以及边界情况等，就像OO课程里的JML一样;同时通过代码规范检查等机制来限制每个函数的大小、行数，这样在对方复审时检查工作会容易进行得多，有利于结对编程的落地

5.第九章---高效的团队讨论

平时开会讨论特别杂乱的原因是，在每个具体时段，每个人在扮演的角色不同，别人也没能理解不同人的角色和出发点

开会讨论杂乱的另一原因还有参会者与议题的相关性。有些会议存在这样一个问题：议题过于庞杂，有些议题无关乎一些与会者当下正在做的或者是相关的工作和领域，被强行凑进一个会，这时的会议的讨论与与会者其实是无关的，也浪费了与会者的时间。

2.软件” 和 “软件工程” 等词的出现时间、地点和提出者

软件：一说最早出现在由Richard R.Carhart于1953年8月出版的兰德公司研究备忘录中 ，一说由 Paul Niquette于1953年提出，链接

软件工程： 最早源自1965年6月发布的《computers and automation》的服务清单中，由玛格丽特.汉密尔顿提出

3.软件工程发展的过程中有什么你觉得有趣的冷知识和故事

Linux的来源：

Linus Torvalds 林纳斯·托瓦兹 是linux操作系统内核的发明者。最初他想将其命名为"Freax"，意思是自由（"free"）和奇异（"freak"）的结合字，并且附上"X"这个常用的字母，以配合所谓的类Unix的系统 。在开发系统的前半年里，他把文件以文件名“Freax”存储。Torvalds考虑过Linux这个名字，但是因为觉得它过于自我本位而放弃了使用它。

为便于开发，在1991年9月，他把那些文件上传到了赫尔辛基工业大学（HUT）的FTP服务器。Torvalds在HUT负责管理那个服务器的同事Ari Lemmke，觉得“Freax”这个名字不是很好，就在不咨询Torvalds的情况下，把项目的名字改成了“Linux”。之后，Torvalds也同意“Linux”这个名字了：“经过多次讨论，他承认Linux这个名字更好。在0.01版本Linux的源代码的makefile里仍然使用‘Freax'这个名字，在之后‘Linux'这个名字才被使用。所以，Linux这个名字并不是预先想好的，只是它被广泛接受了而已”

4.目前流行的源程序版本管理软件和项目管理软件及各有的优缺点

目前各版本管理和项目管理软件使用人数：

Github：4000多万 （2019年底，源自github2019年年度报告）

其余版本/项目管理软件使用人数只有2018年及以前的数据,源自wikipedia

Name	Users	Projects	Alexa rank (lower = more popular)
Assembla	Unknown	526,581+[45]	23,052 as of 9 September 2019[46]
Bitbucket	5,000,000[47]	Unknown	989 as of 9 September 2019[48]
Buddy	Unknown	Unknown	73,518 as of 9 September 2019[49]
CloudForge	Unknown	Unknown	339,271 as of 9 September 2019[50]
Gitea	Unknown	Unknown	209,697 as of 9 September 2019[51]
GitHub	31,000,000[52]	100,000,000[52]	65 as of 9 September 2019[53]
GitLab	100,000[54]	546,000[55][k]	2,146 as of 9 September 2019[56]
GNU Savannah	93,346[57]	3,848[57]	100,244 as of 9 September 2019[58]
Launchpad	3,965,288[59]	40,881[60]	12,344 as of 9 September 2019[61]
OSDN	54,826[62]	6,294[62]	8,529 as of 9 September 2019[63]
Ourproject.org	6,353[64]	1,846[64]	1,191,954 as of 9 September 2019[65]
OW2 Consortium	Unknown	Unknown	610,052 as of 9 September 2019[66]
Rosetta code	Unknown	Unknown	62,045 as of 9 September 2019[67]
SEUL	Unknown	Unknown	1,268,571 as of 9 September 2019[68]
SourceForge	3,700,000[69]	500,000[69]	407 as of 9 September 2019[70]
Name	Users	Projects	Alexa rank (lower = more popular)

一些版本/项目管理软件优缺点：

Github

• ​ 优点

1. 有着海量的代码资源
2. 上手快，设计简洁，代码托管、版本控制比较方便
3. 提供免费的公有仓库

• ​ 缺点：

1. 国内访问速度较慢

SVN

• ​ 优点

1. 使用方便，操作简单，很容易就可以上手
2. 统一控制访问权限控制，利用代码安全管理
3. 以服务端代码为准，一致性高

• ​ 缺点：

1. 需要连网，连不上网就无法提交代码
2. 不是本地化操作，如果要删除分支，也是需要将远程的分支进行删除，这会导致大家都得同步
3. 所有操作都需要通过服务端进行同步，这会导致服务器性能要求比较高。如果服务器宕机了就无法提交代码了

Microsoft TFS

• 优点

  1. 与VS契合
  2. 任务版上能将需求、项目进度一览无余
  3. 集成了项目管理、版本控制、BUG 跟踪，能有效实现 SCRUM

• 缺点

  搭建、维护tfs比较复杂

Gitlab

• ​ 优点
  2. 同样是基于web的git仓库，易于代码的版本管理
  2. 相比于github，提供免费的私有仓库

• ​ 缺点

  1. 相比于图形界面，命令行操作更流行，因而有一定的学习成本

Trac

• 优点
  1. 非常灵活，可定制自由度高
  2. 权限体系比较完备
• 缺点
  1. 用户偏少
  2. 中文化不完整
  3. 核心功能少，不装插件没法用

Bugzilla

• 优点
  1. 开源
  2. 有中文版本支持
• 缺点
  1. 只能管理缺陷

Github截图：

SVN使用截图：