软件工程第1次作业[通俗易懂]

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

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

在检查编写的代码的过程中，作者往往只能考虑到自己在写程序时考虑到的和遇到的问题，这些问题应该很早就被作者自己解决了，如果在进行单元测试时，由于自己写程序的惯性思维，应该很大可能性会忽略掉其他一些重要的地方。如果选择另外一名，了解程序框架（其实只需要知道各函数的输入输出等少量信息就好，这样反而更容易测试出作者没想到的地方的bug）的人来进行单元测试，效果应该会更好。

4.3.2 “只要有助于程序逻辑的清晰体现，什么方法都可以使用，包括goto。”

在我们一开始学习编程时，老师就一直向我们强调无论是什么原因，都不要使用goto。通过几个学期的学习后，尤其是在学习面向对象，编译之后，更能够感受到当开发一个大型项目时，保持程序的逻辑性，可读性是最重要的。虽然使用goto能够在写程序的时候减少一些工作量，但更多时候，我们会发现可能连自己在前一段时间写的程序都难以看懂，更何论软件工程中多人开发。个人认为如果使用了goto会使得程序后续的可读性，可理解性大大降低。

并不同意作者所说的可以使用goto的理由，总的来说使用goto是弊大于利的。

4.5.4 描述结对编程的细节如下：

驾驶员：写设计文档，进行编码和单元测试等XP开发流程。

领航员：审阅驾驶员文档；监督驾驶员开发流程的执行；考虑单元测试的覆盖率；思考是否需要和如何重构；帮助驾驶员解决具体的技术问题；设计TDD中的测试用例。

驾驶员和领航员不断轮换角色，不要连续工作超过一小时，工作一小时休息15分钟。领航员控制时间。

不同的人之间的编程习惯，思维习惯差别是较大的，而且编程应该是一个连续性的工作，并不能理解这种两个人轮流编写同一段程序的做法。书中所举的驾驶员，副驾驶的例子，和结对编程并不相同，因为例子中的驾驶员和副驾驶并不会互相交换身份，他们之间是一种协作关系，而非一种替换关系，每人的工作都是连续的，同时也会更加熟练。我认为结对编程并不能提高编程，debug的效率。

16.1.4 “迷思之四：创新者都是一马当先…其实，大部分成功的创新者都不是先行者，例如搜索引擎，Google是很晚才进入这个领域的。”

确实如作者所说，计算机领域，尤其是IT中，很多先行者都被淘汰掉了。由于互联网天生的互联特性，我们也发现整个行业逐渐出现了几大寡头，如果提出了一些创新，也经常败在这些互联网巨人的资本之下，这是否意味着未来的IT领域，创新者的生存空间在逐渐缩小？

16.1.5 迷思之五: 要成为领域的专家，才能创新

为什么领域的专家有时候没有领域外的创新者那么有新意？这也是一个很有意思的话题

创新的概念究竟是什么？是像作者所举例子中的创新者一样提出一个全新概念，还是说将一个领域钻研透彻，发掘这个领域的更深之处？对于作者所说的“70%的创新者说他们最成功的创新是在他们的拿手领域之外发现的”，这个70%我是存有一定疑虑的，就像计算机是由一群数学家研究出来的一样，对他们而言，计算机他们是否也是在他们的拿手领域之外发现的创新？可是正是因为没有人研究过这种事物，才更能说明他是创新呀。当那群数学家在计算机领域中取得更多的成果之时，这又到底是不是他们所研究的领域呢？

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

软件：1958年，John Tukey，在其论文”The Teaching of Concrete Mathematics”中提出

维基百科-John Tukey

软件工程：阿波罗11号的软件开发期间，Margaret Hamilton提出

Linux中国开源社区

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

Git的诞生

Linus在1991年创建了开源的Linux，从此，Linux系统不断发展，成为最大的服务器系统软件。Linus虽然创建了Linux，但Linux的壮大是靠全世界热心的志愿者参与的。在2002年以前，世界各地的志愿者把源代码文件通过diff的方式发给Linus，然后由Linus本人通过手工方式合并代码。

