【BUAA 软工博客作业】个人博客作业

项目	内容
课程：2020春季软件工程课程博客作业（罗杰，任健）	博客园班级链接
作业：热身作业，阅读并撰写博客	作业要求
课程目标	学习大规模软件开发的技巧与方法，锻炼开发能力
作业目标	阅读教材，回答问题
参考博客	详见文中各处引用

Part I 列出5个不懂的问题

Question I 单元测试必须由写程序的人完成

原文在讲述单元测试时，在2.1.2节中提到：

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

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

我对这一段的描述尚存在一定的争议。为什么单元测试作者来写更适合呢？我并不完全觉得。在之前的程序编写经验里，有些时候一个函数的比较隐藏bug作者一般比较难自己找出来，因为作者对自己程序的逻辑结构太清晰太自信了，以至于在每一次自我复查的时候都难以发现，在构造测试样例的时候，也是按着自己完成相应功能的思路去思考的。在去年的一次OO作业就因此得到了比较低的分数。当时写完程序后，用自己写的测试数据自动构造程序进行对拍测试，却没有测试出自己的bug来。等到最后换了一个思路写数据构造器才测试出bug来。事后思考觉得原因在于，程序作者往往太熟悉自己的逻辑结构，在进行测试数据构造时往往会构造一些自己熟悉的数据类型，而作者一些难以想到的数据类型，往往就是自己程序忽略处理的数据类型

因此，我认为，写单元测试的人不一定必须是作者。当然程序作者最熟悉程序结构，写起来会方便很多。我觉得，单元测试可以由两三个人完成，由作者之外的合作伙伴提供一些独特的测试数据，由作者来完成编写。这样测试的可能会更加全面。

Question II 过早优化，过早泛华：何时为过早

在讲述软件工程师的个人发展中，3.2节里提到过早优化，过早扩大化/泛化的概念，并且告诫程序员不要过早的干这些事，其中提到

一个工程师在写程序的时候，经常容易在某一个局部问题上陷进去，花大量时间对其进行优化，无视这个模块对全局的重要性，甚至还不知道这个“全局”是怎样的。

那么什么时候才算是过早，什么时候才算是合适优化，扩大化/泛化的时候呢？作者告诫不能过早的考虑这些事情，但是如果考虑的太晚了可能会导致原编写的模块需要大量的重构。按照作者的逻辑，猜测答案是在局部模块完成后，大概看到全局布局时再考虑优化，扩大化/泛化。那么全局和局部有没有更加具体化的定义呢？如果等到看到全局结构时再进行优化是否会太晚？导致大量细节需要重构设计？

Question III 关于goto语句

在讲述代码设计规范时，4.3.2节中提到：

函数最好有单一的出口，为了达到这一目的，可以使用goto。只要有助于程序逻辑结构的清晰体现，什么方法都可以使用，包括goto。

作者提到为了使程序逻辑结构清晰体现，可以使用goto。但是总所周知，goto语句很有可能导致程序控制流紊乱，以至于众多专家建议不要使用goto语句。而且大量的使用goto，是否会使程序内部跳转语句过多，导致多次进行寄存器存取降低程序的效率？那么如果为了有助于程序逻辑结构的清晰体现，可否使用一些宏定义来代替？宏定义的名字可以取一些容易让程序员读懂的名字，这样也有助于提高逻辑结构的清晰，并且不会扰乱程序原本的控制流。

Question IV 分而治之，如何分

原文在讲述用户需求分析时，8.7节讲述了一种方法叫做分而治之，并且提供了一种分而治之的结构WBS，其中WBS有其中几个规则

1、保证所有子节点覆盖了全部父节点包含的内容。

2、保证各个子节点不要相互覆盖。

3、叶子节点要保证足够小，能在一个里程碑中完成。在通常的软件项目中，叶节点的成本最好不要超过两周。如果团队成员从常理出发，认为叶节点不宜再分下去，那就可以停止。

4、从结果（Outcome）出发构建WBS，而不是从团队的活动（Action）出发。

其中这里第二点说明保证各个子节点不要相互覆盖。但是万一存在一种需求使得存在不同的子需求团体一定存在某一功能是重复的该怎么办，能否用数据库理论那一套E-R图来描述是否会更清晰？这样不同团体的同一功能可以不需要重复实现，并且分析过程也可以清晰展示相互的关系。另外Outcome具体指的是什么呢？是指模块的功能还是指需求的子团体呢？

Question V 兼容性测试和配置测试，易用性测试与可访问性测试

在讲述软件测试时，13.1.2节将测试分成了两个部分，功能测试和非功能测试，另外每个部分也细分了多种类型的测试。其中非功能测试其中有以下几个

测试名称	测试内容
Compatibility Test	兼容性测试
Configuration Test	配置测试——测试软件在各个配置下能否正常工作
Accessibility Test	可访问性测试——测试软件是否向残疾用户提供了足够的辅助功能
Usability Test	易用性测试——测试软件是否好用

其中的兼容性测试和配置测试的内容是否存在重合？兼容性测试是指不同设备下的兼容还是指软件新旧版本的兼容？如果是前者是否与配置测试重合？可访问性测试是否是易用性测试的一部分？

此外在非功能测试中有一项为效能测试，效能测试在书中解释为在正常的软件设计负载中，能否完成令用户满意的服务质量。这一项测试是否可以归到功能测试的范畴中？毕竟在一定时间内反馈用户需要的结果也算是功能的一个部分，如果效能测试不通过，则是否说明功能设计存在bug？

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

软件一词最早是由John Tukey提出的，他在1958年发表的论文《具体数学的教学》中提出，比OED的引用要早两年。参考维基百科：

