第一次閱讀做業

軟件工程第一次閱讀做業

項目	內容
本次做業所屬課程	2019BUAA軟件工程
本次做業要求	第1次我的做業
我在本課程的目標	熟悉軟件工程流程，瞭解團隊開發
本次做業的幫助	幫助理解《構建之法》,更深刻了解課程大綱

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

問題1.1 第二章 我的技術和流程

單元測試必須由最熟悉代碼的人(程序的做者)來寫。
單元測試應該覆蓋全部的代碼路徑。

​看到這兩條，我發現OO課後期的要求也是這樣的（在書上看到了不少去年OO的方法論），可是當時由於全部做業都是我的做業所以沒有想過其中的道理，可是我對這個存在必定的疑問。我認爲一個程序員在面對一個問題去思考解決方法的時候頗有可能會存在必定的考慮不全的問題，會有必定的思惟受限的問題。我以爲讓做者繼續寫單元測試的話做者不少針對問題的遺漏點還會繼續發現不出來，因此我以爲應該須要第二我的輔助進行單元測試來發現思路以及設計上的遺漏點。
另外有個問題，單元測試要求覆蓋全部的代碼路徑，是須要在完成基本的代碼調試以及性能優化以後進行仍是說從完成程序編碼就進行？書的後文提到單元測試須要與代碼一塊兒維護，若是每次作修改都須要覆蓋全部的代碼路徑帶來的維護成本是否會過大？

問題1.2 計算機專業考級真的有用嗎

職業發展——考級之路

在中國，軟件工程師的職業資格考試有: 計算機等級考試和全國計算機技術與軟件專業技術資格考試

​這個我有必定的疑問，在大學期間，你們對CCF認證或者英語四六級的考試的重視程度遠遠大於上述的兩個認證，並且從師兄師姐那裏並未據說公司以及導師招收研究生時對上述證書有要求，甚至在網上的大部分評論說這些證書比較「雞肋」，遠遠比不上網絡工程師等證書含金高。因此我也有點疑問:做爲計算機專業學生是否須要考取這些證書呢？

問題1.3 多個同類型變量的實體不能在同一行定義嗎？

更嚴格的說不要把多個變量定義在同一行上

Foo foo1,fool2; //bogus

​儘管代碼規範並無一個徹底肯定的標準，可是我對這個不容許多個變量定義在同一行的要求仍是有些不解。我我的習慣是將同類型的變量放在一行上，不一樣類型的變量會分開行，可是按照這條要求來講，假設如今代碼中出現三個學生實體，須要一行行定義這幾個實體嗎，以下所示:

typedef struct{
    ...
}Student;

int main(){
    Student student0;
    Student student0;
    Student student0;
}

總以爲這樣寫有點冗餘，可否請老師解釋一下這個的分行寫的緣由以及不分行寫的壞處嗎？

問題1.4 變量命名

​書上也對變量作出了必定的要求，我對書上所說的持確定態度。恰好這個寒假作馮如杯的時候由於牽扯網頁開發全部接觸了一些js腳本，可是看到不少js腳本中的全部代碼都是一行並且不少變量名都是以a b c這種簡單的單字母命名。上網查閱資料說壓縮爲一行以及採用極簡不可讀的變量名是爲了更快的加載渲染速度，我對這種作法比較懷疑，十分懷疑代碼的可維護性。請問老師對這種行爲有什麼見解呢？

問題1.5 goto語句的使用

函數最好有單一的出口，爲了達到這一目的，可使用goto。

​書上說爲了實現單一出口，使用goto語句跳到函數/方法的末尾，我認爲這個跟直接在每一個返回點上直接寫return語句並無本質上的區別。並且在前期全部編程課程上(好比數據結構，編譯原理等)老師都強烈反對使用goto語句，我反對書上的這個觀點。

問題1.6 類以及面向對象編程

僅在必要的時候，才使用"類"

若是隻是數據的封裝，使用struct便可

類不能濫用這點比較贊同，以上學期的編譯原理課程設計過程爲例，編譯過程自己就是一個串行化比較高的過程，這個時候強行把語法分析、中間代碼生成、代碼優化建立一個類實際上是至關於給一些過程函數強行封裝了一些類的外觀，本質沒有什麼改變，反而增長了代碼理解上的困難。可是後面我想請問，爲何數據的封裝儘可能不要使用c++的class呢，是由於效率的問題嗎？

問題1.7 結對編程

在開發層次，結對編程能提供更好的設計質量和代碼質量，兩人合做解決問題的能力更強。

不適合結對編程的狀況——.......

​首先針對第一個課本闡述的結對編程的優勢，在我看來優勢並非絕對的，並且是理想化的，不一樣同窗在編程的時候的設計和思路差別會很大，若是兩我的一塊兒結對很大機率會出現兩我的分歧很大，沒法談攏，因此我認爲在考慮項目是否須要結對編程的時候須要考慮到這個因素。
另外，對於下面的，課本上着重介紹了不適合結對編程的情形，可是什麼狀況下應該採用結對編程(我認爲不是除了不適合以外的補集吧，有些狀況下適合用結對編程可是沒有必要，好比兩個能夠並行的項目開發並且須要在較短期完成，這時候可能每人各負責一塊會效率更高)，何時採用並行編程？

問題1.8 敏捷流程

