軟工第一次博客做業

軟工第一次博客做業

項目	內容
課程：北航-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並從新提交，期間遇到了登陸的小問題。

​

​

​

​

​