软件工程 - 个人博客作业
教材内容提问
1. 如何进行高质量的单元测试？
作者在2.1节 单元测试 中提到了单元测试失效的几种情况。在笔者实际使用单元测试中，尽管能够对代码进行覆盖测试，但是总觉得一些简单的单元测试无法对代码的所有运行逻辑进行测试(例如：循环、函数间逻辑)。此时应当如何学习编写更高质量的单元测试代码呢？
作者在书P25的对话中提到："如果不能表示为一个单元测试用例呢？"“那就是你写得还不够细。”
拆分程序逻辑，是否能够对我们更好地覆盖单元测试情况有所帮助？应当如何拆分呢？另外，在笔者之前的课程中，常常会使用自动化测试手段。相较于进行自动化测试，个人总觉得编写单元测试有些费时，但是自动化测试不一定能够覆盖所有的代码，如何能够将二者结合起来呢？
2. 结对编程真的更高效吗？
作者在书P86提到，结对编程可以取得更高的”投入产出比”。我认可结对编程可以有效提高代码质量，但是我认为合作的效率更好。 1. 二人合作是4只手在编程，从速度上讲比结对编程更高，能够快速实现已经制定的目标；2. 结对编程面临二人技术能力不同而可能导致的一人编程、另一人参与度较低的情况；而二人合作可以通过任务量分配差异来规避此问题。3. 结对编程主要特点是二人不断交流、不断互审，那么二人合作也可以进行不断交流和审阅。因此，我认为结对编程的“投入产出比”可能不如合作编程。
3. 新人如何融入敏捷团队？
作者在第六章介绍了敏捷开发，敏捷开发注重人员之间的沟通，能够有效增加开发进度。
但是敏捷开发对于团队的要求较高，如果团队人员流动较大，不熟悉项目的新手如何能较快地融入到敏捷开发的团队中呢？
4. 该不该立即回团队成员的Email？
作者在这里提供了一些非常有用的建议，例如集中处理Email，微信等。
那么我们在开发过程中，如果有团队其他人员的相关问题，是否应当及时回复呢？如果不及时处理，可能会影响团队其他人员的进度；而及时处理又可能耽误自己手头的工作。
5. BUG该立即修吗？
作者在11.5.5节讲到一个比较有意思的事情“小强地狱”，即bug积攒数量到一定程度的队员要使bug低于阈值才能继续开发；作者在后文中也提到一些小bug可能导致功能重写。
在自身的开发中，我也出现过由于一些之前的bug没有及时修复，导致后续需要大量时间重写某些功能的情形。那么，我们是对于出现的bug，是应当发现一个立即消除一个吗？修bug而影响的开发进度是否值得？
6. 为什么创新拓展不被接受？而“线性拓展”有着更好的命运？
作者在第16章谈到，在算法和数据库领域，创新的想法一开始往往不被接受，而那些在前人基础上的“线性拓展”则往往有着更好的命运。而这些决定还是很有经验的期刊审稿人做出来的。
在学术研究时，很多时候我们在工作中都需要和前人相似的工作进行比较，这样的work才可能更受认可。但是有时创新的一个小领域，便可能会因为别人无法对其进行判断而被忽视。是否应该根据前人的工作判断我们的工作的价值呢？如何避免创新拓展被忽视的情况出现？
请问'软件'和'软件工程'这些词汇是如何出现的?
| 软件 | 软件工程 | |
|---|---|---|
| 何时 | 1953年8月 | 1950s |
| 何地 | 美国兰德公司 | MIT |
| 何人 | Richard R.Carhart | Margaret Hamilton |
| 如何出现 | Richard R.Carhart 在公司的研究备忘录中首次提出 | Margaret Hamilton在阿波罗计划中正式命名了这个短语 |
冷知识
2038危机
早期我们使用32位计算机，而大多数C语言程序使用的“标准时间库”，用一个标准的4字节也就是32位的形式来储存时间信息。设计时，我们将把1970年1月1日凌晨0时0分0秒（the Unix Epoch）作为时间起点，这时的时间值为0。以后所有的时间都是从这个时间开始一秒一秒累积得来的。
而到了2038年时，这个32位存储的时间库便可能发生溢出，从而导致时间变为十进制的 -2147483648 ，而时间也会由2038年1月19日03:14:07因此跳转到1901年12月13日20:45:52。
当然，使用64位来表示时间便不会出现这样的问题。新的64位运算器可以记录至约2900亿年后的292,277,026,596年12月4日15:30:08，星期日（UTC）。
2038年问题 - 百度百科
上网调查一下目前流行的源程序版本管理软件和项目管理软件都有哪些， 各有什么优缺点？
请按照最近一两年使用人数的多少， 从多到少排序并说明各自有多少用户（估计），工具的优缺点（可以引用相关资料并注明来源）。
| Name | Users |
|---|---|
| GitHub | 31,000,000 |
| Bitbucket | 5,000,000 |
| Launchpad | 3,965,288 |
| SourceForge | 3,700,000 |
| GitLab | 100,000 |
| GNU Savannah | 93,346 |
| OSDN | 54,826 |
| Ourproject.org | 6,353 |
From Wikipedia
优缺点
Git
- 简介：分布式版本管理软件，有Linus创作，最初为了更好地管理Linux内核开发。
- 优点：
- 分布式开发，对于公共服务器的压力不会太大；
- 灵活能够方便地解决开发者之间的冲突
- 支持离线工作。
- 缺点：
- 学习门槛较高；
- 代码的保密性差，开发者clone下的库中可以看到所有的版本信息；
- 提交一些大文件后会导致git仓库上传/下载缓慢(所以在使用时要避免把git当网盘😂)
- Git有哪些缺点 - 知乎
Microsoft TFS
- 简介：TFS(Team Foundation Server)，是微软开发的项目管理工具，对敏捷、msf、cmmi等项目提供支持
- 优点：
- 支持代码审阅、邮件通知、web访问管理等
- 自带版本合并与比较工具，支持数据库版本管理
- 和VS结合紧密
- 缺点：
- 使用浏览器访问缓慢（如何评价微软TFS？ - 知乎）
Mercurial
- 简介：Mercurial是跨平台的分布式版本控制软件，主要由Python实现。
- 优点：
- 命令简单，易于上手
- 封装好
- 缺点：
- 功能不够强大；(Hg与git相比较，优缺点是什么 - 知乎)
- 分支管理不够灵活，跨平台性能较差；(Mercurial 有哪些优点 - 知乎)
GitHub
- 简介：基于Git进行版本控制端额源代码托管服务平台。
- 优点：
- 基于Git，具有前文提到的Git的相关优点；
- 使用用户众多，公开仓库及部分私有仓库免费；
- bug公开，具有pull request和issue等实用功能；
- 缺点：
- Git具有的命令复杂、门槛较高的问题。
Bitbucket
- 简介：Atlassian公司提供的一个基于web的版本库托管服务。
- 优点：支持Hg同时支持Git;
- 缺点：使用人数较少。
Trac
- 简介： Edgewall公司开发并维护的开放源码网页界面项目管理、缺陷追踪软件。
- 优点：灵活，可以与SVN集成 (参考)
- 缺点：不支持多项目，中文支持不好，需要配合插件使用。
Bugzilla
- 简介：由Mozilla公司提供的免费开源的一款Bug管理系统；
- 优点：免费，具有强大的检索功能；
- 缺点：只能管理缺陷，界面效果较差。(bug管理工具 - 知乎)
Apple XCode
- 简介：Apple公司向开发人员提供的集成开发环境。
- 优点：界面好看😂，集成代码管理工具。自动提供撤消、重做和保存功能，无需编写任何编码。
- 缺点：稳定性不佳、上手难 (Xcode与VS比较 - W3Cschool)
选择两个源程序/项目管理软件进行实践
GitHub
(图中为笔者的GitHub账号及博客园首页)
GitHub不仅仅是一个远程的代码寄存平台，重要的是它支持issue等功能来方便开发者进行交流。
在issue中，我们可以汇报发现的bug，对于产品的问题，也可以分配bug或者任务给开发者。
Git
git虽然学习门槛稍高，但是使用git可以较为轻松地进行版本管理，从而提升开发效率，并为版本回退等需求提供方便。
