初窺構建之法——記2020BUAA軟工我的博客做業

時間 2020-03-09

標籤構建 2020buaa buaa 我的博客简体版

原文原文鏈接

項目	內容
這個做業屬於哪一個課程	2020春季計算機學院軟件工程(羅傑任建)
這個做業的要求在哪裏	我的博客做業
我在這個課程的目標是	完成一次完整的軟件開發經歷並以博客的方式記錄開發過程的心得掌握團隊協做的技巧作出一個優秀的、持久的、具備實際意義的產品
這個做業在哪一個具體方面幫助我實現目標	經過鄒欣老師的《構建之法》在開始團隊項目前先了解清楚「團隊」和「項目」

學會提出問題

第一次真正意義上的軟件工程我的博客做業，要求是速讀鄒欣老師編著的《構建之法》，並提出5-10個問題。這個任務很是有趣，他不是傳統的讀書做業似的讓同窗們寫讀後感，我想多是讀後感這種東西比較偏向我的，並且大多的讀後感實際上是對文章目錄的總結，並無深度到某一個文字段落中去。可是，提出問題，一是同窗必需要真正深度到段落文字，二是強迫你在閱讀的時候思考，沒有思考就不會提出問題。在周舜欽：學習金字塔的誤解中，做者爲閱讀這一學習行爲進行了辯護，認爲不少人經過讀完以後能記憶多少來考察閱讀的效果是不正確的，應該夾以考慮閱讀的深度和廣度，是否有在閱讀的過程當中積極思考，參與討論。對書本中不理解的地方提出問題，便是一種思考的方式。html

問題零：課程的打分是否合理？

參見《構建之法》—— 給任課老師和助教的建議linux

這堂課如何打分？很簡單：把每次做業的表現分爲N檔，最優秀的幾個同窗得滿分，第2檔的同窗得1/2的分數，第3檔的同窗得1/3的分數，依次類推下去，這就是1/N的打分體系。遲交做業0分，不交做業倒扣分。就像下圖實線顯示的那樣。虛線是傳統的「你們都能及格」的分數分佈，如此分佈看似皆大歡喜，實際上是對優秀學生的極大不公。
git

爲何是問題零呢？你們已經看出來，這個問題是在書中的正式內容開始以前的部分，甚至是「給任課老師和助教的建議部分」，而不是關於軟件工程的部分。可是我仍是想斗膽提出本身的質疑，這樣的 1/N打分體系 是否合理？是否有走極端的嫌疑？程序員

首先，分檔給分是有依據的，這裏我也在arxiv上找到了一篇Grading by Category(GBC)關於討論如何可以更好的給同窗不只僅是分數，而帶有反饋。文中提到了三個關鍵點：github

分類標準是由學生的整體水平決定的，而不是事前給出的分數。如：應該是佔當年學生的百分之多少，而不是達到了多少分。
先分類再給定分數，這也透露出分檔不是最後的得分。
分類的標準是學生沒作什麼或者作錯了什麼，而不是作對了什麼。
這裏的分檔給分，論文中也給出了例子，對於一道物理題，分了多達8個等級：

等級	緣由	佔比
Q(4.0)	完整的回答，有清晰的步驟和整潔的做圖	27%
M(3.5)	也是完整的回答，但可能在步驟或做圖上出現一些瑕疵	6%
L(3.2)	大體完整的回答，但做圖錯誤或表述不清	10%
C(2.5)	回答中對圖片沒有完整的定義，做圖也出現錯誤或表述不清	6%
P(2.0)	知道回答須要的方程，並能知道方程的定義	14%
S(1.0)	知道回答須要的方程，可是並不能正確理解方程的含義	22%
N(0.5)	可以寫出一些有意義的回答，可是沒有完成題目	10%
Z(0.0)	物理意義和實際意義上的白卷	4%

論文的做者表示，經過給出細分的等級，有如下幾點好處：編程

