軟件工程第1次做業

項目	內容
本次做業所屬課程	2019BUAA軟件工程
本次做業要求	第1次我的做業
我在本課程的目標	學習軟件工程的相關知識，瞭解團隊協做編程，爲之後的工做打下基礎
本次做業的幫助	經過閱讀其餘博主的博客，瞭解了許多優秀的人的學習和工做經歷，他們對於計算機的理解，幫助本身選擇將來的路。

快速看完整部教材，列出你仍然不懂的5到10個問題，發佈在你的我的博客上。

2.1.2 「單元測試必須由最熟悉代碼的人（程序的做者）來寫。」

在檢查編寫的代碼的過程當中，做者每每只能考慮到本身在寫程序時考慮到的和遇到的問題，這些問題應該很早就被做者本身解決了，若是在進行單元測試時，因爲本身寫程序的慣性思惟，應該很大可能性會忽略掉其餘一些重要的地方。若是選擇另一名，瞭解程序框架（其實只須要知道各函數的輸入輸出等少許信息就好，這樣反而更容易測試出做者沒想到的地方的bug）的人來進行單元測試，效果應該會更好。

4.3.2 "只要有助於程序邏輯的清晰體現，什麼方法均可以使用，包括goto。"

在咱們一開始學習編程時，老師就一直向咱們強調不管是什麼緣由，都不要使用goto。經過幾個學期的學習後，尤爲是在學習面向對象，編譯以後，更可以感覺到當開發一個大型項目時，保持程序的邏輯性，可讀性是最重要的。雖然使用goto可以在寫程序的時候減小一些工做量，但更多時候，咱們會發現可能連本身在前一段時間寫的程序都難以看懂，更何論軟件工程中多人開發。我的認爲若是使用了goto會使得程序後續的可讀性，可理解性大大下降。

並不一樣意做者所說的可使用goto的理由，總的來講使用goto是弊大於利的。

4.5.4 描述結對編程的細節以下：

駕駛員：寫設計文檔，進行編碼和單元測試等XP開發流程。

領航員：審閱駕駛員文檔；監督駕駛員開發流程的執行；考慮單元測試的覆蓋率；思考是否須要和如何重構；幫助駕駛員解決具體的技術問題；設計TDD中的測試用例。

駕駛員和領航員不斷輪換角色，不要連續工做超過一小時，工做一小時休息15分鐘。領航員控制時間。

不一樣的人之間的編程習慣，思惟習慣差異是較大的，並且編程應該是一個連續性的工做，並不能理解這種兩我的輪流編寫同一段程序的作法。書中所舉的駕駛員，副駕駛的例子，和結對編程並不相同，由於例子中的駕駛員和副駕駛並不會互相交換身份，他們之間是一種協做關係，而非一種替換關係，每人的工做都是連續的，同時也會更加熟練。我認爲結對編程並不能提升編程，debug的效率。

16.1.4 「迷思之四：創新者都是身先士卒...其實，大部分紅功的創新者都不是先行者，例如搜索引擎，Google是很晚才進入這個領域的。"

確實如做者所說，計算機領域，尤爲是IT中，不少先行者都被淘汰掉了。因爲互聯網天生的互聯特性，咱們也發現整個行業逐漸出現了幾大寡頭，若是提出了一些創新，也常常敗在這些互聯網巨人的資本之下，這是否意味着將來的IT領域，創新者的生存空間在逐漸縮小？

16.1.5 迷思之五: 要成爲領域的專家，才能創新

爲何領域的專家有時候沒有領域外的創新者那麼有新意？這也是一個頗有意思的話題

創新的概念到底是什麼？是像做者所舉例子中的創新者同樣提出一個全新概念，仍是說將一個領域鑽研透徹，發掘這個領域的更深之處？對於做者所說的「70%的創新者說他們最成功的創新是在他們的拿手領域以外發現的」，這個70%我是存有必定疑慮的，就像計算機是由一羣數學家研究出來的同樣，對他們而言，計算機他們是否也是在他們的拿手領域以外發現的創新？但是正是由於沒有人研究過這種事物，才更能說明他是創新呀。當那羣數學家在計算機領域中取得更多的成果之時，這又究竟是不是他們所研究的領域呢？

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

軟件：1958年，John Tukey，在其論文"The Teaching of Concrete Mathematics"中提出

維基百科-John Tukey

軟件工程：阿波羅11號的軟件開發期間，Margaret Hamilton提出