到了2002年，Linux系统已经发展了十年了，代码库之大让Linus很难继续通过手工方式管理了，于是Linus选择了一个商业的版本控制系统BitKeeper，BitKeeper的东家BitMover公司出于人道主义精神，授权Linux社区免费使用这个版本控制系统。

安定团结的大好局面在2005年就被打破了，原因是开发Samba的Andrew试图破解BitKeeper的协议（这么干的其实也不只他一个），被BitMover公司发现了，于是BitMover公司怒了，要收回Linux社区的免费使用权。

Linus可以向BitMover公司道个歉，保证以后严格管教弟兄们，嗯，这是不可能的。实际情况是这样的：

Linus花了两周时间自己用C写了一个分布式版本控制系统，这就是Git！

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

请按照最近一两年使用人数的多少， 从多到少排序并说明各自有多少用户（估计），工具的优缺点（可以引用相关资料并注明来源）。

下图为源代码托管服务的用户数，可以从中推测出对应的管理软件的用户数。

维基百科-Comparison of source-code-hosting facilities

Git

优点：

• 免费且开源。
• Git支持分支功能（branch）。如果开发一个新的产品功能，可以建立一个分支，对这个分支的进行修改，而不至于会影响到主支上的代码。
• 可拿Git做备份系统，或者同步多台机器的文档，很方便。
• 支持离线工作。本地提交可以稍后提交到服务器上，不用和集中的代码管理服务器交互。 只有最终完成的版本才需要向一个中心的集中的代码管理服务器提交。
• Git 提交都是原子的，且是整个项目范围的。
• Git 中的每个工作树都包含一个具有完整项目历史的仓库。

缺点：

• 学习成本大。由浅入深的过度很漫长，需要大量时间的投入。
• Git版本库需要频繁的手动维护。

SVN

优点：

• 对目录的组织的管理更加方便。SVN不光对文件做版本跟踪，也会对目录做版本跟踪。因此可以根据项目的需要，对目录结构随时进行修改，可以把现有的目录移动到新的地方。
• 保证提交操作的完整性。SVN对提交操作的处理方式类似数据库的事务处理，要么全部成功，要么全部无效，保证了原子性。
• SVN允许一个文件有任意多的可命名属性，功能十分完全。

缺点：

• 不能离线工作。所有的版本信息都放在服务器上。如果脱离了服务器，开发者基本上可以说是无法工作的。
• 提交、更新、浏览历史的速度慢。耗费CPU资源。
• 代码不能及时提交。强迫使用者即时处理冲突，然后才能提交。
• 不能恢复到历史版本。SVN记录了单个文件的历史版本，但没有记录全局版本，不能恢复到上次的状态。

Microsoft TFS

优点：

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

缺点：

• 搭建、维护tfs比较复杂，硬件要求也比较高。
• 整个系统是用 asp 实现的，用浏览器访问较慢。

Mercurial

优点：

• 学习门槛较低。整体上看，hg需要掌握的命令要比git少很多。
• 可以一键完全恢复到历史版本的某一个切面。
• 封装好。相比git，hg很少暴露一些实现内的细节。
• 照顾 svn 的迁移用户。hg 的很多命令是迁移自 svn 命令的，习惯 svn 命令的团队，几乎可以零成本的切换到 hg。
• hg的版本库不需要维护。

缺点：

• 分支管理不灵活。Mercurial的branch管理和Git相比不是很方便。不适合大型团队使用。

个人认为Git使用率较高的原因

git在全世界范围内的使用量较高，除了上述介绍的git本身的易用性以外，个人认为还跟许多重要项目使用git进行管理也有关系。当然git的易用性，github等托管平台的开放性，也反过来提升了这些项目的使用量。例如在overflow的2018年的调查中，有以下这些有趣的信息：

程序员们最喜欢使用的数据库，其中排名较高的redis，elasticsearch等，都在github上进行管理。

更不用说开发的平台，毕竟研发git的重要原因就是为了管理linux的开发：

最喜欢的开发环境，Visual Studio Code，vim等：