學生能夠根據獲得的等級快速定位到本身的問題，以致學生可以在將來的測試中根據本身等級對應的不足本身有目標努力。
學生更加關注的是本身沒有作到什麼，而不是本身作到什麼，從而暴露出本身的不足和缺陷，去重視本身的缺陷。
老師在給分時能夠三思，由於GBC評分方式是等到全部學生的回答都給定等級以後再進行細緻的數值上的分數。這可讓老師在給定具體數值分數的時候能夠不須要從新審閱全部同窗的回答，而是在大致的等級區域內給出細緻的分數，也不會讓同窗獲得比應得更低的分數。
GBC評分制度提供給了老師一個量化分析的手段，由於在給定等級的過程當中就已經對同窗們所犯的錯誤或者不足進行的分類，因此出現同一問題的同窗的比例就能夠直接由該等級獲得，從而進一步調整教學方式和教學重點。
GBC評分制度提供了一個更簡便的 re-grade 方式。也就是說若是學生對於本身的成績有異議，能夠告訴老師本身的預期等級是多少，但學生在提出異議以前會先對本身進行一個等級上的評價，也就是將成績的合理性的證實從老師的身上轉移到了學生的身上，給對評分不滿的學生提出了「自證」的要求。

論文做者經過實際踐行這一方法獲得了積極的反饋，學生們從各個角度都認同了這種等級制評分方式。bash

因此在這裏，我想提出的問題就是，鄒老師在《構建之法》中提到的 1/N 體系是否太過於倉促果斷了，咱們能夠按照分檔給分的方式去衡量每一個人的做業，可是在衡量具體的做業以前就將對應的等級的分數給出，如1/2，1/3等等，是否有點對學生的工做不負責任？在這裏我想表達的是，我相信每一個學生都是認真完成做業並在做業的過程當中帶有本身的思考的，可能有些地方作的確實不是很完美，可是是否應該按照同窗在哪裏作的不夠好或者不足去具體的細分等級，而不是隻要犯錯就馬上少了一半的分數，我相信這樣一種「狼性文化」，會在同窗們剛開始的時候起到很好的競爭的效果，可是與此同時對於學生的打擊也是巨大的。網絡

也算是斗膽對課程組提出本身小小的建議，不妨嘗試一下這種 Grade by Category的評分方式，能夠給同窗們的做業按照不足進行分檔，在等級內再進行細緻的給分，我相信這會是一個不錯的嘗試。ssh

問題一：是否真的沒有銀彈

參見《構建之法》—— 第一章第2節分佈式

CD/DVD上可是這些非本質、臨時的特性並不能決定軟件工程的本質問題。例如，有人發明了一種新的程序設計語言，或者又出現了一個新的軟件開發流程，或者網上出現了又一個程序員技術社區……這些事並不能改變軟件工程的根本難度，這也是著名的「沒有銀彈（No Silver Bullet）」論斷所闡述的道理。軟件的這些本質特性讓「作一個好軟件」變得很難，同時也讓軟件工程有它獨特的挑戰和魅力。

首先咱們看銀彈是什麼，根據維基百科上沒有銀彈的詞條：
《沒有銀彈：軟件工程的本質性與附屬性工做》是IBM大型機之父佛瑞德·布魯克斯所發表一篇關於軟件工程的經典論文，該論述中強調因爲軟件的複雜性本質，而使真正的銀彈並不存在；所謂的沒有銀彈是指沒有任何一項技術或方法可以使軟件工程的生產力在十年內提升十倍。
布魯克斯在他的論述中將軟件開發的困難分爲兩類，一是本質性的困難，是軟件自己在概念（conceptual）建構上存先天的困難；二是附屬性的困難，在於將概念上的構思施行於電腦上，所遭遇到的困難。並提出了四點形成本質性困難的緣由：

複雜性（complexity）：軟件要解決的問題，一般牽扯到計算步驟，這是一種人爲、抽象化的智能活動，多半是複雜的。
隱匿性（invisibility）：還沒有完成的軟件是看不見的，即便利用圖標說明，也常沒法充分呈現其結構，使得人們在溝通上面臨極大的困難。
配合性（conformity）：在大型軟件環境中，各子系統的接口必須協同一致。因爲時間和環境的演變，要維持這樣的一致性一般十分困難。
易變性（changeability）：軟件所應用的環境常是由人羣、法規、硬件設備、應用領域等，各因素所聚集而成，而這些因素皆會快速變化。

