个人博客作业
| 项目 | 内容 |
|---|---|
| 本次作业所属课程 | 2020BUAA软件工程 |
| 本次作业要求 | 第1次个人作业 |
| 我在本课程的目标 | 学习软件工程的相关知识，了解团队协作编程，为以后的工作打下基础 |
| 本次作业的帮助 | 通过阅读其他博主的博客，了解了许多优秀的人的学习和工作经历，他们对于计算机的理解，帮助自己选择未来的路。 |
快速看完整部教材，列出你仍然不懂的5到10个问题，发布在你的个人博客上。
-
关于软件的“完美”
作者是这样描述的：有实际用处同时又是完美的软件在世界上是不存在的，没有实际用处的“完美”软件，也几乎没有。
作者从bug的角度分析了软件好与坏的一些判定，但是从我个人的使用经验来看，是否存在bug其实只是使用体验的一个很基础的标准。对我来言，软件的逻辑结构，界面设计，流畅度都很影响我的使用体验，所以完美究竟该如何理解。同时，如果从这么多主观的方式来评价软件，又会存在不同用户的偏好不同的问题，所以说我们如何有一套客观的标准来指引我们向完美开发。
-
作者在讲解单元测试的技巧和作用时，多次强调了单元测试的路径覆盖率
单元测试应该覆盖所有代码路径。单元测试应覆盖所测单元的所有代码路径，包括错误处理路径。 为了保证代码覆盖率，单元测试必须测试公开的和私有的函数/方法。
在上上学期的面向对象的课程中，我们尝试过把软件的每一个部分都用严密的逻辑表达确定，并且可以生成自动测试。但是从实际体验上来说，却并不理想，我觉得有以下原因。1. 如果把程序的每个函数都严格的测试，工作量十分浩大，并且不够灵活，比如对程序的架构调整甚至方法的优化，就可能需要重新构建测试。2. 哪怕经过了严格的测试，也不能排除一些逻辑上的错误，通过测试也没有办法从宏观角度检验软件。3. 测试的工具其实有很多不方便的地方，有的东西感觉也不够成熟。综合以上的问题，我对测试的价值，以及需要测试的程度产生了一些怀疑。
-
关于第四章中提到的“结对编程”
身旁的这个家伙老是问问题，他/她不会看书么？我都无法专心工作了
我对上面的陈述在现实中是否存在留有疑问，现在的企业生产环境十分紧张，企业往往愿意直接招聘高水平的人才然后直接投入困难的工作，而并不倾向于培养新人，同时也存在老人排挤新人等情况，这种开发模式真的在企业生产环境中有落地吗？
-
关于第十七章中提到的“磨合阶段”
磨合阶段（Storming）就像一个人的青少年时期，充满了对个人、同伴和团队的 疑惑和冲突。团队中的一团和气只能维持一小段时间，大家不得不认真地面对问题，开展讨论。随着讨论的深入，有些人会沉不住气，就会出现小的意见分歧和冲突。
那么如何判断一个团队是处于“磨合阶段”还是说这个团队的人员配置本身真的存在问题呢？
-
大部分成功的创新者都不是先行者
确实如作者所说，计算机领域，尤其是IT中，很多先行者都被淘汰掉了。由于互联网天生的互联特性，我们也发现整个行业逐渐出现了几大寡头，如果提出了一些创新，也经常败在这些互联网巨人的资本之下，这是否意味着未来的IT领域，创新者的生存空间在逐渐缩小？
请问 “软件” 和 “软件工程” 这些词汇是如何出现的 - 何时、何地、何人？
软件：1958年，John Tukey，在其论文"The Teaching of Concrete Mathematics"中提出
软件工程：阿波罗11号的软件开发期间，Margaret Hamilton提出
大家知道了软件和软件工程的起源，请问软件工程发展的过程中有什么你觉得有趣的冷知识和故事？：Git的诞生
Linus在1991年创建了开源的Linux，从此，Linux系统不断发展，成为最大的服务器系统软件。Linus虽然创建了Linux，但Linux的壮大是靠全世界热心的志愿者参与的。在2002年以前，世界各地的志愿者把源代码文件通过diff的方式发给Linus，然后由Linus本人通过手工方式合并代码。
到了2002年，Linux系统已经发展了十年了，代码库之大让Linus很难继续通过手工方式管理了，于是Linus选择了一个商业的版本控制系统BitKeeper，BitKeeper的东家BitMover公司出于人道主义精神，授权Linux社区免费使用这个版本控制系统。
安定团结的大好局面在2005年就被打破了，原因是开发Samba的Andrew试图破解BitKeeper的协议（这么干的其实也不只他一个），被BitMover公司发现了，于是BitMover公司怒了，要收回Linux社区的免费使用权。
Linus可以向BitMover公司道个歉，保证以后严格管教弟兄们，嗯，这是不可能的。实际情况是这样的：
Linus花了两周时间自己用C写了一个分布式版本控制系统，这就是Git！
上网调查一下目前流行的源程序版本管理软件和项目管理软件都有哪些， 各有什么优缺点？
Microsoft TFS
优点：
- 任务版上能将需求、项目进度一览无余，集成了项目管理、版本控制、BUG 跟踪。
- 能有效实现 SCRUM，能与 VS 无缝接合。
缺点：
- 搭建、维护tfs比较复杂，硬件要求也比较高。
- 整个系统是用 asp 实现的，用浏览器访问较慢。
Git
优点：
- 免费且开源。
- Git支持分支功能（branch）。如果开发一个新的产品功能，可以建立一个分支，对这个分支的进行修改，而不至于会影响到主支上的代码。
- 可拿Git做备份系统，或者同步多台机器的文档，很方便。
- 支持离线工作。本地提交可以稍后提交到服务器上，不用和集中的代码管理服务器交互。 只有最终完成的版本才需要向一个中心的集中的代码管理服务器提交。
- Git 提交都是原子的，且是整个项目范围的。
- Git 中的每个工作树都包含一个具有完整项目历史的仓库。
缺点：
- 学习成本大。由浅入深的过度很漫长，需要大量时间的投入。
- Git版本库需要频繁的手动维护。
Mercurial
优点：
- 学习门槛较低。整体上看，hg需要掌握的命令要比git少很多。
- 可以一键完全恢复到历史版本的某一个切面。
- 封装好。相比git，hg很少暴露一些实现内的细节。
- 照顾 svn 的迁移用户。hg 的很多命令是迁移自 svn 命令的，习惯 svn 命令的团队，几乎可以零成本的切换到 hg。
- hg的版本库不需要维护。
缺点：
- 分支管理不灵活。Mercurial的branch管理和Git相比不是很方便。不适合大型团队使用。
请按照最近一两年使用人数的多少， 从多到少排序并说明各自有多少用户（估计），工具的优缺点（可以引用相关资料并注明来源）。
用户数量与热度
| Name | Users | Projects | Alexa rank (lower = more popular) |
|---|---|---|---|
| Assembla | Unknown | 526,581+[45] | 23,052 as of 9 September 2019[46] |
| Bitbucket | 5,000,000[47] | Unknown | 989 as of 9 September 2019[48] |
| Buddy | Unknown | Unknown | 73,518 as of 9 September 2019[49] |
| CloudForge | Unknown | Unknown | 339,271 as of 9 September 2019[50] |
| Gitea | Unknown | Unknown | 209,697 as of 9 September 2019[51] |
| GitHub | 31,000,000[52] | 100,000,000[52] | 65 as of 9 September 2019[53] |
| GitLab | 100,000[54] | 546,000[55][k] | 2,146 as of 9 September 2019[56] |
| GNU Savannah | 93,346[57] | 3,848[57] | 100,244 as of 9 September 2019[58] |
| Launchpad | 3,965,288[59] | 40,881[60] | 12,344 as of 9 September 2019[61] |
| OSDN | 54,826[62] | 6,294[62] | 8,529 as of 9 September 2019[63] |
| Ourproject.org | 6,353[64] | 1,846[64] | 1,191,954 as of 9 September 2019[65] |
| OW2 Consortium | Unknown | Unknown | 610,052 as of 9 September 2019[66] |
| Rosetta code | Unknown | Unknown | 62,045 as of 9 September 2019[67] |
| SEUL | Unknown | Unknown | 1,268,571 as of 9 September 2019[68] |
| SourceForge | 3,700,000[69] | 500,000[69] | 407 as of 9 September 2019[[70]]( |
调查完目前流行的源程序版本管理软件和项目管理软件后，请你选择其中至少2个软件来进行动手实践
-
git
- github
