一、列举速读一遍教材之后不懂的5到10 个问题
1.书中说到，不经分析就盲目优化是不可取的，所以是在代码编写之前就考虑到优化的部分还是应该先将代码完整实现后再进行优化呢。如何做出一个平衡
2.创业公司失败最主要的原因是没有实际市场需求，那么如何进行准确的市场需求分析呢
3.小组中的人员是水平都平均差不多才好，还是有大牛带小渣这种才好，哪种更加符合实际
4.书中说“大部分成功的创新者都不是先行者”，有的时候真的是教会徒弟饿死师傅，如何看待这一现象
5.商业价值和科学价值如何做出平衡，到底是为了金钱还是为了追求编出特别巧妙的程序的快感
二、 “软件” 和 “软件工程” 这些词汇是如何出现的 - 何时、何地、何人？
软件：第一个写软件的人是Ada(AugustaAdaLovelace)，在1860年代他尝试为Babbage(CharlesBabbage)的机械式计算机写软件。
软件工程这一次是在1960年左右汉密尔顿在MIT计算机科学和人工智能实验室发明的。
三、目前流行的源程序版本管理软件和项目管理软件都有哪些， 各有什么优缺点？
【1】Microsoft TFS
优点：和VisualStudio集成得最好，本身的功能非常强大，并不单单是个源码管理，不过个人用起来一般也就主要用其源码管理功能。
【2】Git
优点：
适合分布式开发，强调个体。
公共服务器压力和数据量都不会太大。
速度快、灵活。
任意两个开发者之间可以很容易的解决冲突。
离线工作。
缺点：
资料少（起码中文资料很少）。
学习周期相对而言比较长。
不符合常规思维。
代码保密性差，一旦开发者把整个库克隆下来就可以完全公开所有代码和版本信息。
【3】Mercurial
更轻松的管理。传统的版本控制系统使用集中式的 repository，一些和 repository相关的管理就只能由管理员一个人进行。由于采用了分布式的模型，Mercurial 中就没有这样的困扰，每个用户管理自己的 repository，管理员只需协调同步这些repository。 更健壮的系统。分布式系统比集中式的单服务器系统更健壮，单服务器系统一旦服务器出现问题整个系统就不能运行了，分布式系统通常不会因为一两个节点而受到影响。 对网络的依赖性更低。由于同步可以放在任意时刻进行，Mercurial 甚至可以离线进行管理，只需在有网络连接时同步。
【4】GitHub
GitHub可以托管各种git库，并提供一个web界面，但与其它像sourceforge或google code 这样的服务不同，GitHub的独特卖点在于从另外一个项目进行分支的简易性。为一个项目贡献代码非常简单：首先点击项目站点的“fork”的按钮，然后将代码检出并将修改加入到刚才分出的代码库中，最后通过内建的“pull request”机制向项目负责人申请代码合并。已经有人将GitHub称为代码玩家的MySpace。
【5】svn
所有的文档都显示SVN可以取代CVS，同时SVN的问题和缺点都被隐藏了。不幸的是，我们并不认为SVN是CVS的替代品，尽管很多缺陷都被修改了。更有甚者，它甚至让人重回CVS。CVS和SVN的比较类似于比较C++和Java。很明显CVS和SVN都远比SourceSafe强大的多，如同C++和Java比Basic强大的多。CVS代表了几乎代码控制系统的所有功能项，尽管有时他的实现并不很方便。SVN修正并添加了一些CVS并不拥的有功能。例如，创建标志和分支dubious，你在编辑文件时其他人不会有任何通知。SVN并不是CVS的替代品，只是个不同的系统，类似于CVS。它有些特有的功能，足以作为采用它的理由。这些功能使他更适合于开发环境，例如对PowerBuilder。下面你可以找到两者的相对优势、劣势。
1 存储类型格式
CVS是个基于RCS文件的版本控制系统。每个CVS文件都不过是普通的文件，加上一些额外信息。这些文件会简单的重复本地文件的树结构。因此，不必担心有什么数据损失，如果必要的话可以手工修改RCS文件。
SVN是基于关系数据库的(BerkleyDB)或一系列二进制文件的(FS_FS)。一方面这解决了许多问题 (例如，并行读写共享文件)以及添加了许多新功能(例如运行时的事务特性。)。然而另一方面，数据存储由此变得不透明。
2 速度
CVS比较慢。
整体而言,由于架构实现的不同, SVN的确比CVS快很多。在网络上它只传输很少的信息并支持更多的离线模式的功能。但这也是有代价的。速度的代价就是巨大的存储（完全备份所有的工作文件）。
3 标志&分支
SVN采用标志和分支而抛弃了其他三件东西，实际上这意味着他们把这个概念替换为在档案库内部复制文件或目录以便保存日志。这样一来，无论标志创建还是分支创建都只是仓库内部的文件复制了。对分支而言：分支不过是在仓库内部的一个单独的目录而已了，不像早期还有些什么交错。对标志而言：已经不能对代码加标志了。在某种程度上说，SVN全文件编号补足了这个缺陷，SVN里整个仓库都有版本号，但不是针对单个文件。
4 元数据
CVS只允许存储文件。
SVN允许一个文件有任意多的可命名属性，功能十分完全。
5 文件类型
CVS最初是为文本文件存储而设计的。因此其他文件类型（二进制，统一码）文件的支持几乎没有，如需要的话则要有其他信息，并且客户端服务器端都要调整。
SVN会关心所有的文件类型，不需要你来手工操作。
CVS允许任意的回滚，在任意一个已递交的版本上，尽管这要花些时间（所有的文件都要分别处理）。
SVN不允许递交后回滚。建议把版本库里好的状态版本加到末尾，覆盖掉损坏的版本。而损坏的版本无论如何也是会存在数据库里的。（SVN的滚回操作实际上是merge操作）
CVS中的“零或一”事务原则根本没有实现。如果检入几个文件的话（加到服务器上），很有可能部分文件完成了，而另几个没有。作为一个潜规则，手工纠正这些并且对余下的文件 (而不是所有文件)一一重复检入。这样这些文件将在两阶段中被检入。SVN的确支持“零或一”事务原则，这是SVN的一大优势。
与vss比较
1. 支持重命名，这对 Java 开发来说非常重要
为了得到更好的代码，开发中需要经常进行重构，重构就经常涉及到文件的重构名，而重命名 VSS中是不被支持的。
2. 开发的时候不一定要锁定。
一方面导致重构不方便，另一方面，不能离线开发，使用 SVN就不同，可以带回家继续开发，回来后，提交就行了。
3. 多平台。
可以支持多个平台下的操作
4. 更好的客户端支持。
Eclipse 中的 VSS Plugin 不如它的 SVN Plugin 好用。一个在 Windows 下用的 SVN客户端TortoiseSVN 也比VSS 的客户端好用（VSS 只有微软提供的一个 GUI 客户端）。
5. 更好地与外围工具集成。
各种各样的外围工具（主要是服务器端），满足多种需要。如果有需要，也可以自己写插件或管理脚本，开放的架构，允许我们这样做。
6. 方便。
一个例子：部署应用的时候，以前的做法是找出一个项目中修改过的文件，更新到服务器上去，可以在服务器上执行 svn export 命令，把代码库中的最新版本导出，完成部署（也可以替换回老版本）。
7. 速度与稳定性看起来都不错。
学习它的管理、它的工作方式，是值得的。而 VSS是一个已经被逐渐抛弃的软件。如果时间不是多得没处用，那么就把时间花在最值得花的东西上面。
1、服务器压力太大，数据库容量暴增。
2、如果不能连接到服务器上，基本上不可以工作，看上面第二步，如果服务器不能连接上，就不能提交，还原，对比等等。
3、不适合开源开发（开发人数非常非常多，但是GAE就是用svn的）。但是一般集中式管理的有非常明确的权限管理机制（例如分支访问限制），可以实现分层管理，从而很好的解决开发人数众多的问题。
优点
1、管理方便，逻辑明确，符合一般人思维习惯。
2、易于管理，集中式服务器更能保证安全性。
3、代码一致性非常高。
4、适合开发人数不多的项目开发。