雖然布魯克斯提出了四點困難的緣由，可是爲了提高軟件工程的生產力，也有許多人在奮力搜尋「銀彈」的存在，如從彙編語言到高級語言，大幅提高了生產力，下降了程序員的編程門檻；分是技術的出現提高了人們工做的效率，經過時間片輪轉等技術實現了程序的並行，同時不下降使用體驗等等。

除了沒有銀彈的聲音外，還有一些存在銀彈的反響，其中以 Brad Cox 的《There is a Silver Bullet》和 Divid Harel 的《Biting the Silver Bullet》爲主要論點。

我本身的觀點是辯證地討論這個問題，這個問題須要結合實際的現實而不是在任什麼時候候均可以揚言——「沒有銀彈」。咱們知道軟件開發的生產力不只被本質困難所影響，還被附屬困難所左右。今天咱們之因此可以站在這裏萬衆開發，就是由於先人們已經幫助咱們必定程度上解決了附屬性困難。好比集成開發環境的產生使得全部人都能輕鬆運行和開發程序，好比面對對象編程的出現，使得全部人都可以在構建和開發時編寫出更加理解易懂好維護的代碼。因此說，Harel還提出的一項假象實驗，將沒有銀彈的說法發表在再向前三十年的1952年而不是1986年，在當時的外部附屬難度頗高的環境下，沒有人會預料到後續的三十年內人們將附屬困難逐一攻破，十年內軟件工程的生產力提升十倍極可能成爲現實。
其次，我也很是贊成Jones的觀點——「把重點放在質量上，生產力將隨之而來」。對於生產力的衡量不只僅是量還有質。Jones提出，缺少有系統的質量控制與發生時程落後的災難，這二者之間有強烈的相關性。這就引出了咱們所須要學習和思考的如何對團隊進行系統且有效的進度控制和質量控制。
我之因此對銀彈是否存在持有懷疑態度是由於在大環境下，有一些本能夠提升的生產力沒有提升，還有不少團隊會出現文檔與實現分離的狀況，出現進度卡在某一我的負責的環節的狀況，這些狀況都是咱們會在後續的團隊編程中可能會遇到的，因此我以爲如今就應該思考，如何在團隊中破除沒有銀彈的詛咒，提高團隊的總體水平和能力。

問題二：如何選擇合適的團隊模式

參見《構建之法》第五章第2節

體育團隊從一窩蜂搶球演變到有明確的分工、陣型、戰術的團隊，須要時間。相似地，軟件團隊的模式，最初是混沌的一窩蜂形式：一羣人開始寫代碼，但願能寫出好軟件。隨着團隊的成熟和環境的變化，團隊模式會演變成下面幾種模式之一。

對於本學期的重頭戲：Alpha 和 Beta 階段的團隊編程，心中既激動好奇又惴惴不安，之前歷來沒有進行過任何大項目開發的咱們，該如何打好第一次戰役？
在團隊的選擇中，咱們首先是舍友三人組成了一個小的團體，一是對於你們的能力和責任心都比較放心，二是團隊中大部分人相熟能夠迅速在團隊中破冰。後來加入了一位女生和兩位男生，組成了6人的團隊。可是問題是你們都沒有從事過軟件開發，這就給咱們的團隊模式的選擇帶來了困擾。
結合咱們目前的狀況來看，因爲沒有一個技術高手進行統領，比較實際的是在社區模式和業餘劇團模式中進行選擇，然而社區模式在個人理解下，是像Linux社區那樣的，須要原先就具備必定的基礎，結合一個成熟的審覈團隊進行質量控制，因此剩下的只有業餘劇團模式，文中對於業餘劇團模式的描述確實比較業餘，在網絡上也沒有找到相關的描述，想請教老師和助教，業餘劇團模式的具體形式可以結合助教的經歷或是老師的觀察給一個更加清晰的講述嗎？

