阅读教材后的疑问
编写单元测试的原则
此问题源于 P25 “2.1.2 好的单元测试的标准”。
在实际操作过程中，一个代码片段可能就是对于一段功能的极简描述，试图从外部验证其是否完成了指定功能本身就很困难。
比如 DLX 中覆盖一列的操作 coverCol，如果对该函数进行单元测试，就要验证其是否准确删除了一列及其对应的若干行，完成这项验证有两种方法：
- 以类似
coverCol的逻辑写一遍验证，但这本质上是循环论证，没有意义。 - 准确描述删除之后应该具有的状态，这需要以复杂的方法编码一个双向循环链表的状态，编写的测试的过程本身容易出错。
以上两点或许不是全部的解决方法，但是思考其它做测试的方法所花费的时间以及复杂度可能远远大于这个函数本身。
另一方面，该算法解决的精确覆盖问题却是较易验证的，只需要验证解是否构成一个精确覆盖即可，但是这就是在一个更大的层次上进行测试，并没有对 coverCol 进行单独的单元测试。
在类似这种难以对微观结果做描述，宏观结果易验证的情况下，是否还要执着于微观结果的单元测试？
此外，在 “单元测试应该覆盖所有代码路径” 中，提出了条件的覆盖。文中只是抛出了分支覆盖不等同于条件覆盖，那么我们在实际操作中究竟是否应该重视条件覆盖？又是何时应该重视呢？
总的来说，当单元测试会对开发造成极大负担的时候，该以何种原则找到二者之间的平衡点？
团队模式选择
在第 5 章 “团队和流程” 中，介绍了许许多多的软件团队的模式，这其中各有利弊，但作为经验十分不足的我们，该如何选择团队模式？或者如何通过一个高效、低错误代价的流程确定较为适合的模式？
关于共同远景
在 7.2 “MSF 基本原则” 中提到为“共同的远景而工作”，但在长时间的开发流程中，可能因为现实世界的变化导致远景不再现实，或者过程中的琐碎细节冲淡了对于这份远景的激情。而这一条又是 MSF 基本原则中维持团队凝聚力的重要一环，那么此时该通过什么方式强化团队的凝聚力呢？
关于会议
在 9.4 “领导力——高效的团队讨论” 中，提出了一些关于有效开会的一些阶段性流程，但实际列举到的手段较少，只有一个好主意停车场。考虑到在讨论的时候领导者可能自己也会深陷讨论不可自拔，有没有一些更加具体且有效的手段监控整个会议的流程？比如定时是否是一个好的选择？
关于源代码管理
在 11.6 “实战中的源代码管理” 中，提出了若干场景，但是没有答案只有一些问句，潜台词是否是说这些方面是需要考虑的，但是在实际的生产生活中并没有一个较为公认的方法解决各个场景吗？有没有一些具体的解决方案的例子说明各种方案之间的优劣？
请问 “软件” 和 “软件工程” 这些词汇是如何出现的 - 何时、何地、何人？
软件：最早的已知的使用记录是 1953 年八月由 Richard R. Carhart 在一次 Rand Corporation Research Memorandum 中做出的。具体发明时间、发明人不详。
软件工程：由 Margaret Hamlton 在开发阿波罗 11 号期间发明，时间大约在 1968 年附近。
大家知道了软件和软件工程的起源，请问软件工程发展的过程中有什么你觉得有趣的冷知识和故事？
在 1990 年 1 月 15 号，由于 AT&T 公司一行代码中的错误，导致 7500 万电话呼叫无响应，造成该公司 6 万美元的电话收入损失，其它间接损失未知。来自这里。
上网调查一下目前流行的源程序版本管理软件和项目管理软件都有哪些，各有什么优缺点？请按照最近一两年使用人数的多少， 从多到少排序并说明各自有多少用户（估计），工具的优缺点（可以引用相关资料并注明来源）。
Microsoft TFS
优点：分布/集中式版本控制，适用于敏捷开发，持续集成
缺点：多人时价格较贵
Git
优点：分布式版本控制，易使用的分支、合并，易调整的工作流，高效率，开源，免费
缺点：陡峭的学习曲线，对非文本文件不友好
Mercurial
优点：高扩展性，易移植，商业支持
缺点：不能合并，非脚本化的
GitHub
优点：便于管理开源软件，使用 Markdown 做记录，有良好的帮助文档
缺点：稍陡的学习曲线
Bitbucket
优点：易于使用
缺点：不可以搜索源代码
Trac
优点：易用的项目管理功能
缺点：对大多数版本控制软件没有原生支持
Bugzilla
优点：开源，易用，集成了测试管理、邮件系统，可自动化生成文档
缺点：复杂的界面
Rational
优点：自动化测试
缺点：价格昂贵，对生态系统外的支持不友好，较缓慢的开发周期
备注
用户量很难找到相关资源（即时是估计），故未填写。