软件工程第一次阅读作业
作业介绍
| 项目 | 内容 |
|---|---|
| 作业所处课程 | 软件工程班级博客 |
| 作业要求介绍 | 作业要求 |
| 我在这个课程的目标 | 学习系统化、规范化、量化的方法在软件开发、操作和维护中的应用 |
| 这个作业在哪个具体方面帮助我实现目标 | 让我有机会读了《构建之法》这样一本好书，让我对软件工程有了一定的认识 |
作业正文
第一部分：快速看完整部教材，列出你仍然不懂的5到10个问题。
一）出处：第4章 两人合作 P69
函数最好有单一的出口，为了达到这一目的，可以使用goto。
我对书中的这一句话有一点疑问，因为之前老师在教我们语言的时候明确指出尽量不要使用goto之类的跳转指令。当然，如果一个函数非常复杂使用goto统一返回值可能会使结构更清晰，但是我认为如果函数比较简单的话还是不要使用goto比较好。
二）出处：第4章 两人合作 P79
在结对编程中，因为有随时的复审和交流，程序各方面的质量取决于一对程序员中各方面水平较高的那一位。
我不是对这句话有异议，而是有一些由这句话所引发的思考。在本书介绍结对编程的章节中，似乎没有明确指出对结对的两个人的水平的要求。然而我认为，并不是任意的两个人都适合结对，如果两个人水平相差太多，那么结对将失去原本的魅力。就像上面引用的语句所说，结对编程的成品质量由水平较高的那个人决定，那么如果两个人水平差异较大，以至于其中一位几乎对另一位有全方位的水平碾压，那么不论这个高水平者处于驾驶员还是领航员的位置，整个编程的过程将会几乎由他一人执掌，他将不间断地把自己的想法灌输给另一个人，而另一个人就成了完全的“助手”或者“学生”。可以想见，在本课程的结对作业中，这种现象将会发生。这样的情况显然是不合理的，因此我认为结对编程对两名程序员的要求是水平差异不能太大，两人必须都具备帮助对方的能力。
三）出处：第11章 软件设计与实现 P225
“一图胜千言”，人们经常用图形类帮助他们了解概念，强化记忆。思维导图是其中的一个例子…… 思维导图形式灵活，适用于很多鼓励探索、发散思维的场合（如头脑风暴会议），但是它的图形元素缺乏严格的语法和语义。
我觉得作者是想用思维导图和其他更加严谨、更具有工程化特点的图模型做对比，以突出它们的特点。但是对此我有个鸡蛋里挑骨头的小意见，我认为就如作者所说，思维导图是很多鼓励探索、发散思维的场合的选择，而这样的场合一般存在于设计的最初阶段，因此思维导图一定程度上有笔记、会议记录的意思，而其他的图，可以通过思维导图的启发，进行进一步设计而得出，因此我认为把思维导图视为其他图的前置形式更合理一点。
四）出处：第13章 软件测试 P288
阿超：那不一定，即使你的软件产品功能100%符合Spec的要求，用户也可能非常恨你的软件。这时，就说明测试人员没有尽到责任，因为测试人员要从用户的角度出发来测试软件。
我觉得“从用户的角度”这一点不应该是测试人员所关心的，它应该包含在Spec，如果测试人员进行了完整的测试，那么即使最后用户“可能非常恨你的软件”，责任也不应归咎于测试人员。
五）出处：第16章 IT行业的创新 P349
这一章的《迷思之六：技术是创新的关键》小节举了“铱星计划”作为反例来说明技术的创新不一定是创新的关键，创新还有许多其他方面。我同意书中的说法，但是我认为把“铱星计划”作为反例有些不妥。虽然铱星计划是技术创新的代表，但是其失败不能说明技术的失败，因为铱星计划的失败主要是对自身产品定位的不准确以及对市场的错误估计造成的。如果其一开始就把产品定位成极限条件下的户外通讯设施，并制定合理的销售计划，可能其实际销售情况就不会与其销售计划有如今我们见到这样大的落差，而“铱星计划”甚至可能会成为技术创新成功的典范。
第二部分：请问 “软件” 和 “软件工程” 这些词汇是如何出现的 - 何时、何地、何人？
- 软件（software）
- 时间：1958
- 地点：Tukey's paper "The Teaching of Concrete Mathematics"
- 人物：John Tukey
第三部分：【附加题】大家知道了软件和软件工程的起源，请问软件工程发展的过程中有什么你觉得有趣的冷知识和故事？
约摸在1985年，微软的一个叫Steve Hazelrig的工程师在写Mac Excel版本的打印功能，那时候激光打印机很贵，而且离办公室也不近。他懒得经常跑到打印机那儿取打印纸检查打印效果，就写了一个小程序，把要输出到打印机的图像显示在屏幕上，还有一个放大镜功能可以把局部放大以检查每个像素的位置及效果。这时一个PM路过看到了这个小工具，说，这么酷的东西，为啥不做成一个功能呢？
所以后来微软的编辑软件都有了“打印预览”这一功能。然而，用户们并没有正式地要求这一功能。（引用自《构建之法》第9章）
第四部分：上网调查一下目前流行的源程序版本管理软件和项目管理软件都有哪些， 各有什么优缺点？
一）使用人数排行
资料来源：维基百科Comparison of source-code-hosting facilities
| Name | Users | Projects |
|---|---|---|
| Assembla | Unknown | 526,581+ |
| Phabricator | Unknown | Unknown |
| GitHub | 31,000,000 | 100,000,000 |
| Bitbucket | 5,000,000 | Unknown |
| Launchpad | 3,965,288 | 40,881 |
| SourceForge | 3,700,000 | 500,000 |
| GitLab | 100,000 | 546,000 |
| GNU Savannah | 93,346 | 3,848 |
| OSDN | 54,826 | 6,294 |
| Ourproject.org | 6,353 | 1,846 |
二）工具的优缺点
GitHub
优点
- 免费且开源
- 用于敏捷高效地处理任何或小或大的项目。
- Git支持分支功能（branch）。如果你想开发一个新的产品功能，你可以建立一个分支，对这个分支的进行修改，而不至于会影响到主支上的代码。
- 可拿Git做备份系统，或者同步两台机器的文档，很方便。
- 支持离线工作。本地提交可以稍后提交到服务器上，不用和集中的代码管理服务器交互。 只有最终完成的版本才需要向一个中心的集中的代码管理服务器提交。
- Git 提交都是原子的，且是整个项目范围的，而不像 CVS 中一样是对每个文件的。
- Git 中的每个工作树都包含一个具有完整项目历史的仓库。
- 简易的初始化。对于随便写两行代码就要放到代码管理工具里的人来说，再合适不过。
缺点
- 学习成本大。由浅入深的过度很漫长，需要大量时间的投入。
- Git版本库需要频繁的手动维护。
SVN
优点
- 对目录的组织的管理更加方便。SVN不光对文件做版本跟踪，也会对目录做版本跟踪。因此可以根据项目的需要，对目录结构随时进行修改，可以把现有的目录移动到新的地方。
- 保证提交操作的完整性。SVN对提交操作的处理方式类似数据库的事务处理，要么全部成功，要么全部无效，保证了原子性。
- SVN允许一个文件有任意多的可命名属性，功能十分完全。
缺点
- 不能离线工作。所有的版本信息都放在服务器上。如果脱离了服务器，开发者基本上可以说是无法工作的。
- 提交、更新、浏览历史的速度慢。耗费CPU资源。
- 代码不能及时提交。强迫使用者即时处理冲突，然后才能提交。
- 不能恢复到历史版本。SVN记录了单个文件的历史版本，但没有记录全局版本，不能恢复到上次的状态。
- 需手动“cleanup”。很多评论回复这点让他们抓狂。
Mercurial
优点
- 学习门槛较低。整体上看，hg需要掌握的命令要比git少很多。
- 可以一键完全恢复到历史版本的某一个切面。
- 封装好。相比git，hg很少暴露一些实现内的细节。
- 照顾 svn 的迁移用户。hg 的很多命令是迁移自 svn 命令的，目标其实是为了让 svn 用户更容易接受。这使得已经习惯 svn 命令的团队，几乎零成本的切换到 hg。
- hg 的 pull 更多的时候可以让你避免创建分支。hg 好比苹果系统，git 好比 Linux，前者在常用命令上更好用更易用，后者在功能上更强大更灵活。
- hg的版本库不需要维护。
缺点
- 分支管理不灵活。Mercurial的branch管理和Git相比不是很方便。大型团队不愿使用。
Microsoft TFS
优点
- 任务版上能将需求、项目进度一览无余，对于小团队而言，比甘特图更有用集成了项目管理、版本控制、BUG 跟踪。
- 能有效实现 SCRUM能与 VS 无缝接合。
缺点
- 搭建、维护tfs比较复杂，硬件要求也比较高。
- 整个系统是用 asp 实现的，用浏览器访问相当慢。