【軟工】第1次閱讀做業

項目	內容
這個做業屬於的課程是	2019BUAA軟件工程
做業要求是	第1次閱讀做業要求
我在此次的目標是	系統學習軟件工程的理論知識併成功應用到實踐中來
這個做業在哪些方面幫助我實現目標	經過閱讀《構建之法》以及進行相關的調研工做，對軟件工程的理論知識有了更進一步的認識

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

問題1：單元測試應該由誰來寫？

書中（P25 2.1.2 好的單元測試的標準）提到：

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

此言一出，我立馬想到大二下的面向對象課程，你們常常在私底下交換測試用例，緣由大概就是「三個副將，頂個諸葛亮」。編程者若是沒有考慮到要處理某一個特殊狀況，那麼他就不可能設計相應的測試，從而錯誤地認爲本身的代碼是完美的。爲了防止這種狀況發生，你們每每會私下共享測試樣例，以保證本身的代碼能應付一些特殊狀況的輸入。

雖然「三個副將，頂個諸葛亮」具備必定的合理性，可是卻沒法運用在實際中：

• 從單元模塊的角度講，實際的軟件工程中，出於成本和效率的考量，一個單元模塊主要由一我的進行負責，沒有人會跟你作同一個單元模塊來防止所謂的「一我的可能考慮不周」，而若由單獨的測試人員進行單元測試，每每工做量大，週期長，耗費巨大，其結果事倍功半（參見這裏）。倒不如僱傭/培養一個諸葛亮。
• 從系統測試的角度講，共享測試樣例這個事兒，對於OO課來講，是兩我的的共享測試，可對於軟件工程來講，是兩個團隊的共享測試，然後者是不可能發生的（一個公司總不會用兩個團隊去開發徹底同樣的軟件）。

因此，我仍是比較贊成書中做者的觀點：單元測試仍是應該由「最瞭解代碼的目的、特色和實現的侷限性」的做者來完成，並且「最好是在設計的時候就寫好單元測試，這樣單元測試就能體現API的語義」。

問題2：什麼時候使用goto語句更爲合理？

書中（P69 4.3代碼設計規範）提到：

函數最好有單一的出口，爲了達到這一目的，可使用goto。只要有助於程序邏輯的清晰體現，什麼方法均可以使用，包括goto。

這兩句簡短的話讓我回憶起C語言的教程中每每明確寫着「儘可能不要使用goto」，緣由大概是跳來跳去的容易使程序結構不清晰。可是書中隨後給出的代碼清單4-2又讓我以爲加上goto語句確實邏輯挺清晰的。

下面是書中代碼清單4-2：

HRESULT  HrDoSomething(int parameter) 
{    
    //parameter check and initialization     
    //processing part1     
    If (SomeCode() != ok)     
    {         
        //set HR value         
        Goto Error;      
    }     
    //processing part1     
    If (SomeCode() != ok)     
    {
        //set HR value         
        Goto Error;      
    } 
Error:     
    //clean up free resource, reset state, etc
    return hr;  
}

在閱讀了博客1和博客2後，總結出goto的優缺點和結論大體以下：

• 缺點：GOTO語句使程序的靜態結構和動態結構不一致，從而使程序結構不清晰，難理解，難查錯。去掉GOTO語句後，可直接從程序結構上反映程序運行的過程，不只使程序結構清晰，便於理解，便於查錯，並且也有利於程序的正確性證實。
• 優勢：使用起來比較靈活；有些情形能提升程序的效率。若徹底刪去GOTO語句，有些情形反而會使程序過於複雜，增長一些沒必要要的計算量。
• 結論：不加限制地使用GOTO語句，特別是使用往回跳的GOTO語句，會使程序結構難於理解，在這種情形，應儘可能避免使用GOTO語句。但在另一些狀況下，爲了提升程序的效率，同時又不至於破壞程序的良好結構，有控制地使用一些GOTO語句也是必要的。

至於做者提到的「函數最好有單一的出口，爲了達到這一目的，可使用goto」，這篇簡短的博客給出了單出口函數的兩種代碼結構，一種是使用goto，另外一種是使用do while(0)和break。本人以爲更偏好goto語句來實現。（畢竟雖然寫高級語言時沒用過goto，可是寫彙編語音時對goto已經比較接受了）

私覺得做者能夠在書中對goto語句多作些說明，畢竟可能有一大波人學C的時候也跟我同樣沒太弄懂。「既然課本說別用goto，那我不用就是了」。

問題3：對於結對編程不大承認，還需實踐檢驗。

