问题一

在第一章 绪论的第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用户量