[BUAA軟工]第一次博客做業---閱讀《構建之法》

[BUAA軟工]第一次博客做業

項目	內容
這個做業屬於哪一個課程	北航軟工
這個做業的要求在哪裏	第1次我的做業
我在這個課程的目標是	學習如何以團隊的形式開發軟件，提高我的軟件開發能力
這個做業在哪一個具體方面幫助我實現目標	督促我閱讀《構建之法》，瞭解軟件開發的具體含義及流程

快速看完整部教材，列出你仍然不懂的5到10個問題

若是一架民用飛機上有需求，用戶使用它的機率是百萬分之一，你還要作這個功能麼？

書的第一章使用民航飛機的安全功能舉例，雖然這個功能的使用率不足百萬分之一（能夠理解爲飛機出現事故的機率？），可是卻十分重要，而且若是沒有的話就不能讓乘客安心乘坐。書用這個例子類比商業軟件開發，意在告訴咱們，雖然對於一個軟件來講，某個功能的使用機率是百萬分之一，可是仍要設計實現、並教會用戶使用。

對於民航飛機的例子來講，我無比贊同；對於商業軟件開發中，實現利用率極低的功能的重要性的闡述，我也能理解。可是，我不明白這二者之間關聯的必要性。若是說，這個功能是保護用戶的核心數據（類比民航飛機的安全系統保護乘客的生命安全），且沒有別的手段與之相配合，那麼這樣的比喻我能夠理解。可是，這樣的說明卻在例子的描述中看不到。若是沒有這樣一個重要的前提假設，我就沒法理解實現這樣一個利用率可不可勝數，且並非非它不可的功能的說明了。

在結對編程模式下，一對程序員肩並肩、平等地、互補地進行開發工做。他們並排坐在一臺電腦前，面對同一個顯示器，使用同一個鍵盤、同一個鼠標一塊兒工做。他們一塊兒分析，一塊兒設計，一塊兒寫測試用例，一塊兒編碼，一塊兒作單元測試，一塊兒作集成測試，一塊兒寫文檔，等等。

書的第四章，談到告終對編程。以Intuit公司的兩位程序員的60小時極限馬拉松編程爲例子，提出了兩我的分別做爲領航員和駕駛員的完成程序實現的模式。

這樣開發的模式，確實與咱們傳統完成代碼實現的過程不一樣。可是，書中的例子中的兩位程序員是別無發他的舉措，這樣作在不處於那樣的窘境中的時候仍是必要的麼？既然將來軟件團隊都是以團隊的形式作開發，咱們又爲何要學習兩人結對的模式呢？

而且，書中提到的兩我的肩並肩的開發，在如今的條件下並不現實。就那我舉例，個人同伴白天要去公司實習，因此只能晚上編程。而我晚上會作一點興趣方向的研究，因此只能白天編程。這樣的話，咱們的編程模式就變成了，經共同探討後，一我的先敲一部分，另外一我的理解了以後，再敲一部分。兩人的編程過程卻沒法溝通。

殺手功能/外圍功能

書中談到，要按重要性劃分功能，再決定進行不一樣的處理。具體的例子中， 提到了核心功能是OCR的文字識別，而外圍功能是界面皮膚。可是，當下的市場中，消費者每每對於「外圍功能」有些執着。好比VIVO，OPPO等手機廠商，當而皇之的將使用次當硬件配置，卻着重宣傳手機美圖、顏值等的手機賣一線旗艦機的價格。與之對應比的是小米等廠商，用一流的硬件配置。可是，二者的用戶羣體是不一樣的，前者主要偏重於年輕女性，後者主要偏重於年輕的男性。

這樣來看，是否是產品的功能核心與否也要取決於用戶？

迷思之三：好的想法會贏

書中使用鍵盤鍵位雖不合理卻不更新，以及美國仍在使用英制衡量制度的例子說明，光有一個好的創意是不行的，也須要與之配套的描述。