書中（P79 4.5 結對編程）提到：

• 在結對編程模式下，一對程序員肩並肩、平等地、互補地進行開發工做。他們並排坐在一臺電腦前，面對同一個顯示器，使用同一個鍵盤、同一個鼠標一塊兒工做。他們一塊兒分析，一塊兒設計，一塊兒寫測試用例，一塊兒編碼，一塊兒作單元測試，一塊兒作集成測試，一塊兒寫文檔等等。
• 駕駛員和領航員不斷輪換角色，不要連續工做超過一小時，工做一小時休息15分鐘。領航員控制時間。

對於這樣的結對編程方式，我從直覺上，仍是比較持懷疑態度，畢竟兩我的的水平可能不一樣，思路也可能不一樣，須要調研的東西可能也不一樣，比較難以達到同頻道的狀態（好比我對C++不大熟練一些語法問題可能還須要現場百度）。

直覺上是懷疑，可是行動上仍是要試試看的。我的認爲能夠在某些階段進行結對編程，其它一些時間就並行編程。（感受須要先好好理解做業要求，細緻地劃分多個階段和模塊，調研一下算法，熟悉一下語言，而後再看哪些部分要結對編程，哪些部分要並行編程。）

問題4：PM在本課程項目中的具體任務

書中（P189 9.3 PM作開發和測試以外的全部事情）提到在一個項目中PM的具體任務：

1. 帶領團隊造成團隊的目標/遠景，把抽象的目標轉化爲可執行的、具體的、優美的設計；
2. 管理軟件的具體功能的生命週期（需求/設想/設計/實現/測試/修改/發佈/升級/遷移/淘汰）；
3. 建立並維護軟件的規格說明書，讓它成爲開發/測試人員及時準確的指導，而不是障礙；
4. 表明客戶和用戶的利益，主動收集用戶反饋，預期用戶新的需求。協調並決定各類需求的優先級；
5. 分析並帶領其餘成員對缺陷/變動需求造成一致意見，並確保實施；
6. 帶領其餘成員確保項目保持功能/時間/資源的合理平衡，跟蹤項目進展，確保團隊發佈令客戶滿意的軟件；
7. 收集團隊項目管理和軟件工程的各類數據，客觀分析項目實施過程當中的優缺點，推進項目成員持續改進，從而提振士氣。

可是我認爲，在本課程中，爲了使咱們的軟件可以推廣出去（畢竟仍是很想有用戶量和用戶反饋的），PM除了上述任務，還應負擔起市場調研、競品分析、運營推廣等工做，彷佛加入了許多產品經理的活兒。

而這些任務所有加起來，對於產品經理的要求是很高的，他必須懂市場、懂調研、懂營銷、懂管理、（他可能還想借着軟工課鍛鍊本身的代碼能力，好比承擔一部分測試工做），這樣的人可能難以尋找或快速培養。此時是找一個最合適的人頂上去培養成全職PM，仍是找幾個程序員兼職作PM（頂一個諸葛亮），是一個問題。具體以爲還須要看項目團隊的定位和目標吧。

問題5：在這個時代，創客們更須要注重哪一種創新？

書中（P349 16.1.6 迷思之六：技術的創新是關鍵）提到：

咱們在這裏看到，除了技術的創新，還有不少方面的創新：商業模式的創新…用戶體驗的創新…生態系統的創新…

說到創新，我就想到了創業，若是從一個創業者的角度出發，他應該最看重什麼方面的創新呢？

在我看來，首先確定不是生態系統的創新。緣由有二：

1. 現在各個領域的生態系統大都比較完善。
2. 即使找到了一個生態系統的可創新之處，造成一個新的生態系統也很難，由於生態系統這是大而空的「鏈接方式」，裏面須要有具體的「鏈接物」，即產品或服務。然而，原來的生態系統雖然不完善，但確定已經有了一些市場佔有者，不管是將他們聯繫起來，仍是去白手創造本身的產品或服務系統，都是比較難的。

其次，創客們最應看重的，也應該不是用戶體驗的創新。在這個網站找到了用戶體驗的方方面面：

我以爲這方面用戶要求很高，產品的用戶體驗也比較完善了。若是要進行用戶體驗的創新，可能更多仍是技術支持下的創新，好比VR。

最大的PK可能仍是商業模式的創新與技術的創新。我在這篇報道中，發現了許多不一樣的聲音：

