【軟件工程】 第1次我的做業

項目	內容
這個做業屬於哪一個課程	軟件工程 羅傑
這個做業的要求在哪裏	第一次閱讀做業
我在這個課程的目標是	熟悉軟件開發總體流程，提高自身能力
這個做業在哪一個具體方面幫助我實現目標	經過學習《構建之法》，瞭解敏捷編程

讀《構建之法》的思考

Q1：3.1 re-work是否可以衡量代碼質量呢？

     「有人試圖用「re-work」來表示質量，如改動少的代碼最初質量高，由於re-work的次數少。筆者認爲，re-work只是代表在軟件開發過程當中花費的時間，re-work的多寡並不跟最終的質量成正比。」

     讀到此處，我想起了2.3章節中所提到的大學生和工程師在完成任務時的時間分配比例對比。其中，工程師將更多的時間用於「需求分析」、「具體設計」上，而少許時間用於「具體編碼」，其意義就是要先總體設計好在進行編碼，而筆者也認爲這樣的工做方式是高效的。
     那麼問題出現了，充分的設計的目的就是爲了減小re-work，假若某段代碼須要大量的re-work來進行修正，是否也就意味着設計階段不充分，並未爲後續的編碼節約時間呢？一段沒有被充分設計的代碼是否也能夠說質量並非很高呢？

Q2：4.3 函數中goto的使用？

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

    猶記得以前在學習C語言時，老師儘可能不要使用goto語句，由於它可能會致使程序結構比較複雜，且難以維護，還可能會使得程序存在某些隱患。
    在這裏咱們姑且不討論goto語句究竟是讓程序的邏輯更清晰仍是更復雜，我單純地沒有理解「用goto函數設置惟一出口」的意思是什麼呢？書中的舉例我認爲徹底能夠寫一個ERROR()函數實現，因此仍是沒有太理解goto語句的必要性。

Q3：4.5 結對編程真的利大於弊？

     「在結對編程模式下，一對程序員肩並肩、平等地、互補地進行開發工做。他們並排坐在一臺電腦前，面對同一個顯示器，使用同一個鍵盤......結對編程中有兩種角色：駕駛員和領航員。」

    根據書中所說，這種編程模式須要兩我的一點點磨合，一開始可能兩我的的開發效率甚至不如一我的，形成「1 + 1 < 1」的狀況。用這種成原本培養，是否真的值得呢？最終又真的可以達到「1 + 1 > 2」的程度嘛？一對結對編程小組中，若是一我的出現狀況，如生病、出差、甚至跳槽，另外一位只能孤身奮戰，或是和新的夥伴再次磨合，這不肯定性是否有些高呢？
    其次，書中將結對編程小組類比爲賽車中的駕駛員和領航員、飛機中的駕駛員和副駕駛，但不一樣的是，結對編程小組中兩我的的身份是不斷切換的，且頻率很高（15分鐘切換一次），如此高的切換頻率是否會浪費精力在適應身份上而沒法專心於編程或設計呢？

Q4：9.3 & 9.4 懂技術的PM是否要參與開發？

     曾經我一直覺得PM就是客戶與開發人員的鏈接通道，存在乎義就是將客戶提出的需求轉化爲設計交給開發人員。讀完第9章之後，才明白PM所須要作的遠遠不止這些，甚至PM的種類，也不是單一的一種。
     在班級中閱讀到HansBug的博客，發現博客中所說的「我的承擔了過多任務，而隊員沒法提供不少幫助，最終累垮」這種狀況，與書中9.3中將PM類比爲舵手有些類似。若是舵手參與划船，可能小船的速率會快一些，但方向、穩定性都會出現問題，衆多隊友沒法協調一致，最終到了一個計劃外的地方。因而可知，PM懂技術和參與開發並非必然的關係，懂技術是好事，如今只會寫原型PPT的PM比比皆是，懂技術起碼不會給開發部門提出難題，但並不意味着要直接參與到開發中去，正如9.3的標題「PM作開發和測試以外的全部事情」，作好需求分析、設計好產品，這自己也是對工程的很大幫助。

Q5：14.2 優化該何去何從？

     「分工以後，每一個角色爲了本身的績效而優化，會出現局部最優而全局未必最優的狀況。」

     讀到這個地方的時候我不由想起了以前第三章中提到的：「過早的優化是一切罪惡的根源」。因此到底應該什麼時候優化呢？前期代碼質量太低會致使後期優化任務太重，前期優化過多又會致使限制了全局的上限。並且該按照何種順序進行優化呢？

Q6：17.4 豬、雞和鸚鵡的故事

     「豬：提供豬肉，坐燻肉。
     雞：提供雞蛋，作煎蛋。
     鸚鵡：提供諮詢，天天閱讀大量博客，給其餘團隊成員提供建議......

     豬——全身心投入 雞——參與 鸚鵡——圍觀 」

     這是個頗有趣的比喻，重點在於要認清本身在一個團隊中的位置，「不要拿着賣白菜的錢，操那賣白粉的心」。但同時，也說明了一個穩定的團隊，其核心競爭力仍是在於「豬」的能力，「豬」可能指的是PM，可能指的是開發部門的老大，他必定是扛起公司的一分子，而他的綜合實力，決定了公司的實力。或者說，把能力強的人吸引到本身的團隊中，也許他最初只是「鸚鵡」或「雞」，但團隊的前景吸引着他加入團隊變爲「豬」，這個團隊就必定會愈來愈好。假若找了一羣「鸚鵡」組成團隊，最後也只落得做鳥獸散吧。

「軟件」和「軟件工程」這些詞彙是如何出現的？

• 軟件
      化學家和統計學家約翰·圖基（John W. Tukey）在1958年的論文「The Teaching of Concrete Mathematics」中提出了「軟件」這一律念，用來指代計算機程序，與使用程序的計算機（硬件）來加以區分。

• 軟件工程
      瑪格麗特·哈密爾頓（Margaret Hamilton）在1968年的「阿波羅計劃」期間提出了「軟件工程」這一律念。

軟件工程發展的過程當中，有哪些有趣的冷知識和故事？

• 第一個Bug
      在程序中bug一詞用於技術錯誤，這一術語最初由愛迪生在1878年提出的，但當時並無流行起來。幾年以後，美國上將葛麗絲·穆雷·霍普（Grace Murray Hopper）在她的日誌本中，寫下了她在Mark II電腦上發現的一項bug。不過實際上，她說的真的是「蟲子」問題，由於一隻蛾子被困在電腦的繼電器中，致使電腦的操做沒法正常運行。她將這隻蛾子保存在本身的日記本中，並寫道「這是我在電腦上發現的第一個bug」。（從未寫過bug的程序員可太強遼orz）

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

1.Git
     - 優勢：功能十分強大，適合分佈式開發，速度快較爲靈活，很好地處理分支，可離線工做。
     - 缺點：學習週期較長，不易上手，對初學者不太友好。

2.Mercurial
     - 優勢：與Git相比學習門檻低，易於掌握。
     - 缺點：功能比Git弱，分支管理不靈活。

3.Github
     - 優勢：操做簡單，極爲友好，開源代碼多（用戶量最多的同性交友平臺）。
     - 缺點：（我感受好棒想不出啥缺點qwq）

4.Microsoft TFS
     - 優勢：與Visual Studio完美接合，方便小團隊查看需求、項目進度等。
     - 缺點：搭建和維護都比較複雜，同時對硬件的要求也比較高。

5.Bugzilla      - 優勢：免費，有中文版，支持多項目缺陷追蹤，有極爲豐富的配置設定。      - 缺點：須要Perl和配置MySQL數據庫，修改配置比較麻煩。