软件工程第1次阅读做业

第一部分 读后疑问

问题一

在第一章 绪论的第7页 我看到了这样的一段文字：

若是一架民用飞机上有需求，用户使用它的几率是万分之一，你还要作这个功能吗？

个人疑问是：每个细微的需求都须要获得知足吗？
这里像是玩了一个文字游戏，由于只提到了需求使用的几率是百万分之一，可是并无作其余的任何条件约束。我按照我最真实的想法，选择了直接忽略掉这个需求，但以后才知道这个百万分之一是飞机的安全方面的诉求，那么它的确是有必要去作的。也许是写在绪论这里为了言简意赅，因此说的比较不严谨，我认为大多数使用几率极低的功能都是能够砍掉的，由于面面俱到是一种臃肿的实现方式，咱们应该为用户提供简明方便的使用方法。好比咱们经常使用的office办公软件，也许它也能够包含许多百万分之一律率使用到的功能，那么它的界面和下拉菜单对于用户来讲仍是友好的吗？因此我认为商业化的软件反而要勇于删减本身的功能，从而提供良好的用户体验。
其实本书在后面的章节对于相似的问题也给出了很好的解决方案。在书中的第8章 需求分析中已经有提到，对于需求要考虑他们的优先级，要着重实现那些杀手功能，而且参照在166页提到的功能的象限划分，对于一个软件的不一样功能，咱们能够采用维持、抵消、优化、差别化和不作五种不一样的方式来应对。对于那些基本用不到的功能而且不是必要需求的杀手功能，我仍是秉承本身的观点，大可不作。

问题二

在第三章 软件工程师的成长 的 3.2思惟误区 49页 我看到了这样的一段文字：

过早优化是一切罪恶的根源。

个人疑问是：是否能够在写软件的某个模块的时候进行适度的优化呢？
其实在以前的程序编写时也遇到过相似的问题，好比一个类中定义了不少的属性和方法，而且这些属性和方法在其余的地方也获得了调用，可是若是在总体写完后想要对这个类内部的一些方法进行优化，有时候会增补或者删掉一些属性，或者可能改变某些方法调用的参数、返回值或者是它的功能，那么在其余调用的地方就要进行相应的修改，这样可能会形成很大的工程量而且容易引起新的BUG。若是我自己的软件工程水平不高，没有在写程序前高屋建瓴的想好全部的布局，那么在优化的时候遇到这样的问题就很麻烦，因此我以前会写完一个模块后尝试进行一些优化，而且感受效果也不错。因此我以为这句话说的太绝对了，应该是 对于某些极致优化的过度执著才是一切罪恶的根源。

问题三

在读完第六章 敏捷流程 和 第九章 项目经理 以后我有这样一个疑问：
既然敏捷已经成为了一种风潮，而且在敏捷的体系中你们集思广益，不须要PM来制定什么计划，那么PM这个职位还有存在的必要吗？PM会最终被淘汰掉吗？但我又始终以为一个敏捷的团队也能够拥有一个PM来起到灯塔做用，传统的体系与敏捷的体系能结合吗？

问题四

在第十一章 软件的设计与实现 中提到了构建这个概念，而且在235页有这样的一段话：

在咱们的全球调查中，咱们发现成功的公司中有94%天天或者至少每周完成构建，而不成功的公司绝大多数每个月甚至更少的去作构建``````

个人疑问是：构建具体指的是什么？是说每日对于要作的软件的一个功能的规划吗？由于这本书的名字就是《构建之法》，我理解的构建就是文章对于软件的结构以及团队组成、合做等一整套的方法。但这些都是宏观上的，那么每日要作的构建到底是干什么，怎么干。后文虽然有一个对话形式的解读，可是尚未弄清楚。

问题五

在第十六章 IT行业的创新 中，有这样一段话：

创新的人士的关键特色不是喜欢冒险，也不是躲避风险，而是从错误中回复并继续努力，就像文言文说的“屡败屡战”。

个人疑问是：风险究竟要不要躲避？由于不少的创新对于我的或者团队而言都是极大的风险，好比资金、时间、或者其余机遇。如何评估本身所谓的“创新”是真正的创新，而不是徒劳无功的尝试呢？

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

软件

-什么时候：1935年
-何地：美国
-何人：Alan Mathison Turing
“软件”一词是图灵的一篇题目为“omputable numbers with an application to the Entscheidungsproblem (decision problem)”的论文中提出的

软件工程

-什么时候：1968年
-何地：美国
-何人：Margaret Hamilton
“软件工程”一词是Margaret Hamilton在阿波罗计划期间发明创造出来的

第三部分 软件工程发展过程当中有趣的冷知识和故事

在2012年夏季奥林匹克运动会开幕典礼上，伯纳斯-李得到了“万维网发明者”的美誉。他本人也参与了开幕典礼，在一台 NeXT 计算机前工做。他在 Twitter 上发表消息说：“这是给全部人的”，体育馆内的 LCD 光管随即显示出文字来。

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

Microsoft TFS

-优势：是一个工做流协做的引擎，它容许一个团队使用他们自定义的流程，并使用在项目历史中实时收集起来的一个集中的数据仓库。集成性。版本控制系统和工做项存储器在注册时集成在一块儿。当注册时，能够将其与一个或多个工做项关联。而且任务版上能将需求、项目进度尽收眼底，对小团体适用。
-缺点：TFS经过复杂的看似功能强大配置管理，将联机看作是整个项目周期的常态，这在实际使用中形成极大的不便。能应用起来的团队、公司的数量极少，多数真正用起来，也就是源代码管理这部分，这也仅仅是占TFS极小部分功能。

Github

-优势：基于web，容许你使用Git的源代码管理功能，而且上面有大量的开源程序。
-缺点：访问速度缓慢，对于企业而言使用起来成本较高。

SVN

-优势：SVN容许一个文件有任意都的可命名属性，功能十分完备，而且SVN会关心全部的文件类型，不须要你来手工操做。
-缺点：要将权限控制文件保存为svn支持的UTF-8格式，一个库能够有多个工做目录但一个工做目录只能对应一个库虽然能够更改库位置可是要求很严格，库中文件存放方式，看不到文件真正的内容。并且SVN速度超慢。提交、更新、浏览历史的速度都很慢。

Trac

-优势：力求不影响现有团队的开发过程，良好的扩充性，以里程碑的方式进行项目管理。而且是一个为软件开发项目须要而集成了Wiki和问题跟踪管理系统的应用平台，是一个开源软件应用。
-缺点：功能不是很强大，使用有很大的局限性。

Coding

-优势：支持设置保护分支，被保护的分支只有指定的一些成员才能够写（更新），其余成员只有读的权限。这在开发中能够避免一些重要的分支被成员随便修改。而在默认状况下，项目内的全部成员都有对项目的全部分支的所有权限，包括读、写、删除等等。
-缺点：产品的改进也很是少，基本已经落后。

Bugzilla

-优势：是一个开源的缺陷跟踪系统，它能够管理软件开发中缺陷的提交，修复，关闭等整个生命周期。而且具备强大的检索功能， 用户可配置的经过Email公布Bug变动。
-缺点：是专门为UNIX定制开发的，不是全部的操做系统均可以使用。

Mercurial

-优势：Mercurial 是一种轻量级分布式版本控制系统，采用 Python 语言实现，易于学习和使用，扩展性强。而且它管理起来很轻松。
-缺点：不是很灵活。

排名

-1. github：约31,000,000用户量 -2. SourceForge：约3,700,000用户量 -3. Bitbucket：约5,000,000用户量