問題三：每日例會的效果如何？

參見《構建之法》第六章第2節

天天這樣寫代碼，咱們離衝刺的終點線究竟是更近了，仍是更遠了？若是流於形式，不管多麼敏捷的每日立會也會被忽悠[註釋5]。一個改進是，定義好任務到底是什麼？任務的完成（Done）到底意味着什麼？每一個人的任務必須是明肯定義的，狗熊們不能籠統地說「我在掰棒子」，而是要說明標號爲123的棒子如今是什麼狀態，你作好以後交給誰了。

在個人實習生活中，只遇到過週會，還沒經歷過緊張刺激的日會，天天完成的任務量有時候小到難以和前一天區分開的時候，咱們真正能從日會中得到什麼嗎？好比如今咱們除了軟件工程以外，還有計算機網絡、計算機網絡實驗，幾乎每位同窗還有額外的兩三門通常專業課，當時間真的一天18個小時不夠用的時候，咱們的例會可能發言就變成了「我和昨天同樣在掰棒子」甚至是「今天沒有動代碼」。我很是擔憂咱們團隊到了後期也會出現這種問題，我相信咱們的團隊每個人都不是渾水摸魚的類型，可是時間管理方面出現嚴重的缺陷時，咱們該如何應對？
這是我特別想向老師和助教請教的一個問題

由這個問題引伸出的一個問題：敏捷開始是不是一個僞命題？
在我閱讀第六章的內容前，這個疑問一直在個人腦海，我觀念裏面的敏捷開發，就是三點：一是快；二是快；三仍是快。這種快速可能會帶來質量上的損失，好比《構建之法》的圖6-5，大量微博用戶反映本身的微博丟失的狀況。可是當我看到第六章最後的「酒後問答」，不少個人疑問都被老師一一解答了。
敏捷開發確實是快，可是並非只要參與了敏捷開發，本來工期長的項目就能夠馬上獲得縮短，最後提早完成。用老師的回答來講——「敏捷的方法能幫助你更早地知道你是否能如期完成任務，僅此而已。敏捷的方法（迭代的方式）能幫你儘快讓用戶看到項目的部分價值。當你儘早交付部分價值時，也許用戶對你目前交付的東西已經很滿意了，這樣你就不用再花時間來實現其餘需求。另外一種多是，用戶看到了部分系統，他們有新的需求，這樣你就能夠實現新的需求，而不用再浪費時間實現過期的需求了。」
老師的回答和輪子哥在知乎上的回答有着殊途同歸之妙。敏捷不是一羣開發者對着甲方的初版需求猛作幾天，而是在作的過程當中始終和甲方進行有效的、不間斷的溝通，來幫助甲方更加清晰地認清本身的需求，也幫助整個團隊肯定一個當前的完成進度，也就是一個迭代中的需求分析和驗收。

問題四：爲何除了微軟不多見到Program Manager

參見《構建之法》第九章第1節

Program Manager：微軟的職位名稱。微軟產品團隊三足鼎立的角色分配就是PM、開發、測試。PM負責除產品開發和測試以外的全部事情。從某種意義上說，是前面兩種角色的綜合。微軟一般有專門的產品策劃（Product Planner），他們和市場部門的專職人員一塊兒，負責產品的長期發展和市場推廣。

在第九章中提到了PM，有三種含義，分別是 Product, Project和 Program Manager。做者也在書中提到，其中的Program Manager 是微軟的三駕馬車之一，另外兩個分別是測試和開發。我又在網絡上搜尋了有關Program Manager的資料，發現這個程序經理依然是微軟的特點之一，不由思考，爲何其餘的公司不效仿微軟，將Product Manager 升級爲 Program Manager呢？

對此，我首先看了一下微軟的員工眼裏二者的區別，其中，做者說道：「最基本的一條是程序經理不承擔人員和資源的管理任務。微軟一般把技術路線稱爲Individual Contributor，而把管理路線稱爲Management。而程序經理在職業規劃上屬於前者。」此外，該做者還總結了程序經理的任務：

