第一次阅读作业

一、阅读教材后提出问题

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

作者在讲解软件开发提速中存在的难题时提到了“软件的非连续性”，具体描述是这样的

非连续性（Discontinuity）

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

我理解的非连续性是“计算机的非连续性”，也就是我们常规的计算机采用的都是离散的运算，无法真正表示连续的数据和模型，但这是怎样影响软件的开发速度呢？又或者说这里的“非连续”具体指的是什么呢？

2、关于第二章中提到的“单元测试”

作者在讲解单元测试的技巧和作用时，多次强调了单元测试的路径覆盖率

单元测试应该覆盖所有代码路径。单元测试应覆盖所测单元的所有代码路径，包括错误处理路径。为了保证代码覆盖率，单元测试必须测试公开的和私有的函数/方法。

我曾阅读过Kent Beck大师写的Test-Driven Development: By Example，其中对单元测试的覆盖率有这样的解读

不要测试过多代码

这是一条放之四海而皆准的普遍真理。在利用单元测试核心代码中我看到许多有价值部分。创建这些代码我更多的是根据TDD原则创建而来（尤其是没有产生错误的代码及没有失败的测试）。但是我并不把100% 的代码覆盖率作为最终目标，因为这样没有任何意义。我想，总会有相当多的代码不只是适用于单元测试，即协调/组织类型的代码（我们称之为组成节点将其作为组成root的引用），它们需要一些依赖关系，通过调用几种方法，把代码从这里移植到那里，无需添加任何逻辑，而无需真正干扰数据。由于其沉重的mocks和stubs 的使用，这种编写测试的代码比代码本身要复杂的多。

我完全同意作者对单元测试的重视和强调，因为测试是开发的保障，但在实际开发中，确实存在一些代码因本身十分简单而并不需要过多的测试，甚至根本不需要测试，也有一些代码因为是历史遗留代码或是高危代码而需要着重的测试，我们是否应该追求100%的覆盖率呢？又应该如何平衡测试的重心呢？

3、关于第四章中提到的“结对编程”

作者在书中提到了下面这个问题

身旁的这个家伙老是问问题，他/她不会看书么？我都无法专心工作了

这种情况一般出现在结对两人的水平有差异的时候，对于这个问题，作者给出了解答

每人在各自独立设计、实现软件的过程中不免要犯这样那样的错误。在结对编程中，因为有随时的复审和交流，程序各方面的质量取决于一对程序员中各方面水平较高的那一位。

在企业管理层次上，结对能更有效地交流，相互学习和传递经验，分享知识，能更好地应对人员流动

我对上面的陈述在现实中是否存在留有疑问，现在的企业生产环境十分紧张，企业往往愿意直接招聘高水平的人才然后直接投入困难的工作，而并不倾向于培养新人，同时也存在老人排挤新人等情况，这种开发模式真的在企业生产环境中有落地吗？

4、关于第十六章中提到的“要成为领域的专家，才能创新”

作者对于这个观点的看法是这样的

这个想法看起来没什么错，我们不就是为了成为某个领域的专家，才来上学，拿学位，希望拿到学位之后成为专家，然后再开始这个领域的创新？但是统计数据表明，70%的创新者说，他们最成功的创新，是在他们的拿手领域之外发现的。

之后作者举出了HTTP的诞生、阿里巴巴的诞生等例子，佐证上面的观点。

但是这些例子中有一些共同点，这些创始人大多只是提出了创意，而最终产品的落地依然要依靠专业人士的参与，没有专业人士的参与也仅能是自己的一番空想。此外，这些创新多是在一些空白领域提出的，例如，马云提出阿里的时候，国内并没有电商领域，而倘若在一些既有领域，如深度学习领域，没有相当的学术功底是不可能提出创造性的学术创新的，所以关于这一方面我不敢完全苟同。

5、关于第十七章中提到的“磨合阶段”

作者介绍了团队合作的几个阶段，其中对“磨合阶段”的描述如下

磨合阶段（Storming）就像一个人的青少年时期，充满了对个人、同伴和团队的疑惑和冲突。团队中的一团和气只能维持一小段时间，大家不得不认真地面对问题，开展讨论。随着讨论的深入，有些人会沉不住气，就会出现小的意见分歧和冲突。

那么如何判断一个团队是处于“磨合阶段”还是说这个团队的人员配置本身真的存在问题呢？

