写在前面
| 项目 | 内容 |
|---|---|
| 所属课程 | 2020春季计算机学院软件工程(罗杰 任健) (北航) |
| 作业要求 | 个人博客作业 |
| 课程目标 | 培养软件开发能力 |
| 本作业对实现目标的具体作用 | 阅读教材，了解软件工程，并比较各个项目管理软件 |
一、《构建之法》的读后疑问与思考
1. 单元测试相关问题 （书本2.1.2）
单元测试必须由最熟悉代码的人(程序的作者)来写。代码的作者最了解代码的目的、特点和实现的局限性。所以单元测试没有比作者更适合的人选了。
虽然我十分肯定没有人比程序员自己更了解自己代码的观点，但对作者的这句话我仍有疑问。作者在 2.1的开头说道：“软件的很多错误都是来源于程序员对模块功能的误解、疏忽或不了解模块的变化。”然而，程序员意识到的可能出错的地方，他在写代码时往往已经注意了。这同时也意味着他写的单元测试的数据不大可能会包含到他没想到的出错情况。我们debug的过程中常常也有这样的困扰，感觉自己没有什么可错的地方，自己写的测试样例测了很多也没问题。但别人的测试样例却常能给我们很大的帮助。一个人自己写自己的单元测试，可能会思维受限，考虑不全。如果在大家都清楚代码实现功能的情况下，有人辅助进行单元测试以避免设计和情况的遗漏，是不是会好一点？
2.软件团队的模式 （书本 5.2)
本节中，作者介绍了多种团队的模式，有 主治医师模式、明星模式、社区模式、业余剧团模式、秘密团队、特工团队、交响乐团模式、爵士乐模式、功能团队模式、官僚模式。然而，作者并没有在文章中直接说明他们之间的优劣，似乎持着“不管白猫黑猫，抓到老鼠就是好猫“的态度。
作为学生的我们，专业能力还在培养之中，课上组队的模式多为主治医师模式、业余剧团模式和爵士乐模式。之前读过关于”鸡群效应“的相关文章，其在一定程度上否定了”超人“对团队的必需性。然而就我的大学经历来说，组队作业中最突出的不乏有”大佬“的团队（他们可能有时独挑大梁）。虽然这种团队存在一人带不动全组的情况，但能力相当的人组成的团队往往会应没有导向而没有突破性进展。那决定一个模式是否适合的重要因素是什么呢？团队模式是由组队人的水平一开始就决定的呢，还是说在合作过程中可以改变的呢？如果改变，又将怎样过渡以避免尴尬的境地？
3.关于项目经理（书本 9.3 ）
在软件行业发展初期，软件都是为维持机器本身的运作服务，或是做科学计算，这时候也许看不出PM的作用。随着产业的发展，软件团队的复杂度都极大地提高了，这时候我们需要一些人，起到沟通、交换、影响、润滑、讨价还价的作用--就像商业社会的金钱一样--PM就是这样的角色。
PM做开发和测试之外的所有事情。
作者在这章中强调了PM的重要性，以及其所担任的任务。从作者的描述中，感觉PM更加注重的是软实力。虽然我们的大学课程有不少团队作业，却往往并没有PM的工作体现。这次软工作业，似乎是可以有PM的担当的，那么其预期的工作量是多少呢？在小型项目中，PM的价值如何更好得体现？
4.质量保障的相关问题 （书本14.1.2）
软件开发过程中的可见性（ Visibility）
我们看这个项目开发过程中的场景：
领导：进度如何？
答：可能快了。
问：能看看演示吗？
答：嗯，不知道。可能到了项目的最后一天才能看......
上面的对话不能说明软件的功能如何（也许最后发现功能非常惊艳），项目的可见性是非常差的。不但是小规模、业余项目会出现这样的情况，大规模的专业团队也是如此。
上面的问题我也遇到过。项目开展一段时间后，也许背后的工作很多，然而可展示的部分却很少。可能实际工作进度只差一点了，但由于各个部分关联性很强，没有全部完成的情况下并不好展示。项目开发的可见性，非常重要，但确实也会存在上面我说的情况，那么我们该如何做得更好呢？
5.关于创新的迷思（书本 16.1）
迷思之一：……但是他们没有提到这些科学巨人在顿悟之前已经在相关科学打下了深厚的基础，同时他们也为这些问题思考进行了长时间的思考，那些看似神奇的时刻才能光顾他们。
迷思之五：统计数据表明，70%的创新者说，他们最成功的创新，是在他们的拿手的领域之外发现的。
作者的这两段话，乍一看是挺矛盾的。我挺赞成第一段话的，且不说创新性地解决问题，连精准地发现可突破创新的点所在何处，大致有个前进的方向，就需要很深厚的领域知识了。然而，第二段话却用数据表明，领域的专家没有领域外的创新者那么有创意。是不是存在领域专家长期深陷本领域的研究，导致其思想被已有的专业知识限制的可能呢？这似乎牵扯到了学识的广度与深度的问题。在时间精力有限的情况下，深与广又该如何平衡呢？生活中不少例子表明，创新的方向往往以需求为导向。创新又带来了新一轮的需求。那么能敏锐发现需求的人，是不是更加可能创新呢？
二、 “软件” 和 “软件工程” 词汇的由来
软件
化学家和统计学家约翰·图基（john W. Tukey）在1958年撰写的一篇科学文章时，首次使用了“软件”这一 术语。据报道，他早在1953年就已经提出这个概念，用来标记计算机程序（即”软件“）与使用这些程序的计算机（或”硬件“）之间的区别。
软件工程
1968年秋季，NATO（北约） 的科技委员会召集了近50名一流的编程人员、计算机科学家和工业界巨头，讨论和制定摆脱“软件危机”的对策。在那次会议上第一次提出了软件工程（software engineering）这个概念，研究和应用如何以系统性的、规范化的、可定量的过程化方法去开发和维护软件，以及如何把经过时间考验而证明正确的管理技术和当前能够得到的最好的技术方法结合起来的学科。
三、软件发展过程中有趣的冷知识和故事
之前看到一篇文章，总结了一些在软件开发中的有趣而著名的定理。详见
墨菲定律 (Murphy's Law)
凡是可能出错的事就一定会出错。
推论：计算机会按照你写出来的方式运行，而不是你臆想出来的。
防御性编程、版本控制、测试驱动开发、模型驱动开发等等都是预防墨菲定律很好的做法。
布鲁克斯法则(Brook's Law)
向一个延期的项目增加人手只会让它延期得更加厉害
如果一个项目进展落后了，仅仅增加人力很有可能会带来灾难性的后果。相反，提高编程效率、审查软件开发方法和技术架构是否合理，几乎总是会比增加人力带来更好的效果。如果没有，这可能意味着霍夫施塔特定律在起作用。
霍夫斯塔特定律 (Hofstadter's Law)
事情总是要花费比你预想更长的时间，即使你把霍夫斯塔特定律也考虑在内。
这条定律的递归性反映出，即使付出最大的努力，也知道任务是复杂的，去精确地估算它依然是非常难的，所以要给估算留一个缓冲区出来。
四、流行的源程序版本管理软件和项目管理软件
- 近年来，源程序版本/项目管理软件的使用人数情况如下：
| Software | Usage | Project |
|---|---|---|
| GitHub | more than 40 million* people | 100 million* |
| GitLab | 100,000 organizations | ------ |
| Bitbucket | 6 million developers and 1 million teams | ------ |
| Bugzilla | hundreds or thousands of organizations | ------ |
| Trac | list of uesrs | ------ |
- 工具的优缺点比较：
| 软件名 | 优点 | 缺点 |
|---|---|---|
| Git | 1.分支与合并 2.小而快速 3.分散式 4.资料保证 5.登台区 6.免费和开源 |
1. 前期学习知识较多 2. 对中文支持差 3. 代码历史保密性差，一旦开发者把整个库克隆到本地，就可以完全查看到所有的历史版本信息 |
| Mercurial | 1.更简洁好用的命令行指令 2.易于扩展 3.服务器配置相对于Git更加容易。 |
1.Mercurial的分支模型十分复杂，分支管理与Git相比不方便 2. Mercurial改写历史很麻烦 3. 没有命名空间 |
| Trac | 1.十分灵活，支持定制 2.良好的扩充性 3.权限体系设计得比较完备 |
1. 不支持多项目 2. 中文化不完整 3. 核心功能很少，不安装插件基本无法使用 |
| Bugzilla | 1. 检索功能强大 2. 优化的数据库结构 3. 定制功能强 |
1. 安装需要Perl和配置MySQL数据库，过程比较繁琐 2. 修改配置文件很麻烦 3.UI设计差 |
| Bitbucket | 1.支持私有免费项目 2.提交大文件速度快 |
1.项目检索不便 2.社区活跃度低 |