負責和提出需求的客戶打交道，而且負責撰寫功能規範，也就是Product Feature Spec。
協調部門間的合做關係。

可是在看了這些資料以後，我還不是特別可以區分開二者的區別，但願老師和助教可以給我提供一個具體的樣例，即程序經理有什麼是產品經理作不了的，有什麼是產品經理能作而程序經理作不了的，有沒有除了微軟的其餘公司也設立了 Program Manager 這一個職位，這家公司和微軟有什麼類似的地方？

問題五：對於小團隊而言小強地獄是否可行？

參見《構建之法》第十一章第5節

隨着項目的深刻，每一個人同時既要開發新的功能，也要修復之前的缺陷。因爲沒有明確的優先次序，通常人都願意把時間花在開發新功能上。可是咱們的確須要平衡進度和質量。有這樣的一種方法：小強地獄（Bug Hell）。若是開發人員的小強（Bug）數量超過一規定值，則此君被送入「小強地獄」，在地獄中，他惟一能作的就是修復小強，直到小強數量低於此閾值。這一閾值由團隊根據實際狀況來肯定，要注意：開發人員同時「入獄」的人數應在全體成員的5%——30%之間，若比例過高，則要考慮閾值或小強數量的計算方式是否合理（是否只包括某一嚴重程度以上的Bug）。在項目過程當中，閾值不宜頻繁調整，最好事先宣佈閾值。

從這個團隊的例子中咱們能夠看到不少人身上的影子——如何處理待開發的新功能和已存在的Bug？相信不少人在編寫C/Cpp程序的時候，都會先寫完全部功能，而後再進行覆蓋性的測試，去找出全部的bug。可是當咱們是以一個團隊的身份開發一個項目的時候，不一樣點在於咱們再也不是單打獨鬥，咱們有專門的一部分人負責測試工做，若是像書中的例子同樣開發人員也是一味追求新功能而將本身的bug都藏着掖着，就會致使測試人員進度了等待的狀態。
這裏提到的小強地獄確實很美好，他將每一個人產生的小強的個數限定在一個提早設定好的閾值以內，每一個人的bug數目只要達到閾值就要開始專門的修復bug階段。這種方案對於大型團隊而言不容置疑是高效的，可是對於一個小型團隊而言，這種小強地獄的方案是否會對整個項目的進度帶來嚴重的影響？或者咱們是否能夠讓測試也承擔起一部分修繕bug的責任？

網絡上對於小強地獄這種工做方式寥寥無幾，因此但願有豐富的經驗的老師和助教們能以自身的經歷或者見聞解答一下個人這個疑惑——「小強地獄對於小型開發團隊團隊而言適合嗎？若是不適合，有什麼其餘的適合方案呢？若是適合，如何解決開發至多三人帶來的團隊進度被影響的問題呢？」

問題六：迷思之六：技術的創新是關鍵？

參見《構建之法》第十六章第1節

銥星有用戶麼？固然有，那些爬山運動員，在南極科學考察的人士，想隻身駕船周遊世界的孤膽英雄們，他們但願有一部這樣的電話。可是這樣的用戶在全世界有多少呢？銥星電話如今變成了一項租賃業務，爲這些幾千、幾萬的用戶提供短時間服務。與此同時，全世界的手機用戶早已突破了10億。

做者在這裏舉出的例子是銥星計劃(Iridium)的手機，論述的是銥星計劃雖然有技術的創新可是沒能成功，在這裏我有一點小小的疑惑。由於對銥星計劃不是很是瞭解因此就查了一下。

對於摩托羅拉的工程師巴里·伯蒂格來講，它來自於妻子在加勒比海度假時的抱怨，說她沒法用手機聯繫到她的客戶。回到家之後，巴里和摩托羅拉在亞利桑那州工做的衛星通訊小組的另外兩名工程師想到了一種銥星解決方案——由77顆近地衛星組成的星羣，讓用戶從世界上任何地方均可以打電話。因爲金屬元素銥有 77 個電子，這項計劃就被稱爲了銥星計劃，雖而後來衛星的總數降到了 66 個。
——來自百度百科對銥星計劃的介紹。

