软工第一次博客作业

软工第一次博客作业

项目	内容
课程：北航-2020-春-软件工程	博客园班级博客
要求：阅读《构建之法》并回答问题	个人博客作业
我在这个课程的目标是	提升自己的专业能力,审视自己所学的知识
这个作业在哪个具体方面帮助我实现目标	了解软件工程的大体流程,概念以及过去的实例

关于PM

微软的PM 有独特的历史和价值, 正如 Steven Sinofsky 讲的: 一直被拷贝, 但很少成功复制…

PM作为一种非常优秀的制度,在行业能广泛采用.那么微软的PM到底和其他公司的PM有什么不同之处?无法被成功拷贝的关键点在哪里?以及一个真正优秀的PM是如何成长的，他们是从猪逐渐演变而来还是从鹦鹉变成的?

关于软件工程结构

根据理论描述,软件工程包括了软件需求分析, 软件设计, 软件构建, 软件测试, 和软件维护。然而在现实生活中,对于一些规模比较小的公司,由于人员限制或者业务比较基础单一,并不需要那么多的流程和步骤,或者由于人数或者专业水平不够无法达到完整的流程。那么在现实工作中对于不同的业务哪些流程可以被简化甚至舍弃?以及是否存在只专注于单个或几个流程的外包公司?若存在,那么外包方和承包方是如何进行交流以及验收成果有效性的?

敏捷开发

敏捷开发是一种形式上较为松散的组织形式,以人之间的互动为导向。由此看来敏捷开发更加强调参与者之间的素质以及专业技能，相较于形式化开发缺少文档的支持内容。那么在敏捷开发团队的人员选用上有什么值得注意的地方?以及如何确保一支敏捷开发的团队拥有足够的稳定性以及安全性，不会由于成员之间的串通或者快速的人员流动导致心怀不轨的人混入团队，造成团队的财产损失或者项目受挫?

代码规范

在博客讲义的代码规范上讲到了goto语句的一些使用注意,即在单一出口下可以被合理使用。但是我一直看到的建议大多是禁止goto语句的使用。同时何为一个良好的编程逻辑对于不同人的认知可能不太相同。那么作为一个leader时如何确立一个合理正确的代码规范?当之前项目的代码规范与我的经验产生冲突,或者时间紧张,无法在短时间内多方面考虑时如何能够合理的取舍，制定一个好的代码规范?

创新迷思

阅读完了创新迷思5-6中NOKIA,WALKMAN以及铱星的例子，可见许多创新思维并不需要雄厚的专业知识以及技术背景,而反过来创新又不是完全凭空一拍脑袋产生的,那么创新思维的产生原点究竟在哪里?如何才能拥有更好的创新头脑?同时如果就像文中所描述的那样,当你对其他领域有了一定的创新思维，但是领域专家却用他的专业知识驳斥你后，你如果证明自己的想法是对的，以及自己是否坚持自己的想法?

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

In 2000, Fred Shapiro, a librarian at the Yale Law School, published a letter revealing that John Wilder Tukey's 1958 paper "The Teaching of Concrete Mathematics"[5][6] contained the earliest known usage of the term "software" found in a search of JSTOR's electronic archives, predating the OED's citation by two years.[7] This led many to credit Tukey with coining the term, particularly in obituaries published that same year,[8] although Tukey never claimed credit for any such coinage. In 1995, Paul Niquette claimed he had originally coined the term in October 1953, although he could not find any documents supporting his claim.[9] The earliest known publication of the term "software" in an engineering context was in August 1953 by Richard R. Carhart, in a Rand Corporation Research Memorandum.[10]

根据维基百科的描述,software一词最早由John Wilder在他一篇1958年发表的论文中被提出。同时software第一次使用来自于Richard R.Carhart在1953年写的一片工程性研究报告中。

The origins of the term "software engineering" have been attributed to various sources. The term "software engineering" appeared in a list of services offered by companies in the June 1965 issue of COMPUTERS and AUTOMATION and was used more formally in the August 1966 issue of Communications of the ACM (Volume 9, number 8) “letter to the ACM membership” by the ACM President Anthony A. Oettinger;,[8] it is also associated with the title of a NATO conference in 1968 by Professor Friedrich L. Bauer, the first conference on software engineering.[9] Independently, Margaret Hamilton named the discipline "software engineering" during the Apollo missions to give what they were doing legitimacy.[10] At the time there was perceived to be a "software crisis".[11][12][13] The 40th International Conference on Software Engineering (ICSE 2018) celebrates 50 years of "Software Engineering" with the Plenary Sessions' keynotes of Frederick Brooks[14] and Margaret Hamilton.[15]

对于software engineering,它被认为位于阿波罗计划项目组中的Margaret Hamiltion提出，大背景是software crisis。但该词在之前多次被使用,早在50年代 Douglas T. Ross在MIT的讲座中就曾提到软件工程这个词，之后 Margaret H. Hamilton正式命名了这个术语。

