1.看完整部教材后，我仍然不懂的一些问题？
Q1：第四章 两人合作
-
4.5.4 “如何结对编程”中提到
“驾驶员和领航员不断轮换角色，不要连续工作超过一小时，每工作一小时休息15分钟。”
这里的“不能连续工作超过一小时，每工作一小时休息15分钟”是否太过绝对？有时候编写某个模块时，工作状态正好，如果突然停下来去休息或者去做其他轻松的事，反而会大大影响自己的工作效率。以我自己为例，如果在很顺手地编写某一段代码时，被打断了一段时间，后面再继续时会感觉之前的“手感”完全不见了。这里是不是应该认为判断自己的效率下降时，选择去休息调整更好？
Q2：第九章 项目经理
- 9.3 提到“PM做开发和测试之外的所有事情”，这里设想一下，如果PM参与开发，是不是能更好地掌握当前的项目进度，从而更好地协调团队内部外部，调配各部门资源和时间，更顺利地完成项目计划呢（这里或许与书中问题中的舵手和划船手不同，PM参与开发并不意味着失去方向，而舵手参与划船则会使得船失去方向、稳定）？
Q3：第十三章 软件测试
- 13.2.7的伙伴测试中，要求测试人员作为开发人员的一个伙伴，并对其模块在本地做必要的回归/功能/集成/探索测试。可是据书中前面所说，最好是开发人员自己写测试，因为开发人员是最清楚自己代码的人。那么，为什么不让开发人员进行测试？或者说给每个开发人员分配一个测试人员进行结对？
Q4：第十六章 IT行业的创新
-
16.1.5 “迷思之五：要成为领域的专家，才能创新”中提到
“统计数据表明，70%的创新者说，他们最成功的创新，是在他们的拿手领域之外发现的”
而关于领域内的专家有时候没有领域外的创新者那么有创意这个问题，是不是因为专家在这个领域研究得多了，被一些固有模式所绊住了呢？还有，如果创新就是知识->金钱的过程的话，那么我们去了解多个领域是不是更有利于我们创新呢？
Q5：第十七章 人，绩效和职业道德
- 17.1“领导力--带领团队成长”中，如果一个团队刚刚成立，有一个人以技术见长，而一个人在相关原理知识方面更胜一筹，两个人的其他如交际能力等很好且相差无几，那么这两个人哪个更适合当团队的领导，带动团队成长呢？
2.“软件” 和 “软件工程” 这些词汇是如何出现的 - 何时、何地、何人？
- The earliest known publication of the term "software" in an engineering context was in August 1953 by Richard R. Carhart, in a Rand Corporation Research Memorandum.（最早在工程背景下出版的术语“软件”是由Richard R. Carhart在兰德公司研究备忘录中于1953年8月出版的。）
- Margaret H. Hamilton began to use the term "software engineering" during the early Apollo missions in order to give software the legitimacy of other fields such as hardware engineering.（<font face="微软雅黑"在早期的阿波罗任务中，玛格丽特·汉密尔顿开始使用“软件工程”这个术语，以使软件具有硬件工程等其他领域的合法性。）
3.软件工程发展的过程中有趣的冷知识和故事？
说一说Lua语言的由来吧。Lua 是一个小巧的脚本语言，由标准C编写而成，几乎在所有操作系统和平台上都可以编译，运行。是由三个巴西人Roberto Ierusalimschy、Waldemar Celes、Luiz Henrique de Figueiredo发明。发明的原因是巴西石油公司PETROBRAS没办法使用指定的硬件，使用公众的资金需要通过一系列的严格手续，并且现有设备中什么平台什么系统都有，所以Lua被设计成一个基于ANSI C开发可以任意跨平台的语言。
4.目前流行的源程序版本管理软件和项目管理软件都有哪些， 各有什么优缺点？
目前流行的源程序版本管理软件和项目管理软件：Microsoft TFS，Git, SVN, Mercurial，Trac等。其中版本管理软件排行榜
-
Microsoft TFS
优点：
- 任务版上能将需求、项目进度一览无余，对于小团队而言，比甘特图更有用集成了项目管理、版本控制、BUG 跟踪。
- 能有效实现 SCRUM，能与 VS 无缝接合。
缺点：
- 搭建、维护tfs比较复杂，硬件要求也比较高。
- 整个系统是用 asp 实现的，用浏览器访问相当慢。
-
Git
优点：
- 公共服务器压力和数据量都不会太大。
- 速度快、灵活。
- 任意两个开发者之间可以很容易的解决冲突。
缺点：
- 学习周期相对而言比较长。
- 不符合常规思维。
- 代码保密性差，一旦开发者把整个库克隆下来就可以完全公开所有代码和版本信息。
-
Trac
优点：
- 有良好的扩充性。
- Trac的权限体系是比较完备的设计。
- 非常灵活，可以随心所欲的定制，可以和TortoiseSVN集成。
缺点：
- 不支持多项目。
- 需求和缺陷没有分离。
- 核心功能很少，不安装插件基本上没法用。
-
SVN
优点：
- 管理方便，逻辑明确，操作简单，上手快。
- 易于管理，集中式服务器更能保证安全性。
- 代码一致性非常高。
- 有良好的目录级权限控制系统。
缺点：
- 对服务器性能要求高，数据库容量经常暴增，体量大。
- 分支的管控方式不灵活。
-
Mercurial
优点：
- 学习门槛较低。整体上看，需要掌握的命令要比git少很多。
- 可以一键完全恢复到历史版本的某一个切面。
- 封装好。相比git，很少暴露一些实现内的细节。
缺点：
- 分支管理不灵活。Mercurial的branch管理和Git相比不是很方便。大型团队不愿使用。
参考资料