SE_Work1_阅读构建之法&项目管理实践
| 项目 | 内容 |
|---|---|
| 课程：北航-2020-春-软件工程 | 博客园班级博客 |
| 要求：阅读《构建之法》并回答问题 | 个人博客作业 |
| 我在这个课程的目标是 | 提升团队管理及合作能力，开发一项满意的工程项目 |
| 这个作业在哪个具体方面帮助我实现目标 | 阅读《构建之法》，了解软件工程构建过程的宏观理念 |
一、读《构建之法》有疑
1. 科学与工程
概论P14
希望读者看了这一节之后，不再纠结“科学”和“工程”的问题，而是在不同的学习与工作阶段，投入到最适合的项目类型中去.
正如我上一篇博客所说，个人及其讨厌对于科学与工程对立的划分。因为在很大一部分程度上，科学和工程是合为一体，不分彼此的。因为科学本身的存在就是起源于对于现实生活、社会发展的需求：如《Dr. Stone》里面所示的一样，你能说男主角到底是一名科学家还是一名工程学家？
我认为：更多情况下，工程学只不过是科学的一种放大化，一种应用和实践：不再是一个人去研究，而是一群人真正开始实现这一种想法，真正通过技术手段改变所有人的生活。是的，科学和工程只是两个阶段，而不是两个职业！只关注工程学背后的科学原理或者只关注使用固定的方法进行工程实践必将造成天性的割裂！
2. 回归测试？
第二章P28
回归测试最好要自动化，因为这样就可以对于每一个构建快速运行所有回归测试，以保证尽早发现问题单元测试是回归测试的基础。在专注于模块基本功能的单元测试之外，还有功能测试一从用户的角度检查功能完成得怎么样。
从作者所述，似乎“回归测试=单元测试+功能测试”，即一个经过单元测试的模块却在此后不能完成其功能。
但是我们之前上过的面向对象中，老师专门讲述了JML规格设计 即一个类或者一个函数通过一种契约式设计能够完完全全完成自己的功能，如果该单元出现“回归”现象，仅仅是因为使用没有遵守契约。而不应该重新回归到该单元反复进行所谓的回归测试。
在这一情况下，很可能因为曾经的需求有所改变，我们可能需要重新设计一套新的契约，并且在该契约的基础上重新完成一套程序并进行充分的单元测试，而在原先的程序上修改是不合时宜的。
3. 专与精
第三章P57
当我们谈论“全栈工程师”的时候，我们说的究竟是“交响乐作曲家写各个乐器的乐谱”，还是 “演奏家满场奔走，操作各种乐器”呢？当工程师设计软件的时候，工程师的设计、修改错误 等活动大致等同于交响乐的谱写完善阶段，两个职业都假设一旦程序/乐谱写好，它们就会被正确地执行。
当一个运维工程师在维护一套系统的时候，运维团队要了解各个模块的作用、维护知识，以及和硬件、商业模式相关的各种事件的需求，如果这大部分运维工作都是一个运维工程师来完成，那么这位工程师的确是“全栈”，
这一段没有很好的解释专与精的关系，作者将软件工程师的“全栈”比作了交响乐作曲家对“多乐器”的深入理解。
以个人理解：虽然乐谱的作者/程序架构者是一个人，但是最后真正的演奏者/实现者并非本人，而是一个团队，但是本人能够全程指引整个乐队/整个团队的发展，并且维护整个交响曲/软件项目的效果。
注意到，在交响曲的演奏过程中，不仅有作曲家，还有指挥家，还有钢琴家。指挥家是对整首交响曲进行宏观把控的人，类似于管理者，而钢琴家是对于整个交响曲贡献最大的人，甚至能带领剩余乐队的节奏。而团队中的人各有分工，有人拉小提琴，有人吹长号，有人敲三角铁，甚至还有人在浑水摸鱼。那么软件工程中是不是一样呢？两者能做充分的类比吗？
4. 结队编程的意义
第四章P85
结对编程中有两个角色：
- 驾驶员（Driver）：控制键盘输入。
- 领航员（Navigator ）:起到领航、提醒的作用：
这两个角色是可以互换的 和现实生活中的例子类似，一个人负责具体的执行（驾驶，用键盘编写程序等），另一人负责导航、检查、掩护等。
针对结队编程的驾驶员和领航者两种角色的切换，我认为更多的是设计与实现的分离，即两个人一起设计编程的方法，设计双方模块所需要实现的功能，规整好双方的接口，制定好契约。而真正上是只有一个人去实现相应的部分，最后两人将自己所实现的组装在一起，即集成。
如果两个人都同时需要去理解对方程序所写的具体思路，甚至去复查对方的代码，我甚至觉得还不如自己重新写一份，对于双方来说都是巨大的工作量。这样来做，不仅任务没有减轻为原来的一半，更会变成原来的两倍了。
当然对于程序的复审，也不是读对方的代码，深入了解对方实现的内部细节，而是对对方现实的模块进行“功能测试”，不合格则打回去并提供功能测试样例让对方修改。
综上所述，个人对于结队的理解与作者有差异。
5. 团队模式
如何组织和管理团队，使每个成员能各自发挥特长，使任务能够平均，使得结果能符合预期。作者从不同角度提及了多种模式，大体总结如下：
| 编号 | 模式 | 描述 |
|---|---|---|
| 1 | 主治医师，明星 | 一人干活，其余辅助 |
| 2 | 社区 | 没有明确目标，自愿参与 |
| 3 | 业余剧团 | 一人导演，其余演员 |
| 4 | 秘密团队 | 全凭热情 |
| 5 | 特工团队 | 特殊技能 |
| 6 | 交响乐队 | 种类齐全，成员靠谱 |
| 7 | 爵士乐 | 无明确目标，即兴发挥 |
| 8 | 功能团队 | 按功能划分，频繁互动 |
| 9 | 官僚 | 追名逐利，老板驱动 |
虽然没有明确的好坏之分，但是在作者的字里行间，还是存在着偏好，尤其是对于软件工程的特点。
- 对于一个有明确目标的软件工程：2,7不合理
- 对于成员的特征来说，不一定都有热情，技术参差不齐：4,5不合理
- 不希望中央集权的角度上来说：1,9不合理
最终剩下的3,6,8稍微结合一下，似乎就能成为理想中的团队模式。而且一个较大的团队是有很多较小的团队完成的。对于大团队犹如一个交响乐队，小团队犹如一个功能团队或者业余剧团。
在宏观上，整个团队应该是各司其职，能互相成为可靠的队友，演绎完美的交响曲，整个大团队多于30人。
而在微观上，小团队中（如弦乐）可以分为一些具体的方面，大提琴、中提琴、小提琴按功能分，频繁互动。或者一名小队长掌管该团队的工作，每个小团队在5人左右。
二、 软件工程的起源
请问 “软件” 和 “软件工程” 这些词汇是如何出现的 - 何时、何地、何人？
“Software”
- 这个单词最早出现在出版物中是由Richard R. Carhart 于1953年8月出版的书籍。
- 2000年，耶鲁法学院的图书管理员Fred Shapiro发表了一封信，这封信揭露了在由美国数学家Tukey于1958年发布的论文"The Teaching of Concrete Mathematics"中，提到了对于单词“software”的用法。
- 1995，Paul Niquette声称他在1953年十月最初创造了这个词，虽然他没能找到任何资料支持他的说法。
“Software Engineering”：
- 是由 Margaret Hamilton 发明的， Hamilton是一个自学程序设计，并且当上 MIT 软件工程测试实验室主任（也就是为美国太空总署 NASA 开发电脑系统的单位）的女性。尽管最初这个名词的提出并不被人们理解，但最终软件学科确实得到了应有的尊重。
三、 有趣的冷知识
大家知道了软件和软件工程的起源，请问软件工程发展的过程中有什么你觉得有趣的冷知识和故事？
来源于知乎：1975年，艾伦和盖茨给Altair 8800计算机写了个BASIC解释器卖给MITS，他们很快完成了解释器，甚至包括自己的IO系统和编辑器，一共只需要4k内存。 不过最后他们发现还需要一个引导程序将这些东西从外存整进去。 Paul Allen在飞机航班上完成了这项工作。这是1975年，没有笔记本。他用的是纸笔。写的是8080机器码。
四、项目管理软件
上网调查一下目前流行的源程序版本管理软件和项目管理软件都有哪些， 各有什么优缺点？ （提示：搜索一下Microsoft TFS、Git、Mercurial、GitHub、Bitbucket、Trac、Bugzilla、Rational，Apple XCode）?
请按照最近一两年使用人数的多少， 从多到少排序并说明各自有多少用户（估计），工具的优缺点（可以引用相关资料并注明来源）。
1. 排名及特点
在Wikipedia上，能很明显看到各项目管理软件排名和特点。接下来对其进行整理，如下表格按照各项目管理软件的热度从高到底进行排序：
| Name | Popularity rank | Users | Projects | Code review | Bug tracking | Web hosting | Wiki | Translation system | Shell server | Mailing list | Forum | Personal repository | Private repository | Announce | Team | Release binaries |
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
| GitHub | 1 | 31,000,000 | 100,000,000 | Y | Y | Y | Y | N | N | N | N | Y | Y | Y | Y | Y |
| SourceForge | 2 | 3,700,000 | 500,000 | Y | Y | Y | Y | N | Y | Y | Y | Y | Y | Y | Y | Y |
| Bitbucket | 3 | 5,000,000 | - | Y | Y | Y | Y | N | N | N | N | Y | Y | N | Y | N |
| GitLab | 4 | 100,000 | 546,000 | Y | Y | Y | Y | N | N | N | N | Y | Y | Y | Y | Y |
| OSDN | 5 | 54,826 | 6,294 | Y | Y | Y | Y | N | Y | Y | Y | Y | N | Y | Y | Y |
| Launchpad | 6 | 3,965,288 | 40,881 | Y | Y | N | N | Y | N | Y | N | Y | Y | Y | Y | - |
| Assembla | 7 | - | 526,581+ | Y | Y | Y | Y | Y | N | N | N | Y | Y | Y | Y | - |
| Buddy | 8 | - | - | Y | Y | N | N | N | N | Y | Y | Y | Y | Y | Y | Y |
| GNU Savannah | 9 | 93,346 | 3,848 | Y | Y | Y | N | N | Y | Y | N | N | N | Y | Y | - |
| Gitea | 10 | - | - | Y | Y | N | Y | - | - | - | - | Y | Y | - | Y | - |
| CloudForge | 11 | - | - | - | Y | Y | Y | N | N | N | N | - | - | - | - | - |
| Ourproject.org | 12 | 6,353 | 1,846 | - | Y | Y | Y | N | - | Y | Y | - | - | - | - | - |
| Azure DevOps Services | - | - | - | Y | Y | Y | Y | N | N | Y | Y | Y | Y | Y | Y | Y |
| GForge | - | - | - | Y | Y | Y | Y | Y | N | Y | Y | Y | Y | Y | Y | Y |
| Helix TeamHub | - | - | - | Y | Y | N | Y | N | N | Y | Y | Y | Y | N | N | Y |
| java.net/Project Kenai | - | - | - | - | Y | Y | Y | N | N | Y | Y | Y | Y | Y | Y | - |
| Kallithea | - | - | - | Y | N | Y | N | N | - | N | N | Y | Y | N | Y | Y |
| Phabricator | - | - | - | Y | Y | Y | Y | - | Y | - | Y | - | - | - | - | - |
| RhodeCode | - | - | - | Y | N | Y | N | N | - | N | N | Y | Y | Y | Y | Y |
2. 部分软件优缺点
| Name | Advantages | Disadvantages |
|---|---|---|
| Microsoft TFS | 任务版上能将需求、项目进度一览无余 集成了项目管理、版本控制、BUG 跟踪，能有效实现 SCRUM，能与 VS 无缝接合。 | 能应用起来的团队、公司的数量极少，多数真正用起来，也就是源代码管理这部分，这也仅仅是占TFS极小部分功能。 |
| GitHub | GitHub提供Git存储库服务，基于web，允许你使用Git的源代码管理功能，或者其特性。GitHub提供Git存储库服务，基于web，允许你使用Git的源代码管理功能，或者其特性。 | 不是捕捉创意过程和记录创意点子的最佳工具。学习成本大。由浅入深的过度很漫长，需要大量时间的投入。Git版本库需要频繁的手动维护。 |
| Trac | 非常灵活，可以随心所欲控制可以和SVN集成;Trac做一个SCM配置管理平台，意味着它有良好的扩充;Trac的权限体系是比较完备的设计 | 不支持多项目; 需求和缺陷没有分 用 wiki; 来替代 Word 等工具编写文档提高了学习成本; 中文化不完整; 核心功能很少，需要配合插件使用。 |
| Bugzilla | 免费，有中文版支持 | 快速搜索结果不准确。只能管理缺陷。 |
| Apple XCode | 编译速度极快，每次操作都很快速和轻松。自动提供撤消、重做和保存功能，无需编写任何编码。 | 更新版本后，某个插件可能会失效。 |
| Mercurial | 学习门槛较低。整体上看，hg需要掌握的命令要比git少很多。 可以一键完全恢复到历史版本的某一个切面。 封装好。相比git，hg很少暴露一些实现内的细节。 | 分支管理不灵活。Mercurial的branch管理和Git相比不是很方便。大型团队不愿使用。 |
五、调查实践
调查完目前流行的源程序版本管理软件和项目管理软件后，请你选择其中至少2个软件来进行动手实践.
- github
2.bitbucket
支持在线编辑，界面清新美观。跟github一样容易操作。只是用户数不如github，未来可能考虑使用这一工具。