大家知道了软件和软件工程的起源，请问软件工程发展的过程中有什么你觉得有趣的冷知识和故事？

现在的视频游戏已经成为了最受瞩目的程序开发成果，然而历史上第一款数字计算机游戏则遭遇巨大失败。第一个电脑游戏出现于1962年，由麻省理工学院的计算机程序员Steve Russell与其团队一同编写，这款名为《太空大战》的游戏耗费了他们近200个小时。该游戏允许两名玩家分别控制两艘飞船，目标是击中并摧毁对方飞船，并且玩家还需要躲避屏幕中代表星球的小白点。如果玩家撞上这些星球，则游戏失败。虽然Russell和他的团队从未在这个游戏说的任何收益，但必须承认如果没有这一突破我们可能永远不会拥有如今蓬勃发展的视频游戏产业。

调查一下目前流行的源程序版本管理软件和项目管理软件都有哪些， 各有什么优缺点？

如下表格所示,wiki上整理了目前流行的管理软件用户人数排名以及功能模块实现情况。

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

git

git是一个开源的分布式版本控制系统，可以有效、高速地处理从很小到非常大的项目版本管理。

优点：
适合分布式开发，强调个体。
公共服务器压力和数据量都不会太大。
速度快、灵活。
任意两个开发者之间可以很容易的解决冲突。
离线工作。
缺点：
资料少。
学习周期相对而言比较长。
不符合常规思维。
代码保密性差，一旦开发者把整个库克隆下来就可以完全公开所有代码和版本信息。

github

GitHub是一个面向开源及私有软件项目的托管平台

优点:

​ 适合分布式开发，强调个体;

​ 公共的服务器压力和数量都不会太大；
​ 速度快， 成熟的架构，开发灵活；
​ 任意两个开发者之间可以很容易的解决冲突；

缺点:

​ 资料少，学习成本比较大，学习周期比较长，要求人员素质比较高；
​ 不符合常规思维；
​ 代码保密性差，一旦开发者把整个库克隆下来就可以完全公开所有代码和版本信息。

gitlab

GitLab 是一个用于仓库管理系统的开源项目，使用Git作为代码管理工具，并在此基础上搭建起来的web服务。

优点：

​ 国内IT公司对gitlab的私有库有较大的使用量。有较强的ci/cd功能.

​ 相较于github有更好的私有性和安全性

缺点：

​ 拓展功能需要收费，注册起来比较麻烦，相对于github比较慢。有些时候需要二重验证。

Microsoft TFS

优点：

​ 是对敏捷，msf，cmmi等项目、过程管理、过程改善的支持。任务版上能将需求、项目进度一览无余，对于小团队而言，比甘特图更有用。

缺点:

​ 能应用起来的团队、公司的数量极少，多数真正用起来，也就是源代码管理这部分，这也仅仅是占TFS极小部分功能。

bitbucket

BitBucket 是一家源代码托管网站，采用Mercurial和Git作为分布式版本控制系统，同时提供商业计划和免费账户。

优点:

​ 支持Hg，最易学易用（但不是最强大的）的分布式版本管理工具。同时也支持Git。他的网页端的git仓库不如 github好用，但是作为远端仓库足够了。

​ 完全免费的闭源项目，还支持5人以内的合作开发。
​ 支持中文

缺点:

​ 使用群体较小，同时系统不太稳定.

gitee

码云(gitee.com)是 OSCHINA.NET 推出的代码托管平台,支持 Git 和 SVN,提供免费的私有仓库托管。

优点:

​ 更快的下载速度，相较于github访问更加快速.支持 issue，wiki，私有仓库免费使用，保护分支是免费的。

​ 完全支持中文.

​ 可以将github中的项目直接导入

缺点:

​ 每个仓库有1G容量限制

Apple Xcode

优点:

​ 编译速度极快，每次操作都很快速和轻松。自动提供撤消、重做和保存功能，无需编写任何编码。

缺点:

​ 更新版本后，某个插件可能会失效。

​ 语言限制为IOS

Mercurial

Mercurial 是一种轻量级分布式版本控制系统，采用 Python 语言实现，易于学习和使用，扩展性强。其是基于 GNU General Public License (GPL) 授权的开源项目。

优点:

​ 学习门槛较低。整体上看，hg需要掌握的命令要比git少很多。 可以一键完全恢复到历史版本的某一个切面。 封装好。相比git，hg很少暴露一些实现内的细节。

缺点:

​ 分支管理不灵活。Mercurial的branch管理和Git相比不是很方便。大型团队不愿使用。

实践

Git

说明:改变git项目的readme.md并重新提交，期间遇到了登录的小问题。

​

​

​

​

​