但這裏美國仍使用英制衡量制度的例子，我以爲的有些不恰當。並非只有美國曾經使用過英制衡量制度，最起碼英國使用過的。可是如今卻只有美國仍在使用。說明別的國家通過討論，決定更改。而美國不只本身的國會通過了討論，而且也知作別的國家的更改制度理由。能夠理解爲美國接收到了「創新的宣傳」，但仍未作出更改。因此，我認爲，這裏的例子並不能很好地說明觀點。

迷思之五：要成爲領域的專家、才能創新

這句標題與文中的例子未免都有以偏概全的嫌疑。對於無數的創新過程，書中僅僅以幾例就駁倒創新與領域專家之間的關係。而標題更是忽視了可能存在的反例。對於這部分信息，我更想知道的是對於不一樣的領域，專家和創新之間的關係，是計算機領域的獨特性質（早期待發展的部分不少）致使了這種現象麼？仍是這是一個普適的結論？

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

軟件

軟件（英語：software）是一系列按照特定順序組織的計算機數據和指令，是計算機中的非有形部分。計算機中的有形部分稱爲硬件，由計算機的外殼及各零件及電路所組成。計算機軟件需有硬件才能運做，反之亦然，軟件和硬件都沒法在不互相配合的情形下進行實際的運做。軟件一詞，最先於1953年在Richard R.Carhart的備忘錄中被使用使用。

軟件工程

軟件工程（英語：software engineering），是軟件開發領域裏對工程方法的系統應用。

1968年秋季，NATO（北約）的科技委員會召集了近50名一流的編程人員、計算機科學家和工業界巨頭，討論和制定擺脫「軟件危機」的對策。在那次會議上第一次提出了軟件工程（software engineering）這個概念，研究和應用如何以系統性的、規範化的、可定量的過程化方法去開發和維護軟件，以及如何把通過時間考驗而證實正確的管理技術和當前可以獲得的最好的技術方法結合起來的學科。它涉及到程序設計語言、數據庫、軟件開發工具、系統平臺、標準、設計模式等方面。其後的幾十年裏，各類有關軟件工程的技術、思想、方法和概念不斷被提出，軟件工程逐步發展爲一門獨立的科學。

1993年，電氣電子工程師學會（IEEE）給出了一個更加綜合的定義："將系統化的、規範的、可度量的方法用於軟件的開發、運行和維護的過程，即將工程化應用於軟件開發中"。此後，IEEE屢次給出軟件工程的定義。

在現代社會中，軟件應用於多個方面。典型的軟件好比有電子郵件、嵌入式系統、人機界面、辦公包、操做系統、網頁、編譯器、數據庫、遊戲等。同時，各個行業幾乎都有計算機軟件的應用，好比工業、農業、銀行、航空、政府部門等。這些應用促進了經濟和社會的發展，提升人們的工做效率，同時提高了生活質量。

參考資料：軟件， 軟件工程

【附加題】：你們知道了軟件和軟件工程的起源，請問軟件工程發展的過程當中有什麼你以爲有趣的冷知識和故事？

Git 誕生背後的小故事

同生活中的許多偉大事件同樣，Git 誕生於一個極富紛爭大舉創新的年代。Linux 內核開源項目有着爲數衆廣的參與者。絕大多數的 Linux 內核維護工做都花在了提交補丁和保存歸檔的繁雜事務上（1991－2002年間）。

不少人都知道，Linus在1991年建立了開源的Linux，今後，Linux系統不斷髮展，已經成爲最大的服務器系統軟件了。

Linus雖然建立了Linux，但Linux的壯大是靠全世界熱心的志願者參與的，這麼多人在世界各地爲Linux編寫代碼，那Linux的代碼是如何管理的呢？

事實是，在2002年之前，世界各地的志願者把源代碼文件經過diff的方式發給Linus，而後由Linus本人經過手工方式合併代碼！

爲何Linus不把Linux代碼放到版本控制系統裏呢？不是有CVS、SVN這些免費的版本控制系統嗎？由於Linus堅決地反對CVS和SVN，這些集中式的版本控制系統不但速度慢，並且必須聯網才能使用。有一些商用的版本控制系統，雖然比CVS、SVN好用，但那是付費的，和Linux的開源精神不符。