我分享一下個人感覺：技術的創新我依然認爲是關鍵，銥星計劃的失敗只不過是沒有把握住最好的時機。若是銥星計劃可以早那麼10年，我相信又是另外一幅格局。用戶基數一旦造成就難以撼動，不是技術不夠創新，而是很大程度上因爲人的惰性形成的，人們不肯意踏出溫馨區去爲了一點點微小的利益而改變，假若摩托羅拉的銥星計劃可以比基站通訊更早地俘獲大量的用戶而且穩定用戶，我相信銥星計劃仍是可以成功的。並且銥星計劃也沒有徹底失敗，說不定在將來又有他的出彩之處，若是可以基站和銥星結合起來，相互補充，我相信這將是通訊歷史上濃墨重彩的一步。

問題七：最難的問題——排座次

參見《構建之法》第十七章第3節

一羣人在一塊兒作事，事成以後，就有排座次、論功勞的問題——在有些團隊裏，事成以前就爲功勞的事吵翻了。軟件團隊如何作人員的績效管理？這個問題較難回答，由於全部人的工做被集成在一個軟件產品中，互相依賴，產品功能受到用戶讚賞或批評，都不能簡單地徹底對應於某一我的的工做。

在《構建之法》的最後一章的內容中，仍是提到了沒法迴避的問題，如何給團隊裏面的人排座次。做者經過多個角度論證了座次的排列不能但從一個角度，而是多個角度一塊兒考慮的結果。最後給的二維評價考覈表特別有趣，我以爲是一種很是新穎並且值得嘗試的方式。可是這些方式都是一些比較偏理論的，那若是在好比咱們這種軟件工程的課程裏面，和同年級的同窗組成的小組裏面進行貢獻度分配的時候，有什麼具體的實用的方式嗎？我也參考了知乎上的回答，可是上面所羅列的 KPI （Key Performance Indicator）關鍵業績指標法、BSC（Balanced Score Card）平衡記分卡、OKR （Objectives and Key Results）目標與關鍵成果法和 360度考覈法雖然特別完善和強大，可是對於小型團隊而言彷佛又太過於專業化了，並且會帶來額外的巨大的工做量，因此想請教一下助教們，當初大家在完成軟件工程這門課的最後是如何進行小組內的考覈評比的呢？

「軟件」和「軟件工程」這些詞彙是如何出現的 - 什麼時候、何地、何人？

軟件：從維基百科中能夠看到「軟件」一詞最先在 Turkey 於 1958 年所發表的 "The Teaching of Concrete Mathematics" 一文中被使用。

軟件工程：在對Margaret Hamilton的專訪中，咱們得知，是她在編寫阿波羅登月計劃的項目期間創造的軟件工程一詞。Margaret Hamilton 致力於爲軟件以及那些發明者爭取應有的正統性與尊重，因此開始使用「軟件工程」這樣的字眼來將之與硬件還有其餘工程學類作出區別。

關於軟件工程的小故事

世界上第一個計算機病毒

世界上第一個病毒是由巴基斯坦兄弟倆巴斯特（Basit）和阿姆捷特（Amjad）在1987年寫下的，但他們寫出這個病毒並非爲了去損害別人的利益，偏偏相反，是爲了維護本身的利益。
兩兄弟開了一家電腦公司，主要經營電腦和軟件業務。剛開始的時候公司經營很是好，生意興隆，可是慢慢的，市面上浮現出了盜拷的行爲，致使他們辛苦寫的程序被別人普遍傳播，因而兄弟兩人從父親往魚塘裏面丟樹枝防止別人撒網偷魚的作法中獲得了靈感，編寫了第一個病毒軟件。一旦他們的發行程序被盜拷，這個病毒就會在計算機中發做，將盜拷者計算機剩餘的內存空間所有佔據，這使得很多盜拷的人由於計算機沒法使用來向他們認錯，請求他們幫助修復計算機。他們一不留神寫下了世界上第一個病毒，人類與計算機病毒之間的較量由此展開。