In 2000, Fred Shapiro, a librarian at the Yale Law School, published a letter revealing that Tukey's 1958 paper "The Teaching of Concrete Mathematics"[10][11] contained the earliest known usage of the term "software" found in a search of JSTOR's electronic archives, predating the OED's citation by two years.

软件工程一词最早是由Margaret Hamilton，在开展研究阿波罗项目的时候提出的软件工程概念，参考维基百科：

When Hamilton started using the term "software engineering" during the early Apollo missions,[61] software development was not taken seriously compared to other engineering,[62] nor was it regarded as a science.

Part III 请问软件工程发展的过程中有什么你觉得有趣的冷知识和故事？

第一款数字化电脑游戏被开发出来时，难以成为商品，没有获得任何的盈利

现在的视频游戏已经成为了最受瞩目的程序开发成果，然而历史上第一款数字计算机游戏则遭遇巨大失败。第一个电脑游戏出现于1962年，由麻省理工学院的计算机程序员Steve Russell与其团队一同编写，这款名为《太空大战》的游戏耗费了他们近200个小时。该游戏允许两名玩家分别控制两艘飞船，目标是击中并摧毁对方飞船，并且玩家还需要躲避屏幕中代表星球的小白点。如果玩家撞上这些星球，则游戏失败。虽然Russell和他的团队从未在这个游戏说的任何收益，但必须承认如果没有这一突破我们可能永远不会拥有如今蓬勃发展的视频游戏产业。（参考自知乎）

1961年，麻省理工学院的学生史帝芬·罗素与他的同学试图设计以PDP-1作为游戏平台的电子游戏，因为当时的电脑大多借由打孔卡或磁带来输入及输出资料、令人感到乏味，而PDP-1有显示器的设备，使他们下此决心。1962年开发出了《太空大战》，设计的灵感是受到爱德华·艾默·史密斯的《透镜人》和《云雀》两部小说所启发。

由于当时PDP-1价值120000美金，对一般民众而言过于昂贵，使《太空大战》难以成为商品。但游戏程序在美国各学校广为流传，最初用来设计《太空大战》的PDP-1现在位于美国加州山景城摩费菲尔的计算机历史博物馆展出。（参考自维基百科）

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

各个版本控制软件的优缺点

Git

• 优点：适合分布式开发，每一个个体都可以作为服务器。每一次Clone就是从服务器上pull到了所有的内容，包括版本信息。公共服务器压力和数据量都不会太大。速度快、灵活，分支之间可以任意切换。任意两个开发者之间可以很容易的解决冲突，并且单机上就可以进行分支合并。离线工作，不影响本地代码编写，等有网络连接以后可以再上传代码，并且在本地可以根据不同的需要，本地新建自己的分支。
• 缺点：学习周期相对而言比较长。不符合常规思维。代码保密性差，一旦开发者把整个库克隆下来就可以完全公开所有代码和版本信息。
• 参考博文

Microsoft TFS

• 优点：是对敏捷，msf，cmmi等项目、过程管理、过程改善的支持。任务版上能将需求、项目进度一览无余，对于小团队而言更有用。
• 缺点：能应用起来的团队、公司的数量极少，多数真正用起来，也就是源代码管理这部分，这也仅仅是占TFS极小部分功能。
• 参考博文

GitHub

• 优点：GitHub提供Git存储库服务，基于web，允许你使用Git的源代码管理功能，或者其特性。GitHub提供Git存储库服务，基于web，允许你使用Git的源代码管理功能，或者其特性。
• 缺点：可能不是捕捉创意过程和记录创意点子的最佳工具。对于这种特殊功能模拟可以选择LayerVault 或其他相似工具。之前，我们已经强调过Github非常适用代码跟踪，但是却不是最好的设计跟踪工具。将图片内容转化为代码，或者将设计用于产品设置，看起来依旧不是那样顺利。
• 参考博文

Bugzilla

• 优点：检索功能强大。审核机制安全。网络用户界面友好。配置设定丰富多样。安全策略细致和产品分类方案完备。
• 缺点：只能管理缺陷。
• 参考博文

Apple XCode

• 优点：能够自动建立分类图表。自动提供撤消、重作和保存功能，无需编写任何编码。
• 缺点：更新版本后，某个插件可能会失效。
• 参考博文

Trac

• 优点：力求不影响现有团队的开发过程，良好的扩充性，以里程碑的方式进行项目管理。非常灵活，可以随心所欲控制可以和SVN集成.
• 缺点：功能不是很强大
• 参考博文1，参考博文2

Bitbucket

• 优点：对于小团队使用可以使用无限量的免费存储库，不限容量，但是限制 5 名成员。集成 Jira 工具，通过集成的错误跟踪组件，Jira 自动更新有关检测到的问题的信息。提交大文件速度很快。拥有灵活的权限管控，可自定义域名，支持 wiki 等。
• 缺点：使用群体和代码量可能不如 GitHub，国内使用私有仓库的托管平台可能不及 GitLab。系统不够稳定。
• 参考博文

各个在线版本控制平台的使用人数统计

统计数据来源于维基百科

手动实践

git

下图是本地的git bash，将尝试使用git从远程代码库clone代码到本地，其中远程代码库是去年OO课写的一个项目。

git的强大之处在于他可以帮你记录每一次版本的所有文件内容，能够帮你统计不同版本之间的差异，使得在版本控制过程中帮你决策留下哪个版本。下图是add和commit流程，每一次commit过后git就会在本地记录一次版本

github

github是在线的版本控制平台，配合git使用，能够将你本地的代码push到远程github服务器上。github的好处在于第一他可以将代码开源，各方各界的程序员都可以看到你的代码并为你提出意见，第二他可以做一个远程仓库，当你要切换主机编写代码时，就可以使用github配合git来做远程的版本控制。下图是创建一个项目的流程。