个人博客作业
个人博客作业
写在前面:
| 项目 | 内容 |
|---|---|
| 这个作业属于哪个课程 | 2020年春季计算机学院软件工程（罗杰 任建） |
| 这个作业的要求在哪里 | 个人博客作业 |
| 我在这个课程的目标是 | 提高自己的团队协作能力, 代码编写能力, 学会软件工程领域的技能. |
| 这个作业在具体哪方面帮助我实现目标 | 阅读<构建之法>, 帮助了解软件工程的脉络. |
快速看完整部教材(构建之法, 第三版)，列出你仍然不懂的5到10个问题，发布在你的个人博客上。
1. 单元测试必须由最熟悉代码的人(程序的作者)来写?
书上(P25)谈到, 必须由最熟悉代码逻辑的人来写, 才能保证单元测试可以尽可能地覆盖到所有情况.
对此, 我不是很赞同.
在我非常有限的编程经验来看, 最熟悉代码的人(程序作者)往往做不好自己程序的测试, 因为作者自己对自己的逻辑太过自信, 又或者是即使有缺陷也是作者本人的思维误区, 在编码的时候想不到, 单元测试时一样想不到.
所以我认为让作者本人写单元测试, 仅仅只能找出一些及其简陋的bug(如语法问题, 或者是编码粗心造成的), 而不能找到真正的逻辑上的bug.
2. 我们是否应该像工程师那样做?
书上(P36)谈到, 软件工程师比大四学生多学习了三年, 多工作了三年, 但是软件工程师们花在需求分析和测试上的时间比大四学生多得多, 与此同时, 具体的编码时间反而少了.
我有一个疑问是, 我们应该像文中谈及的软件工程师们那样做吗.
大三, 大四学生究竟应该以学习知识, 锻炼编码技能为主, 还是应该尽力靠近工程界, 把自己当软件工程师要求.
3. 如何在软件开发过程中保持开放-封闭原则?
书上(P38页)谈到, 软件应该是可扩展的, 同时是不可修改的.
那么我们应该如何保证软件的开放-封闭原则?
事实上, 软件的下一步需求是难以预测的, 在软件的开发过程中, 也很难保证现在的代码实现不和后续需求冲突. 如果产生了这种冲突, 一定是先期构建不合理吗, 还是说小范围推倒重构是合理的现象.
4. 结对编程果真效率高吗?
书中(P87)谈到, 结对编程分驾驶员和领航员角色, 各司其职, 但是事实上, 两个人的编码风格, 编码速度等都是不尽相同甚至差别甚大的, 几乎很难找到理想中的结对人员(甚至还不如小黄鸭), 结对很可能无法提高编程效率, 甚至可能拖慢进度, 乃至出现争执.
有如此之多的缺点, 结对编程真的有效可行吗?
5. 如何选择创新?
书上(P363)谈到, 大众的进步往往是缓慢的, 成功者只是比大众先走了一步.
然而, 从历史来看, 有些真正的天才(如哥白尼), 其想法往往超越时代(如哥白尼提出日心说), 不为大众所接受, 甚至逆社会之潮流. 那这样的创新, 还有必要, 有意义吗.
请问 “软件” 和 “软件工程” 这些词汇是如何出现的 - 何时、何地、何人？
- 软件(software)最早是在1953年由Richard R.Carhart在备忘录中首次使用; 1958年美国数学家Tukey在论文"The Teaching of Concrete Mathematics"中正式提出 .
- "软件工程"最早由数学与电脑科学先锋— Margaret Hamilton在阿波罗计划开发(1969年)过程中提出, 主要是为了将软件事业与硬件事业以及其他的工程学类做出区别.
附加题】：大家知道了软件和软件工程的起源，请问软件工程发展的过程中有什么你觉得有趣的冷知识和故事？
很多人都知道，Linus在1991年创建了开源的Linux，从此，Linux系统不断发展，已经成为最大的服务器系统软件了。
Linus虽然创建了Linux，但Linux的壮大是靠全世界热心的志愿者参与的，这么多人在世界各地为Linux编写代码，那Linux的代码是如何管理的呢？
事实是，在2002年以前，世界各地的志愿者把源代码文件通过diff的方式发给Linus，然后由Linus本人通过手工方式合并代码！
你也许会想，为什么Linus不把Linux代码放到版本控制系统里呢？不是有CVS、SVN这些免费的版本控制系统吗？因为Linus坚定地反对CVS和SVN，这些集中式的版本控制系统不但速度慢，而且必须联网才能使用。有一些商用的版本控制系统，虽然比CVS、SVN好用，但那是付费的，和Linux的开源精神不符。
不过，到了2002年，Linux系统已经发展了十年了，代码库之大让Linus很难继续通过手工方式管理了，社区的弟兄们也对这种方式表达了强烈不满，于是Linus选择了一个商业的版本控制系统BitKeeper，BitKeeper的东家BitMover公司出于人道主义精神，授权Linux社区免费使用这个版本控制系统。
安定团结的大好局面在2005年就被打破了，原因是Linux社区牛人聚集，不免沾染了一些梁山好汉的江湖习气。开发Samba的Andrew试图破解BitKeeper的协议（这么干的其实也不只他一个），被BitMover公司发现了（监控工作做得不错！），于是BitMover公司怒了，要收回Linux社区的免费使用权。
Linus可以向BitMover公司道个歉，保证以后严格管教弟兄们，嗯，这是不可能的。实际情况是这样的：
Linus花了两周时间自己用C写了一个分布式版本控制系统，这就是Git！一个月之内，Linux系统的源码已经由Git管理了！牛是怎么定义的呢？大家可以体会一下。
Git迅速成为最流行的分布式版本控制系统，尤其是2008年，GitHub网站上线了，它为开源项目免费提供Git存储，无数开源项目开始迁移至GitHub，包括jQuery，PHP，Ruby等等。
历史就是这么偶然，如果不是当年BitMover公司威胁Linux社区，可能现在我们就没有免费而超级好用的Git了。
(图片来自网络).
上网调查一下目前流行的源程序版本管理软件和项目管理软件都有哪些， 各有什么优缺点？
请按照最近一两年使用人数的多少， 从多到少排序并说明各自有多少用户（估计），工具的优缺点（可以引用相关资料并注明来源）。
按使用人数排序:
GitHub:
- 使用人数: 31,000,000.
- 优点: 提供Git存储库服务, 允许使用Git的源代码管理功能; 多人协作，交流方便; PR功能很好.
- 缺点: 学习周期长, 不利于新手; 国内使用体验较差.
SourceForge:
- 使用人数: 3,700,000.
- 优点: 开源社区, 人数众多;
- 缺点: 操作繁复，速度较慢
GitLab:
- 使用人数: 100,000.
- 优点: 和Github相似; 支持创建私人仓库;
- 缺点: 同Github
SVN:
- 使用人数: 未知.
- 优点: 管理方便, 逻辑明确, 符合一般人思维习惯; 易于管理, 集中式服务器更能保证安全性; 代码一致性非常高; 适合开发人数不多的项目开发.
- 缺点: 人数过多时服务器可能过载; 对中心服务器太过依赖; 不适合开源软件;
Microsoft TFS:
- 使用人数: 未知.
- 优点: 任务版上能将需求, 项目进度一览无余, 对小团队来说比甘特图更有用; 集成了项目管理, 版本控制, BUG 跟踪; 能有效实现SCRUM; 能与VS无缝接合.
- 缺点: 由asp实现, 浏览器访问慢; 搭建, 维护复杂, 硬件成本也高.