二、“软件” 和 “软件工程” 这些词汇是如何出现的

软件最早是由Alan Turing于1935年在他的论文Computable numbers with an application to the Entscheidungsproblem (decision problem)中提出，因世界上第一台电子计算机在1941年才出现，所以图灵提出的只是软件理论。在工程环境中，最早的“软件”一词的发表是在1953年8月，Richard R. Carhart在RAND Corporation的研究备忘录中发表的。
“软件工程”最早出现于1965年6月出版的“COMPUTERS and AUTOMATION”中。玛格丽特·汉密尔顿（Margaret Hamilton）第一次提出了这个名词，尽管最初这个名词的提出并不被人们理解，但最终软件学科确实得到了应有的尊重。

三、软件工程发展的过程中有趣的冷知识和故事

游戏开发应该也属于软件工程的范畴吧，下面分享一个关于史上第一个游戏彩蛋的故事

1978年，当时家用主机游戏市场的老大雅达利刚刚被华纳通讯收购，新老板Raymond Kassar走马上任。

这位大哥来到雅达利之前，在当时数一数二的纺织品公司当老板。或许是习惯了压榨工人，他到了雅达利之后，也不拿游戏程序员当回事。

他上任后，制作人和程序员都被当做“公司资产”，所有卡带上一律全标“雅达利”，不允许把制作人等的名字印在包装或卡带上。

不仅如此，所有参与制作游戏的人都没有版权分成，只有一份死工资，程序员日子过得非常酸苦。

故事的主人公Warren Robinett（沃伦·宾耐特）就是这群程序员中的一员，他当时正在研发第一个动作冒险游戏《冒险》（Adventure）。

沃伦越努力工作越憋屈，最后他终于想出了一个主意：你不是不让我们署名吗？那我在游戏里设计一个隐藏关卡，在游戏里面写上“Created by Warren Robinett”（沃伦·宾耐特制作）。

沃伦写上自己的名字还不过瘾，他特别地把这两行字添加了闪烁效果。

史上第一个游戏彩蛋就这样诞生了。

参考链接：第一个游戏彩蛋的诞生告诉我们：没事别惹程序员

四、目前流行的源程序版本管理软件和项目管理软件都有哪些，各有什么优缺点

1、用户数量与热度

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]

2、工具特点

Microsoft TFS
- 优点：
  - 任务版上能将需求、项目进度一览无余
  - 集成了项目管理、版本控制、BUG 跟踪，能有效实现 SCRUM，能与 VS 无缝接合。
- 缺点：
  - 搭建、维护tfs比较复杂
  - 硬件要求比较高。
GitHub
- 优点：
  - GitHub是一个非常万能的工具。对于任何大小的项目，他都是理想的工具。
  - 他也是伟大的web工作流工具。首先，他可以作为一个版本控制系统和协作工具，用它来发布工作。利用GitHub，你可以将项目存档，与其他人分享交流，并让其他开发者帮助你一起完成这个项目。
  - 他支持多人共同完成一个项目，因此你们可以在同一页面对话交流。
  - 代码不需要保存在本地或者服务器。
  - 你可以按自己的需要恢复、提交出现问题、恢复任何形式的代码，可以避免很多麻烦。
- 缺点：
  - 不擅于捕捉创意过程和记录创意点子。
  - 不擅于跟踪设计。
  - 对GUI的支持不是很好。
  - 学习成本相对较高。
Trac
- 优点：
  - Trac做一个SCM配置管理平台，意味着它有良好的扩充
  - Trac的权限体系是比较完备的设计
  - 非常灵活，可以随心所欲的定制，可以和TortoiseSVN集成。
- 缺点：
  - 不支持多项目
  - 需求和缺陷没有分
  - 用 wiki 来替代 Word 等工具编写文档提高了学习成本
  - 中文化不完整
  - 不显示中文
  - 核心功能很少，需要配合插件使用。
BUGZILLA
- 优点：
  - BUGZILLA不收费
  - BUGZILLA现在有中文版支持
- 缺点：
  - BUGZILLA只能管理缺陷
Apple XCode：
- 优点：
  - 可以自动创建分类图表。
  - 自动提供撤消、重做和保存功能，无需编写任何编码。
- 缺点：
  - 更新版本后，某个插件可能会失效。