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，將來可能考慮使用這一工具。