SE_Work1_阅读构建之法&项目管理实践

项目	内容
课程：北航-2020-春-软件工程	博客园班级博客
要求：阅读《构建之法》并回答问题	我的博客做业
我在这个课程的目标是	提高团队管理及合做能力，开发一项满意的工程项目
这个做业在哪一个具体方面帮助我实现目标	阅读《构建之法》，了解软件工程构建过程的宏观理念

1、读《构建之法》有疑

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人左右。

2、 软件工程的起源

请问 “软件” 和 “软件工程” 这些词汇是如何出现的 - 什么时候、何地、何人？

“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 开发电脑系统的单位）的女性。尽管最初这个名词的提出并不被人们理解，但最终软件学科确实获得了应有的尊重。

3、 有趣的冷知识

你们知道了软件和软件工程的起源，请问软件工程发展的过程当中有什么你以为有趣的冷知识和故事？

来源于知乎：1975年，艾伦和盖茨给Altair 8800计算机写了个BASIC解释器卖给MITS，他们很快完成了解释器，甚至包括本身的IO系统和编辑器，一共只须要4k内存。 不过最后他们发现还须要一个引导程序将这些东西从外存整进去。 Paul Allen在飞机航班上完成了这项工做。这是1975年，没有笔记本。他用的是纸笔。写的是8080机器码。

4、项目管理软件

上网调查一下目前流行的源程序版本管理软件和项目管理软件都有哪些， 各有什么优缺点？ （提示：搜索一下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相比不是很方便。大型团队不肯使用。

5、调查实践

调查完目前流行的源程序版本管理软件和项目管理软件后，请你选择其中至少2个软件来进行动手实践.

1. github

2.bitbucket
支持在线编辑，界面清新美观。跟github同样容易操做。只是用户数不如github，将来可能考虑使用这一工具。