• 尋找中國創客發起人、北京文投集團總經理戴自更認爲，如今模式創新的時代已通過去，科技創新纔是常青的風口：

  過去由於抓住了移動互聯網爆發的契機，中國的新經濟取得了一些成績，但這些成績很大程度上得益於商業模式的創新，以及依賴巨大的人口紅利實現模仿中的超越。他認爲，如今模式創新的時代已通過去，科技創新纔是常青的風口。

• 中國創客導師、信中利資本集團創始人、董事長汪潮涌認爲，對於AI產業來講，技術和算法難以成爲AI產業的核心壁壘，惟一道路是成爲偉大的AI產品公司。

  AI創業者面臨「落地之痛」。商業化之路要以技術爲基礎、用戶需求爲導向、落地場景爲核心，想要成爲巨頭，就要成爲偉大的AI產品公司。目前單純靠技術和算法的紅利期已通過去了。新成立的AI公司應該打「組合拳」，而不止作技術服務商，隨着技術門檻下降，離用戶需求最近的產品經理和行業專家將成爲團隊的主導，二者的結合能夠造成產品經理和技術專家爲主導的產品級的公司。

• 中國工程院院士、香港中文大學（深圳）校長徐揚生認爲，更重要的是技術創新，可是要注意從解決市場需求的角度入手。

  深圳龍崗有不少創新企業，但商業模式的創新比較多，技術創新比較少。深圳和硅谷的差別在哪裏？硅谷作的事是0到1的事，是科研上的創新，而深圳作的是1到N的事。只有「0到N」纔是技術和產業的創新。過去，人工智能領域經常是有了技術以後纔去找落地應用、推進產業化，但成功的不多。創業者們應當着眼於市場的需求，從如何解決市場需求入手，反推再去進行技術方面的落地。

我比較支持最後一個觀點，「更重要的是技術創新，可是要注意從解決市場需求的角度入手。」

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

軟件：

• 軟件的第一個理論誕生於1935年，由計算機之父阿蘭圖靈提出。可是同時也有人認爲，是化學家和統計學家約翰·圖基（John W. Tukey）在1958年撰寫一篇科學文章時，首次使用「軟件」這一術語。

軟件工程：

• 1968年北大西洋公約組織在聯邦德國召開的國際會議上，爲了討論軟件危機課題，Margaret Hamilton 正式提出並使用「軟件工程」（Software Engineering）的這個名詞。提出把軟件開發從「藝術」和「個體行爲」向「工程」和「羣體協同工做」轉化。

第三部分 軟件工程發展的過程當中有什麼你以爲有趣的冷知識和故事？

如下內容來自知乎

著名的計算機科學家高德納（Donald E. Knuth），在他的鉅著《計算機程序設計藝術》（The Art of Computer Programming，TAOCP）出完第三卷後，終於對當時粗糙的排版技術忍無可忍，毅然暫停寫做，轉向後來在學術界滿載聲譽的排版軟件TeX的開發之中。

1. 他本來覺得他只須要半年時間，在1978年下半年就能完成，但最終他用了超過十年時間，直到1989年TeX才最終中止修改。
2. TeX的版本號碼也十分有趣。從TeX第三版開始，以後的升級是在小數點後加入一個新數位，使之愈來愈接近圓周率π的值。TeX目前的版本是3.1415926。這顯示了TeX已經十分穩定，任何的升級都十分細微。高德納曾表示「最後一次升級是（於我過世後）將版本數改成π，那時任何餘下的漏洞將被看做程序的功能。」
3. TeX是很是穩定的程序，高德納懸賞獎勵任何可以在TeX中發現程序漏洞（bug）的人。每個漏洞的獎勵金額從1美分開始，並每一年翻倍，直到目前的327.68美圓封頂。然而高德納從未所以而損失大筆金錢，由於TeX中的漏洞少之又少，而真正發現漏洞的人在得到支票後，寧願將其裱起來留做記念也不肯拿去兌現。

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

在維基百科找到了用戶量：

排名由高到低主要依次是：github, bitbucket, launchpad, sourceforge

優缺點列表以下：

項目	優勢	缺點
git	可用性好，方便；用戶和項目多，利於交流學習；對git版本庫提供了完整的協議支持；功能強大；	對中文支持太差；國內訪問速度太慢；前期學習知識較多
Mercurial	命令兼容SVN；擴展性強；學習門檻較低；基於Python，服務器配置相對於Git更加容易	功能太過簡陋；分支管理不靈活；中文使用資料匱乏。
Trac	SCM配置管理平臺；十分靈活，支持定製；	不顯示中文名，中文支持不好
Bugzilla	定製功能很強；免費，支持中文	功能不及GitHub；UI不夠好