软工第一次作业

在一周之内，快速看完整部教材，列出你不懂的5~10个问题。

问题 1

我在《构建之法》第三版的26页看到这一段话：

问：如果用随机数以增加测试的真实性，好么？

答：一般情况下不好，如果某个随机数导致程序出错，但是下次运行又不能重复这一错误，则于事无补。我们还是要用随机数等方法“增加测试的真实性”，但不是在单元测试中。单元测试不能解决所有问题，不必期望它能发现所有的缺陷。

有这样的疑问，如果我们将每次测试不通过的随机数或程序状态记录下来，不就可以再现错误了吗？书中的描述和你的经验矛盾。比如，在我的实践中，单元测试中最常用的Assert.AreEqual()就可以在之前加一个条件判断，如果不满足，记录下测试的输入（随机数）。有些像log文件的机制。

问题二

单元测试必须有最熟悉代码的人（程序的作者）来写。
代码的作者最了解代码的目的、特点和实现的局限性。所以，写单元测试没有比作者更适合的人选了。

根据我实践的经验，自己的错误和缺点往往很难由自己发现，即使发现所需花费的时间成本也比较大。所以，才需要互测、互评。代码的作者虽然熟悉代码，但脑中倾向于验证代码的正确性而不是检查错误。有些疏忽很明显但容易视而不见，心中想象的代码是完美的，而屏幕上的代码却有失误。罗杰老师在第一节课时也提到，一般公司的开发人员和测试人员比例是1:1，有时甚至可能达到1:7.可见测试人员不可或缺。开发人员同时作测试人员既越俎代庖又效率低下。所以，我不是很理解和信服书作者的观点。

问题三

书中16.3.4提到效能过剩的一些例子：
- 卖电脑的还会宣传CPU的速度么？还有显示器的尺寸、分辨率？
- 数码相机能照多少兆的照片？USB盘的容量？

我认为这些例子不是很恰当。比如，今年Intel的第8代处理器，性能提高了40%，令很多技术人员感叹“这次牙膏挤多了”。而且，大多数的电脑仍会以CPU速度、内存大小、显卡型号为噱头宣传。比如前些天，小米发布会上小米笔记本Pro的宣传。

同时，硬件的性能上去了，软件就会吃掉，用户和软件的需求也随之增长。比如，以前大家看电影都找720P的资源，现在都只找1080P的资源了。硬盘增长空间很快就被用户的贪婪吃掉了。就会出现硬件总是不够用的现象。

问题四

书中16.1.2 迷思之二：大家都喜欢创新 中谈到
不但大众不喜欢创新，甚至连创新者自己也不例外，有些创新者甚至恨创新。

大众不喜欢创新，我可以理解。但创新者为什么也不喜欢创新呢？书中后文举了电话发明的历史故事和雅卡尔改进织布机的例子，并不能有效地证明创新者不喜欢创新，甚至恨创新。从我的经历和听闻来看，大多数创新者还是比较喜欢创新并推动创新的。比如，很多公司都会有内部创业这种机制，以促进创新。

问题五

书中12.4提出“贯穿多种设备的用户体验”谈到
如何争取让你的软件能在各种设备上以最合适的方式交互，但是同一产品在各种设备上有一致的体验。

我们知道UWP（universal windows program)是一次微软统一手机、平板和电脑体验的一次尝试。但到目前为止，手机端几乎已经死了；平板端考二合一续命；PC端上UWP又很鸡肋。反而，安卓和iOS的体验与传统PC有很大不同，却仍被人们接受。这是否意味着一致的体验的失败？

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

软件

最早的在工程上下文中出现“软件”这个术语的公开出版物是在1953年8月Richard R. Carhart的R a nd公司研究备忘录上。wikipedia链接.

软件工程

由Munich技术大学的F.L. Bauer于1968年首次提出。wikipedia链接
Bauer当时是NATO（北约）科学委员会德国代表的同事。1967年，NATO开始讨论“软件危机”，Bauer之后开始使用“软件工程”这一术语以同时囊括问题和解决方案。

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

微软的前CEO鲍尔默在1986年出演的电视广告。在广告中，鲍尔默说出了我国雷人电视广告的经典台词；“不要500刀，不要1000刀，只要99刀”。有视频有图有真相。

上网调查一下目前流行的源程序版本管理软件和项目管理软件都有哪些， 各有什么优缺点？ （提示：搜索一下Microsoft TFS、Git、Mercurial、GitHub、Bitbucket、Trac、Bugzilla、Rational，Apple XCode）?

Git

现在最流行的分布式版本控制系统。由Linux Torvalds在2005年独立在一周时间内完成。关于Git的开发，还有一个有趣的故事。
Linux内核的维护最初是由Torvalds一人负责的，在其他开发者加入后使用邮件系统维护，之后又用一款商业软件BitKeeper进行版本控制。开发BitKeeper的公司在2005年终止了给Linux社区的免费使用许可，理由是社区中的一名开发者试图逆向BitKeeper，违反了协议。Tarvalds发现当时所有免费的版本控制系统都无法满足他的需求，尤其是性能上的。所以，他就决定开发一款新的开源的分布式的版本控制系统，也就是git。

• 优点：免费的开源软件，分布式的版本控制，性能很好，用户量大，网上教程多，易于团队合作的代码控制。
• 缺点：对中文不够友好，使用难度较大（尤其是CLI），原理不易理解。

GitHub

基于git的仓库托管平台。24M用户，67M仓库，117K公司组织（数据来源。被誉为“全球最大的同性交友平台”。

• 优点：交互、功能好，社区十分活跃，拥有大量优秀开源项目，被大量个人开发者和公司组织使用。
• 缺点：github:fi费用过高。

Bitbucket

与Github类似，基于git的仓库托管平台。不过其客户定位为专业团队。拥有5M开发人员和900K队伍（截止2016年9月，来源）。

• 优点：同GitHub，支持小团队（5人以下）的免费私有项目，5人以上收取不同的费用。
• 缺点：作为同类网站，界面、功能等不如GitHub，使用人数也因此更少，不重视个人开发者。

Apple XCode

Mac下的Visual Studio，项目管理工具和集成开发环境。不过比起宇宙最强IDE Visual Studio的强大生产力来就像是个玩具。

• 优点：编译速度极快，极其适合MacOS、IOS等开发人员。
• 缺点：只能在Mac环境中运行，一般认为不如VS。

Microsoft TFS：

Team Foundation Server是微软提供的源代码管理工具，基于Git或Team Foundation Version Control。

• 优点：与Visual Studio深度结合
• 缺点：搭建、维护tfs比较复杂，硬件要求也比较高。

Trac：

Trac作为一个SCM配置管理平台

• 优点：有良好的扩充性；比较完备的权限体系设计；十分灵活，可定制性强，可以和TortoiseSVN集成。
• 缺点：不支持多项目；需求和缺陷没有分离；用 wiki 来替代 Word 等工具编写文档；对中文不友好；核心功能少。

Bugzilla

Bugzilla是基于Web的通用bug追踪器和测试工具。

• 优点：开源软件，被很多大公司使用，self-hosting，版本的向下兼容，强大的检索能力，有汉化。
• 缺点：Windows下安装困难。

Rational

Rational是提供基于业界开放标准的工具、最佳方案和服务，用于开发商业应用和构建软件产品及系统，包括移动电话和医疗系统等设备使用的嵌入式软件。

• 优点：背靠IBM这颗大树；采用迭代式开发模式，以降低项目风险；专注于构架，开发出更有弹性的系统，以迅速适应不断变化的业务需求。
• 缺点：用户量小，面向企业