不過，到了2002年，Linux系統已經發展了十年了，代碼庫之大讓Linus很難繼續經過手工方式管理了，社區的弟兄們也對這種方式表達了強烈不滿，因而Linus選擇了一個商業的版本控制系統BitKeeper，BitKeeper的東家BitMover公司出於人道主義精神，受權Linux社區無償使用這個版本控制系統。

安定團結的大好局面在2005年就被打破了，緣由是Linux社區牛人彙集，難免沾染了一些梁山好漢的江湖習氣。開發Samba的Andrew試圖破解BitKeeper的協議（這麼幹的其實也不僅他一個），被BitMover公司發現了（監控工做作得不錯！），因而BitMover公司怒了，要收回Linux社區的無償使用權。

Linus能夠向BitMover公司道個歉，保證之後嚴格管教弟兄們，嗯，這是不可能的。

開發 BitKeeper 的商業公司同 Linux 內核開源社區的合做關係結束，他們收回了無償使用 BitKeeper 的權力。這就迫使 Linux 開源社區（特別是 Linux 的締造者 Linus Torvalds ）不得不吸收教訓，只有開發一套屬於本身的版本控制系統纔不至於重蹈覆轍。他們對新的系統制訂了若干目標：

• 速度
• 簡單的設計
• 對非線性開發模式的強力支持（容許上千個並行開發的分支）
• 徹底分佈式
• 有能力高效管理相似 Linux 內核同樣的超大規模項目（速度和數據量）

最後實際狀況是這樣的：Linus花了兩週時間本身用C寫了一個分佈式版本控制系統，這就是Git！一個月以內，Linux系統的源碼已經由Git管理了！牛是怎麼定義的呢？你們能夠感覺一下。

Git迅速成爲最流行的分佈式版本控制系統，尤爲是2008年，GitHub網站上線了，它爲開源項目免費提供Git存儲，無數開源項目開始遷移至GitHub，包括jQuery，PHP，Ruby等等。

歷史就是這麼偶然，若是不是當年BitMover公司威脅Linux社區，可能如今咱們就沒有免費而超級好用的Git了。

參考資料：Linux， Linux創始人，CVS， SVN， BitKeeper， Git

上網調查一下目前流行的源程序版本管理軟件和項目管理軟件都有哪些， 各有什麼優缺點？

優缺點對比

RCS

• 簡單
• 使用 Lock 機制防止多個開發人員對同一個文件同時進行修改

CVS

• 使用單一的主代碼樹,而不像 RCS 那樣依賴多個目錄
• 多名開發人員能夠同時對一個文件進行修改.容許合併，實現併發開發。

SVN

• 目錄的版本控制 CVS 只能對文件進行版本控制，不能對目錄進行版本控制。
• CVS 只能注意到，一個文件在一個位置被刪除了，而在一個新位置建立了另一個文件。因爲它不會鏈接兩個操 做，所以也很容易使文件歷史軌跡丟失。
• SVN 能夠原子性提交。
• 當任何緣由形成批量操做的中斷時（典型緣由包括：網絡中斷、客戶端死機等），版本庫每每處於一個不一致的狀態

Git

• 採用了分佈式版本庫的方式，沒必要服務器端軟件支持，使源代 碼的發佈和交流極其方便。
• 速度很快。
• 擁有合併跟蹤（merge tracing）能力。
• 適合分佈式開發項目

使用人數對比

Name	Users	Projects	Alexa rank (lower = more popular)
Assembla	Unknown	526,581+	37,451 as of 25 December 2018
Bitbucket	5,000,000	Unknown	869 as of 25 December 2018
GitHub	31,000,000	100,000,000	61 as of 25 December 2018
GitLab	100,000	546,000	1,885 as of 25 December 2018
GNU Savannah	93,346	3,848	67,386 as of 25 December 2018
Launchpad	3,965,288	40,881	7,481 as of 25 December 2018
OSDN	54,826	6,294	6,429 as of 25 December 2018
Ourproject.org	6,353	1,846	794,540 as of 25 December 2018
SourceForge	3,700,000	500,000	377 as of 25 December 2018

來源：Wikipedia : Comparison of version-control software