2020BUAA软工个人博客作业

17373010 杜博玮

项目	内容
这个作业属于哪个课程	2020春季计算机学院软件工程(罗杰任健)
这个作业的要求在哪里	个人博客作业
我在这个课程的目标是	学习软件工程，培养工程开发能力、团队协作能力，开阔视野
这个作业在哪个具体方面帮助我实现目标	通过通读教材，提出疑惑来构建对软件工程的初步认知

快速看完整部教材，列出你仍然不懂的5到10个问题，发布在你的个人博客上

在2.1.2好的单元检测的标准中给出了单元测试好坏的判断标准，我的问题是关于单元测试的针对方向。

作者在单元测试好坏的判断标准中写道，单元测试应该在最基本的功能/参数上验证程序的正确性且单元测试要快。但是在前面对单元测试的引入中作者通过小故事表达技术模块各项要求最好都可以表示为一个单元测试样例的思想。那么单元测试到底应当针对什么呢？

首先我认为根据单元测试的名字我们可以看出它应当测试基础功能，其他重要功能应当在功能测试、集成测试等领域展开，但是我们有时会利用单元测试来检验一个类或函数的正确性，通过查找资料，我发现单元测试（unit testing），是指对软件中的最小可测试单元进行检查和验证。（参考：单元测试）那么我们是不是应当针对程序中所编写的一个个单元进行验证，而不是针对技术的一个个最基本功能来验证呢，换句话说，单元测试是基于设计层面，还是基于程序方面？在我看来，我们应当专注于程序方面，但我并不能完全说服自己。
在4.3.2中，作者表达了只要有助于程序逻辑的清晰体现，什么方法都可以使用的观点。

我个人对这一观点表示反对。因为一个程序员很难保证自己的思维永远清晰完整，而开放类似于goto之类的方法，完全是给整个程序的正确性埋下巨大的隐患。毕竟大型软件逻辑结构比较复杂，使用goto之类被公认会降低程序安全性并且破坏程序的结构化程度的方法来使程序逻辑清晰完全是得不偿失。我们完全可以通过增加注释，整理代码等多种方式来做到这一点，为什么要使用goto之类的方法呢？
在11.5.5中，作者对小强地狱进行了阐述，在阐述中我们不难发现开发新功能与修复小强之间的矛盾。

在客户与绩效的压力下，开发新功能有着很高的优先级，但是拖着大量小强既导致测试人员无法有效地继续测试，也可能将小小强拖成大小强，在后续的过程中造成巨大的困难。作者介绍了小强地狱的方式来解决这一矛盾，但是我感觉这种按照阈值修复小强的方法做得不够彻底，大量的bug依然会被遗留下来。

在我看来，借鉴ZBB是一个很不错的选择，在一周的开始，开发人员开发新功能，测试人员进行测试，在这一星期的结束，开发人员针对测试人员提出的bug进行修复，下一周继续进行上述工作。

如果一切顺利，开发人员一周内需要解决的bug也就是他们在上周的开发中所产生的bug，这样是不是就可以比较好地解决开发新功能与修复小强之间的矛盾。
在15.1.3中，作者介绍了从代码完成到代码发布时可以采取的不同操作，其中有重写和重构两种解决Bug的思路。

这两种方式各有不同，但都是解决Bug的相当好的途径，同时也会增加大量的劳动量。我的疑问是这两种方法的差异以及各自的应用领域。

在书中，作者介绍了重写与重构的含义。重写是指重新实现原有功能，重构是指在尽量保持原有界面的基础上优化部分代码。

我在网络上发现很多程序员对重写持有很不友善的态度。他们认为重写是一个相当大工作量的工作，成本很高，很多逻辑可能会被忽略，需要花费更多的人力来测试和debug，并且需要重新了解项目的需求，完全重新设计与实现，任务繁重且困难。为了维持正在运行的系统，我们可能还需要一边重写新系统，一边重构旧系统。而且一个需要重写来处理的项目很有可能留下的文档与代码一样混乱不堪，因此在对业务逻辑没有理足够清楚的情况下，大多数人都不推荐重写系统，只有在很清楚地知道代码做什么，但是很难理解那些代码的时候才会重写。

而大家对重构就比较友善了，重构是一种局部式，增量式的活动，我们通过向旧系统中增补补丁来对代码进行逐步的优化，从而逐渐减少代码的混乱程度，增加代码可读性。一般情况下，当代码难于理解，并且团队不能确定它做什么的时候进行代码的重构。（参考：重构？还是重写？）
在12.1.2中，作者对“吃狗食”进行进行了阐述

“吃狗食”保证了开发人员能了解软件功能的实际表现，可以发现很多关于用户体验方面的问题。但是程序员作为软件开发专业人士，对软件构造的看法与用户有很大的区别。那么我不禁想到，不如专门让那些没有程序员思维的体验员进行体验，通过体验员与程序员之间的交流、辩论来改善软件在用户体验方面的问题。

请问 “软件” 和 “软件工程” 这些词汇是如何出现的 - 何时、何地、何人？

在主流说法中软件一词是由John Tukey于1958年发表的论文"The Teaching of Concrete Mathematics"中首次提出的。而Paul Niquette声称自己于1953年10月创造了软件一词，但他找不到任何确切的证据。

实际上软件一词在工程界是由Richard R. Carhart于1953年8月在 Rand Corporation的研究备忘录中第一次提出。（所以即使Niquette所言确为其事，他仍然不是第一个

