一、快速看完整部教材，列出你仍然不懂的5到10个问题，发布在你的个人博客上。
1.在第二章个人技术和流程，邹欣老师提到了一张表格，主要解释了效能分析的一些名词，其中有这么几个概念：
调用者：函数Foo()中调用了Bar()，Foo()就是调用者
被调用函数： 见上，Bar()就是被调用函数
本函数时间： 所有在本函数花费的时间，不包括被调用者使用的时间
所有时间： 包括本函数和所有调用者使用的时间
“所有时间”这个概念里的“本函数”一词，指的是本函数时间呢还是就是指该函数所花费的时间？如果指本函数时间，那么“所有时间”里面就不会有被调用者的时间；如果指该函数所花费的时间，那么“所有时间”里面就会包括被调用者所花费的时间。
2.在第三章软件工程师的成长，有一个很重要的理念，“过早优化是一切罪恶的根源”。所有的提前（换成了“提前”一词，感觉“过早”本身含有贬义）优化都是不对的吗？优化不仅仅是对效率的提升，还有对于一个模块的简化。一段代码写得比较复杂，程序员将其进行了优化，优化后的代码变得更加简洁易懂；或者一段代码有一种情况没有考虑到，程序员进行了优化，代码的质量更高了。这样的优化为什么不值得提倡呢？
3.在第九章项目经理，我知道了一个优秀的项目经理需要许多“软实力”，比如沟通能力，对流程的把控，和不同角色的沟通与合作，但是这些能力是不会天生就具有的，需要后期不断的在实践中磨练。但是许多技术人员，比如开发人员、测试人员，他们每天与代码和程序打交道，很难获得锻炼这些能力的机会，那么是不是也就意味着技术人员想要成为一个优秀的项目经理相对团队的其他角色很难？如果很难，我们又希望项目经理也能够懂技术，那么这种人才是不是更加稀少？
4.在第九章项目经理，邹欣老师提到了“从乐观角度分析问题的时候需要创意，从悲观角度分析问题的时候更需要创意”。乐观角度按照我的理解时产品能够产生积极作用的一面，比如说产品怎样可以给用户带来更愉悦的体验，产品某个功能的效率怎样可以更快，或者产品的界面怎样设计更加美观。而悲观角度我理解的是消极的一面，比如产品会有怎样的bug，产品设计的哪一点会让用户感到不爽。那么，“从悲观角度分析问题更需要创意”是因为我们需要发挥更多的创意，尽量想到产品的缺陷以进一步提升软件的质量吗？去思考产品的缺陷比思考产品还能添加什么更好的功能更重要吗？如果是这样的话，我们不可能创造出一个完美无缺的软件，如果一味的去思考缺陷是不是违背了“足够好”的理念？
5.在第十一章软件设计与实现，邹欣老师提到了数据流示意图，以图的形式表示了一个软件系统中的数据流动。但其中并没有表示和时间相关的数据流，而这部分信息是很重要的（书中也有提到）。那么怎样表示时间的数据信息呢？还有就是在数据流示意图里，是不是还需要规定图中数据流的数据格式和其他一些数据本身信息？
6.（在和同学的讨论中产生了这样的问题）我是一个体育迷，在职业竞技体育里，比如篮球和足球，会有这样一种现象，就是两三个超级球星加入同一只球队时，大部分情况下，这支球队的战绩会很好。但也有不能忽视的一部分案例，会有球星1+1<2或者1+1+1<3的情况（比如2010年南非世界杯的阿根廷国家队和NBA2016-2017赛季的尼克斯）。那么在软件工程领域，在技术方面有人是技术大牛，有人只是初学者，对于一个团队来说，技术牛人越多，这个团队的工作就一定会越好吗？如果不是的话，那么一个团队除了要有技术牛人以外还要有什么类型的人呢？
二、请问 “软件” 和 “软件工程” 这些词汇是如何出现的 - 何时、何地、何人？
“软件”是1953年8月份Richard R. Carhart在一篇文档中提出的。
“软件工程”是1968年Margaret Hamilton在阿波罗计划期间提出的。
三、【附加题】：大家知道了软件和软件工程的起源，请问软件工程发展的过程中有什么你觉得有趣的冷知识和故事？
《构建之法》中有一个很有意思的故事，在论述建模和写代码解决实际问题二者的关系时，邹欣老师写到了软件工程方法论专家Hans-Peter Hoffmann的经历，“当时他接到了一个来自英国的求助电话。客户说，他们已经建好了模型，并且这个模型已经获得了整个流程中绝大部分人的共同认可，但他们费解的是，有了这个模型，他们下一步应该干些什么！”
还有一个故事是：1996年，三友开始与James Odell、Peter Coad、David Harel等来自其他公司的方法学家合作，吸纳了他们的成果精华。1997年9月，所有建议被合并成一套建议书提交给OMG。1997年11月，UML被 OMG全体成员一致通过，并采纳为标准。UML诞生时，Martin Fowler就作了如下预测：你应该使用UML吗？一个字：是！旧的面向对象符号正在快速地消逝。它们还会残留在UML稳固前出版的书上面，但新的书、文章等等将会全部以UML 作为符号。如果你正在使用旧的符号，你就应该在1998年间转换到UML。如果你正要开始使用建模符号，你就该直接学习UML。时间过去10年了，事实正是如此。以UML为契机，掀起了一股普及软件工程的热潮，比起UML出现之前，软件工程的书籍出现了爆炸性的增长。制定 UML标准的角色（OMG）、根据标准开发工具的角色（UML工具厂商）、使用UML工具开发软件的角色（开发人员）这三种角色的剥离，也导致建模工具数 量和种类出现了爆炸性的增长。
四、上网调查一下目前流行的源程序版本管理软件和项目管理软件都有哪些， 各有什么优缺点？
Microsoft TFS
优点：与visualStudio无缝对接；任务版上能将需求、项目进度一览无余，对于小团队而言，比甘特图更有用；集成了项目管理、版本控制、BUG 跟踪，能有效实现 SCRUM
缺点：对硬件条件的要求很高
Git
优点：用户群广泛，普及度较高；免费，开源，分布式的版本管理系统；操作快速简便
缺点：缺少图形化界面，对初学者不够友好；各个版本之间的命令也有些许不兼容
Mercurial
优点：跨平台，可扩展性强；简洁优雅；服务器部署相对容易；命令行简单，容易上手
缺点：分支管理不灵活
GitHub
优点：开源项目有巨大优势；强调个人；每台同步的机器上都有所有的历史记录；功能设计简洁实用
缺点：不太适合一个团队的私有项目；国内访问速度慢；很难解决企业内部的需求；免费套餐不支持私有项目
Bitbucket
优点：支持私有免费项目，不限容量；提交大文件速度很快
缺点：域名长度较长，记忆起来略困难；界面语言只有英语
Trac
优点：有良好的扩充性；权限体系比较完备； 非常灵活，支持随心所欲的定制；可以和TortoiseSVN集成
缺点：不支持多项目；核心功能很少，不安装插件基本上没法用
Bugzilla
优点：免费；有中文支持
缺点：功能相对单一；
Apple XCode
优点：可以自动创建分类图表；自动提供撤消、重做和保存功能
缺点：更新版本可能会导致插件失效
参考资料：
http://blog.csdn.net/liuyi58/article/details/5389745
https://www.zhihu.com/question/21943395
http://blog.csdn.net/dengsilinming/article/details/7999188
https://www.zhihu.com/question/20401926
https://www.zhihu.com/question/21905835
https://www.zhihu.com/question/20053312
http://shawphy.com/2010/08/bitbucket-vs-github.html
http://www.cnblogs.com/yuyue1216/p/5281544.html