Linux中國開源社區

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

Git的誕生

Linus在1991年建立了開源的Linux，今後，Linux系統不斷髮展，成爲最大的服務器系統軟件。Linus雖然建立了Linux，但Linux的壯大是靠全世界熱心的志願者參與的。在2002年之前，世界各地的志願者把源代碼文件經過diff的方式發給Linus，而後由Linus本人經過手工方式合併代碼。

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

安定團結的大好局面在2005年就被打破了，緣由是開發Samba的Andrew試圖破解BitKeeper的協議（這麼幹的其實也不僅他一個），被BitMover公司發現了，因而BitMover公司怒了，要收回Linux社區的無償使用權。

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

Linus花了兩週時間本身用C寫了一個分佈式版本控制系統，這就是Git！

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

請按照最近一兩年使用人數的多少， 從多到少排序並說明各自有多少用戶（估計），工具的優缺點（能夠引用相關資料並註明來源）。

下圖爲源代碼託管服務的用戶數，能夠從中推測出對應的管理軟件的用戶數。

維基百科-Comparison of source-code-hosting facilities

Git

優勢：

• 免費且開源。
• Git支持分支功能（branch）。若是開發一個新的產品功能，能夠創建一個分支，對這個分支的進行修改，而不至於會影響到主支上的代碼。
• 可拿Git作備份系統，或者同步多臺機器的文檔，很方便。
• 支持離線工做。本地提交能夠稍後提交到服務器上，不用和集中的代碼管理服務器交互。 只有最終完成的版本才須要向一箇中心的集中的代碼管理服務器提交。
• Git 提交都是原子的，且是整個項目範圍的。
• Git 中的每一個工做樹都包含一個具備完整項目歷史的倉庫。

缺點：

• 學習成本大。由淺入深的過分很漫長，須要大量時間的投入。
• Git版本庫須要頻繁的手動維護。

SVN

優勢：

• 對目錄的組織的管理更加方便。SVN不光對文件作版本跟蹤，也會對目錄作版本跟蹤。所以能夠根據項目的須要，對目錄結構隨時進行修改，能夠把現有的目錄移動到新的地方。
• 保證提交操做的完整性。SVN對提交操做的處理方式相似數據庫的事務處理，要麼所有成功，要麼所有無效，保證了原子性。
• SVN容許一個文件有任意多的可命名屬性，功能十分徹底。

缺點：

• 不能離線工做。全部的版本信息都放在服務器上。若是脫離了服務器，開發者基本上能夠說是沒法工做的。
• 提交、更新、瀏覽歷史的速度慢。耗費CPU資源。
• 代碼不能及時提交。強迫使用者即時處理衝突，而後才能提交。
• 不能恢復到歷史版本。SVN記錄了單個文件的歷史版本，但沒有記錄全局版本，不能恢復到上次的狀態。

Microsoft TFS

優勢：

• 任務版上能將需求、項目進度盡收眼底，集成了項目管理、版本控制、BUG 跟蹤。
• 能有效實現 SCRUM，能與 VS 無縫接合。

缺點：

• 搭建、維護tfs比較複雜，硬件要求也比較高。
• 整個系統是用 asp 實現的，用瀏覽器訪問較慢。

Mercurial

優勢：

• 學習門檻較低。總體上看，hg須要掌握的命令要比git少不少。
• 能夠一鍵徹底恢復到歷史版本的某一個切面。
• 封裝好。相比git，hg不多暴露一些實現內的細節。
• 照顧 svn 的遷移用戶。hg 的不少命令是遷移自 svn 命令的，習慣 svn 命令的團隊，幾乎能夠零成本的切換到 hg。
• hg的版本庫不須要維護。

缺點：

• 分支管理不靈活。Mercurial的branch管理和Git相比不是很方便。不適合大型團隊使用。

我的認爲Git使用率較高的緣由

git在全世界範圍內的使用量較高，除了上述介紹的git自己的易用性之外，我的認爲還跟許多重要項目使用git進行管理也有關係。固然git的易用性，github等託管平臺的開放性，也反過來提高了這些項目的使用量。例如在overflow的2018年的調查中，有如下這些有趣的信息：

程序員們最喜歡使用的數據庫，其中排名較高的redis，elasticsearch等，都在github上進行管理。

更不用說開發的平臺，畢竟研發git的重要緣由就是爲了管理linux的開發：

最喜歡的開發環境，Visual Studio Code，vim等：