软件工程则是由Margaret Hamilton在早期的阿波罗项目的研究中提出的。

大家知道了软件和软件工程的起源，请问软件工程发展的过程中有什么你觉得有趣的冷知识和故事？

1982年的圣诞，超过150万的美国儿童得到了自己梦寐以求的圣诞礼物，游戏卡带《E.T.》，这在现在看来是无法想象的。当时游戏巨头雅达利已经在全美售卖了数千万台雅达利2600，这一游戏机进入了全美17%的家庭。然而《E.T.》是一位工程师单人在六个星期内制作出来的赶工之作，整个游戏玩法混乱，内容简陋，音效刺耳，直接导致花费了2500万美元买下《E.T.》版权，准备了400万套的游戏的雅达利公司收获了巨大的失败，本就因为劣质游戏层出不穷而面临困境的雅达利在这一重创下直接崩溃，上百万游戏卡带和主机被掩埋在了美国新墨西哥州的阿拉莫格多垃圾填埋场。整个美国游戏业从此萎靡不振，直到21世纪的XBOX360面世才有所好转。

上网调查一下目前流行的源程序版本管理软件和项目管理软件都有哪些，各有什么优缺点？

在Stack Overflow所做的调查中，一些版本控制系统的使用人数占比如下。（Rational为2017年数据，其余为2018年数据）

名称	使用人数占比	排名
Microsoft TFS	10.9%	2
Git	87.2%	1
Mercurial	3.6%	3
Rational	0.4%	4

而在Wikipedia的使用人数排序中，一些版本控制软件的使用人数如下。

名称	使用人数	排名
GitHub	31,000,000	1
Bitbucket	5,000,000	2
GitLab	100,000	5
GNU Savannah	93,346	6
Launchpad	3,965,288	3
SourceForge	3,700,000	4
OSDN	54,826	7
Ourproject.org	6,353	8

参考内容：Git，Comparison of source-code-hosting facilities

优缺点介绍：

Microsoft TFS

优点：任务版上能将需求、项目进度一览无余，对于小团队而言，比甘特图更有用，集成了项目管理、版本控制、BUG 跟踪，能有效实现 SCRUM，能与 VS 无缝接合。

缺点：搭建、维护tfs比较复杂，硬件要求也比较高。

GitHub

优点：错误跟踪，快速搜索，庞大而有活力的社区，易于协作开发，兼容性高

缺点：GitHub的服务不是完全免费的，如果想要享受GitHub提供的所有功能，需要付费。存在大小限制：文件大小不能超过100Mb，存储库可以托管信息1Gb。

Mercurial

优点：Mercurial为分布式的版本控制系统，可以离线工作，可以不联网就享受版本控制的好处，并且也意味着普通的提交速度也要快的多；学习曲线低；更亲和Windows等

缺点：存在权限控制的问题；分支的时候不能对单独的子目录进行。

Git

优点：适合分布式开发，强调个体；公共服务器压力和数据量都不会太大；速度快、灵活；任意两个开发者之间可以很容易的解决冲突；离线工作。

缺点：资料少（起码中文资料很少）；学习周期相对而言比较长；不符合常规思维；代码保密性差，一旦开发者把整个库克隆下来就可以完全公开所有代码和版本信息。

Bitbucket

优点：对于小团队使用可以使用无限量的免费存储库，不限容量，但是限制 5 名成员。集成 Jira 工具，通过集成的错误跟踪组件，Jira 自动更新有关检测到的问题的信息。提交大文件速度很快。拥有灵活的权限管控，可自定义域名，支持 wiki 等。

缺点：不开源且系统不稳定，使用群体和代码量可能不如 GitHub，国内使用私有仓库的托管平台可能不及 GitLab。

Trac

优点：Trac是一个SCM配置管理平台，意味着它有良好的扩充性；Trac的权限体系比较完备；非常灵活，可以随心所欲的定制，可以和TortoiseSVN集成。

缺点：不支持多项目；需求和缺陷没有分离；用 wiki 来替代 Word 等工具编写文档对于产品策划来说门槛太高了；中文化不完整，美术人员接触起来困难重重；不显示中文名，本地化做得很差；核心功能很少，不安装插件基本上没法用。

Bugzilla

优点：BUGZILLA不收费，且现在有中文版支持

缺点：BUGZILLA只能管理缺陷

Apple Xcode

优点：可以自动创建分类图表；自动提供撤消、重做和保存功能，无需编写任何编码。

缺点：更新版本后，某个插件可能会失效。

参考资料：管理软件的优缺点，git的优缺点，分布式的，新一代版本控制系统Mercurial的介绍及简要入门，GitHub、GitLab与BitBucket应该怎么选?，GitHub 与各代码托管平台比较。

调查完目前流行的源程序版本管理软件和项目管理软件后，请你选择其中至少2个软件来进行动手实践

Git：

使用git在本地保存代码并在修改readme后重新提交。

git真的很好用，尽管已经使用过很多次，但是我依然能感觉到git命令之简洁，功能之强大。但是唯一的问题便是git确实不太好学，即使学会了也实在不容易学懂。

Bitbucket：

使用Bitbucket建立上述git保存的本地代码的远程仓库。

Bitbucket整体而言体验还是很不错的，界面相当简洁，仓库的建立也很简单，唯一美中不足的便是我家的网络似乎不使用一些特殊的方法就无法成功访问。