构建之法读后疑问：
- 初步的完成构建程序设计思路之后实现过程中发现了问题或者可以优化的地方是立马就改进还是完成之后按照步骤统一进行优化。
- 覆盖性测试，针对一些永远用不到只是用来预防极为极端的情况下，例如内存不足等，非常难以模拟的代码也需要覆盖吗?如果是成本岂不是很高
- 所谓敏捷开发在任何时候都适合吗?如果不是得话是什么时候不适合呢
- 拿一些测试应该由编写的人完成 哪一些应该由其他人完成比较好?有没有具体的划分
- 封闭开发以及合作开发应该以怎么样的频率交替核实?例如两个人开发进度不同 一个人需要交流 另一个人需要封闭开发
“软件”词汇由来：
这个词汇在1953年Paul Niquette为了区分”硬件”这个词汇而创造出来的，第一次被使用是在1958年John Tukey所发表的文章上面。
“软件工程”词汇由来：
软件这个词汇最早是由Margaret Hamilton提出来的。她是阿姆斯特丹登月计划的软件工程师。在十九世纪七十年代，她在为登月计划工作的过程中第一次提出”软件工程” 这个概念。刚刚提出这个概念的时候还被很多人所嘲笑，最后才慢慢被接受。
源程序版本管理软件和项目管理软件对比：
Microsoft TFS: 注重代码的全生命周期管理 覆盖面很广 能与VS无缝对接 缺点：部署和维护比较麻烦 访问很慢
Git: 分布式版本控制系统 很强大的功能 效率很高 适合高水平的公司团队 缺点：信息模型比较复杂 不是很容易使用
Mercurial: 基于python 跨平台 扩展性比较好 简洁优雅 部署比较容易 缺点：向后兼容麻烦 分支管理并不灵活 支持社区与其他产品相比并不好
GitHib: 基于Git的项目托管平台 功能十分强大 作品适合展示 缺点:代码私密保存需要收费 国内访问速度很慢
Bitbucket: 免费私有仓库 支持中文 功能全面 缺点: 网站不能直接访问 被墙了
Trac: 非常灵活 可以随心所欲的控制 可以SVN继承 缺点：功能相比较之下不是很强大
Bugzilla: 免费 有中文支持 缺点：快速搜索结果不准确 只能管理缺陷
Rational: IBM的软件管理软件
Apple XCode: 编译速度几块 操作轻松 扩展功能较多 缺点：更新版本后 可能会有插件失效