敏捷編程最重要的一個前提就是scrum master要將當前的任務切成一個一個的小塊進行分配。可是在實際工做中，有些任務並無嚴格的獨立模塊，這種狀況下如何進行劃分，換言之，若是兩個衝刺之間有前驅和後繼的關係，可能會出現前驅的滯後會影響後繼事件的推動與進程，這種狀況該如何處理。scrum大師究竟在中間起到什麼做用，爲何不讓兩個程序員直接進行溝通，而必須經過master做爲中介傳遞信息？同時，這個過程是否過分依賴scrum master的我的能力了(從master的職能來看，團隊的運做很大程度依靠他的任務分配和分工協做)？

問題1.9 一個領域的創新真的跟本領域的專家關係不大嗎？

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

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

​我對這個觀點總體上持確定態度，誠然，萬事萬物都不絕對，並不是成爲一個領域的專家才能創新。可是我對書上所說「70%的創新者說他們最成功的創新是在他們的拿手領域以外發現的」這個70%的比例有些存疑，我認爲領域外的創新是存在的，可是在整個領域的創新所佔的比例是較小的。大部分創新點的提出是基於對該領域有着深入的理解與知識儲備的，除此以外還有運氣和靈光的成分。某領域內若是一個外行能夠提出一個創新點，我認爲後者是主要的因素，可是對於這個領域與行業的長久發展以及推動做用每每仍是這個領域的專家所完成的。

問題1.10 如何在程序的性能代價和程序開發代價之間找到合適的平衡點？

看了課本以及以前課程、網絡上了解到的知識，程序開發效率強調封裝以及代碼重用，良好的擴展性。可是遺憾的是每每過多的封裝、代碼重用以及爲拓展性增長的編碼每每會拉低程序的執行效率，從而影響程序的性能。因此在實際開發中，咱們應該如何解決這二者之間的平衡問題呢？

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

軟件：

軟件的第一個理論誕生於1935年，計算機之父阿蘭圖靈提出了軟件理論。可是同時也有人認爲軟件正式出如今1958年John Turkey的論文中。

軟件工程：

Margaret Hamilton 在1968年北大西洋公約組織在聯邦德國召開的國際會議上爲了討論軟件危機課題，正式提出並使用「軟件工程」這個名詞。

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

1)馮諾依曼的軼事

「有個著名的蒼蠅問題，兩人騎車從相距20英里的兩地相向行駛，兩人均保持穩定的10英里時速，一隻蒼蠅以15英里的速度從一輛車前輪飛向另外一輛車輪前輪，飛到時再折返，直到被兩車前輪擠扁。

問題是：這隻蒼蠅一共飛行了多長距離？（這個中國學生都會）

笨辦法是算出第一段從一車輪到另外一車輪距離，再算下一段，以此類推，最後全都加起來。
聰明的辦法是注意到兩個自行車從開始到相遇一共用時1小時，因此蒼蠅也飛了1小時，距離就是15英里。」
當這個問題拋給馮·諾依曼的時候，他當即解答出來了，還顯得對提問者很失望。
「噢，你必定早知道這個題的技法了！」
「什麼技法？」 馮·諾依曼問道，「我就是作了無窮數列求和而已。」

2)

1975年，艾倫和蓋茨給Altair 8800計算機寫了個BASIC解釋器賣給MITS，他們很快完成了解釋器，甚至包括本身的IO系統和編輯器，一共只須要4k內存。 不過最後他們發現還須要一個引導程序將這些東西從外存整進去。 Paul Allen在飛機航班上完成了這項工做。這是1975年，沒有筆記本。他用的是紙筆。寫的是8080機器碼。

注：以上兩個故事來源知乎

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

從維基百科中能夠看出來近年來流行的源程序版本管理軟件的流行狀況。

很遺憾的是表中並無Mercurial / Trac / Bugzilla 這三種工具的用戶數，下面將依次列舉一下git /Mercurial / Trac / Bugzilla 這四種源程序版本管理軟件的優缺點。

• git(包括github和gitlab)

  • 優勢:
    • 可用性好，十分方便；
    • 用戶多，項目多，利於交流學習；
    • 有本身的十分強的功能（pull request,issue） 等
  • 缺點:
    • 對中文支持太差；
    • 前期學習知識較多

• bitbucket

  • 優勢:
    • 支持私有免費項目；
    • 提交大文件速度快。
  • 缺點:
    • 不容易找到項目；
    • 社區活躍度不是那麼大。

• Mercurial

  • 優勢:
    • 照顧命令行用戶，大多數命令都有雙字母的簡稱，效率更高。
    • 照顧SVN的遷移用戶，命令上大多數都繼承自SVN，使得用戶更加習慣。
    • 基於Python，服務器配置相對於Git更加容易。
  • 缺點:
    • Mercurial的branch管理和Git相比不方便，branch出來就刪不掉。

• Trac

  • 優勢:
    • 十分靈活，支持定製；
    • Trac有良好的擴充性；
    • Trac的權限體系是比較完備的設計。
  • 缺點:
    • 不支持多項目；
    • 對中文的支持差；
    • 需求和缺陷沒有分離。

• Bugzilla

  • 優勢:
    • 定製功能很強；
    • 對語言的支持很強；
    • 免費，響應速度較快 。
  • 缺點:
    • UI設計差；