Linus & Git

參考資料：Linus 在 2007 年 Google Talk 上介紹 Git

Linus 相信沒有學習計算機專業的人不認識的，獨自開發Linux系統，開發了Git源程序管理軟件，性格乖戾脾氣暴躁，都是他的tag。2005年的時候，Git還沒誕生，Linux內核代碼託管在 BitKeeper 上，Linus 本人對 CVS 十分厭惡，可是對 BitKeeper 鍾愛有加。他認爲 BitKeeper 的工做流和分佈式等理念是值得學習和嘗試的。可是因爲 BitKeeper 是一款商業軟件，Linux 是一款開源的工做，爲了防止狀況的惡化(此處也沒找到具體的是什麼惡化)，於2005年的時候 Linus 發佈了 Linux-2.6 ，因而開始本身開發一個 BitKeeper 的替代品。也就是說，若是不是BitKeeper 和 Linux 的一些不合，可能你們就不能看到 Git 的誕生了。對於Linus 給軟件的起名也特別有趣，Linux系統是Linus一開始起的名字，在發佈的時候Linus曾經想過換一個名字，可是被旁人制止，以爲使用本身的名字做爲一款系統的名字比較有意義。而對於第二款Source Code Management 源代碼管理工具——Git，則是英國俚語中「壞小子」的意思，Linus也曾經說過，本身是一個傲慢的混蛋，因此他的創做都用本身起名，Git也不例外。

源程序管理軟件和項目管理軟件調研

軟件	使用人數	優勢	缺點
Git	Unknown	1. 分佈式 2. 輕量 3. 能夠和其餘倉庫(如 GitHub GitLab Gitee)結合使用 4. 能夠隨時隨地離線使用，聯網時再update	1. 上手困難 2. 出現誤差時難以糾正 3. 指令太多，部分指令的表現與理解存在誤差
GitHub	31,000,000	1. 是當前最大的開源免費代碼倉庫，如今private倉庫也無償使用 2. 提供開發者一個交流合做的平臺，經過pr和issue幫助擁有者維護開源程序 3. 還提供了發佈的模塊給開發者進行發佈的版本管理	主要適合於代碼的追蹤，而不適合創意的記錄
Bitbucket	5,000,000	1. 一直提供無限免費私有倉庫 2. 對hg和git都支持 3. 支持中文 4. 第四方的git工具SourceTree比GitHub for Windows好用	1. 功能相比Git少不少 2. 對於開源不夠完全
Mercurial (hg)	Unknown	1. 學習門檻低，比git容易上手 2. 可以實現徹底回到某個歷史版本 3. 具備SVN的影子，對SVN用戶友好，零學習成本	1. 分支管理不靈活，對於大一些的團隊項目會形成權限混亂 2. 分支種類過多，匿名分支法、具名分支法、書籤法、克隆版本庫法等等，不方便使用 3. 沒有命名空間，團隊中誰提交的代碼搞不清楚
Trac	Unknown	很是靈活，能夠爲所欲爲控制能夠和SVN集成	功能不是很強大
Bugzilla	Unknown	免費，有中文版支持	快速搜索結果不許確。只能管理缺陷。
Microsoft TFS	Unknown	1. 微軟出品，和Visual Studio深度結合 2. 任務版內容詳盡，有需求和任務進度等，對小團隊而言更加方便有效 3. 集成了項目管理、版本控制、BUG 跟蹤等特性	1. 上手困難，搭建和維護TFS複雜 2. 基於ASP實現，訪問相比而言慢一些

源程序管理軟件上手實踐

Git

首先確定是最經常使用的 Git：

