软件工程第一次阅读做业

软件工程第一次阅读做业

做业介绍

项目	内容
做业所处课程	软件工程班级博客
做业要求介绍	做业要求
我在这个课程的目标	学习系统化、规范化、量化的方法在软件开发、操做和维护中的应用
这个做业在哪一个具体方面帮助我实现目标	让我有机会读了《构建之法》这样一本好书，让我对软件工程有了必定的认识

做业正文

第一部分：快速看完整部教材，列出你仍然不懂的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
    
    
    
• 软件工程 (software engineering)
  • 时间：June 1965
  • 地点：a list of services offered by companies in the June 1965 issue of COMPUTERS and AUTOMATION
  • 人物：Margaret Hamilton
    
    
    

第三部分：【附加题】你们知道了软件和软件工程的起源，请问软件工程发展的过程当中有什么你以为有趣的冷知识和故事？

约摸在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 实现的，用浏览器访问至关慢。