Git 是 Linus 爲了更好的控制本身的 Linux 源代碼的管理而創新出來的管理工具，其核心思想是充分的分佈式，特性之一是容許離線操做。Git 經過將工做區分爲三棵樹的方式來管理本身的代碼進度。
第一棵樹是本身的 工做空間，修改代碼確定首先是在本身的工做空間發生變化；
第二棵樹是 暫存區，是一個臨時保存的區域，須要經過 git add file/dir 的命令來將本身的工做空間中的修改保存到暫存區；
第三棵樹是 HEAD，始終指向最後提交的結果，運行 git commit -m "explanation words" 來說暫存區下的修改提交到 HEAD上；
三棵樹保證了Git是一個能夠本地離線運行的源程序管理工具，開發者能夠隨意回到以前的任意一個 commit 的版本中去。
最後在在線的狀態下，能夠經過 git push 將本地的HEAD提交到遠端的倉庫中，保存本地的修改。

這種思想對於初學者來講簡直就是災難。我在一年前學習面向對象和操做系統的時候纔開始接觸Git，一開始上手太難理解爲何要構建三棵樹了，以爲爲何不直接本地保存而後同步到線上呢？但隨着使用的時間的推移也發現了這種構建的好處，特別是能夠回到任意一個commit是開發者的福音。還有 Git 的 branch 也是對於項目開發特別友好的設計，能夠生成 Debug、Release、Develop 等等分支，在分支上進行爲所欲爲的操做，都不會對主分支形成任何的影響。
今年有幸擔任了面向對象課程的助教，在第一週的上機實驗中，從學弟學妹們的身上看到我本身的身影。~~沒有經歷過 git push 不被容許的報警是不完整的~~ 不少人一個實驗兩個小時也完不成基本的 Git 操做，要麼在分支上出現了問題，要麼在關聯的遠端倉庫上出了問題，要麼在ssh_key 上出了問題，等等等等。
若是單純可以使用 Git 的話，學習而且使用一段時間就熟練了，但要是想完全弄懂 Git，估計須要 Linus 的智商吧。

Mercurial(hg)

既然 Git 這麼勸退，咱們就嘗試一下聽說門檻低，較易上手的 Mercurial。
關於 Git 和 hg 的對比，爲何 hg 比 Git 好上手，這個博客是我找到的最完整的介紹。

嘗試了一下子 hg，註冊了 BitBucket 的帳號，但發現貌似 BitBucket 如今全面支持 Git 了，半天愣是沒有找到如何使用 hg 初始化倉庫，因而從 hg Guide 中 clone 了一個hg說明書的倉庫使用。
在已經對 Git 熟悉以後，對 hg 上手是特別快速的，要說有什麼特別的地方，hg 也有本身的 hg addremove xxx 和 git add xxx 很是類似，二者的 commit 都是同樣的，可是通過個人查閱以後發現，是由於我如今的倉庫規模不夠大因此感覺不到 hg 的方便之處。
hg 的優點通過總結有如下幾點：

hg 給用戶的信息較爲友好、輕便。好比 hg log 查看日誌的功能就特別簡單清新，好比：
```
changeset:   0:2b106112869d
 user:        q2l
 date:        Sun Mar 08 01:59:07 2020 +0800
 summary:     add one add three
```
與 Git 的 SHA-1 編碼製做的 commit_id 相比顯示簡單，但這裏 Git 裏面蘊含了 Linus 的我的的執念——「經過SHA編碼可讓你將來任什麼時候候都能回到你想要的任意一個版本」。
hg 提供了不少繼承的命令，好比 hg update, hg ci, hg serve 等等，能夠直接使用，其中我嘗試瞭如下 hg serve，若是倉庫是網站，能夠直接部署到 localhost 上，若是不是網站則能夠來顯示這個倉庫的有關信息，好比可視化的 branch 和 commit 等等。

可能對於每一個人的習慣不同選擇的工具也是不同的，在查閱hg 和 git 的對比和優缺點的時候，既有放棄hg轉向git的，也有從git到hg的，但如今整體的大趨勢是更多的源代碼管理倉庫偏向git，好比 bitbucket、github、gitlab，而hg已經被 Atlassain 收購，主要和 Atlassain下的工具進行集成。總之選擇本身喜歡的就行，也不是有不少喜歡 Git 的死對頭 CVS 嗎？