【軟件工程】第一次閱讀做業

1.看完整部教材後，我仍然不懂的一些問題？

Q1：第四章 兩人合做

• 4.5.4 「如何結對編程」中提到

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

  這裏的「不能連續工做超過一小時，每工做一小時休息15分鐘」是否太過絕對？有時候編寫某個模塊時，工做狀態正好，若是忽然停下來去休息或者去作其餘輕鬆的事，反而會大大影響本身的工做效率。以我本身爲例，若是在很順手地編寫某一段代碼時，被打斷了一段時間，後面再繼續時會感受以前的「手感」徹底不見了。這裏是否是應該認爲判斷本身的效率降低時，選擇去休息調整更好？

Q2：第九章 項目經理

• 9.3 提到「PM作開發和測試以外的全部事情」，這裏設想一下，若是PM參與開發，是否是能更好地掌握當前的項目進度，從而更好地協調團隊內部外部，調配各部門資源和時間，更順利地完成項目計劃呢（這裏或許與書中問題中的舵手和划船手不一樣，PM參與開發並不意味着失去方向，而舵手參與划船則會使得船失去方向、穩定）？

Q3：第十三章 軟件測試

• 13.2.7的夥伴測試中，要求測試人員做爲開發人員的一個夥伴，並對其模塊在本地作必要的迴歸/功能/集成/探索測試。但是據書中前面所說，最好是開發人員本身寫測試，由於開發人員是最清楚本身代碼的人。那麼，爲何不讓開發人員進行測試？或者說給每一個開發人員分配一個測試人員進行結對？

Q4：第十六章 IT行業的創新

• 16.1.5 「迷思之五：要成爲領域的專家，才能創新」中提到

  「統計數據代表，70%的創新者說，他們最成功的創新，是在他們的拿手領域以外發現的」

  而關於領域內的專家有時候沒有領域外的創新者那麼有創意這個問題，是否是由於專家在這個領域研究得多了，被一些固有模式所絆住了呢？還有，若是創新就是知識->金錢的過程的話，那麼咱們去了解多個領域是否是更有利於咱們創新呢？

Q5：第十七章 人，績效和職業道德

• 17.1「領導力--帶領團隊成長」中，若是一個團隊剛剛成立，有一我的以技術見長，而一我的在相關原理知識方面更勝一籌，兩我的的其餘如交際能力等很好且相差無幾，那麼這兩我的哪一個更適合當團隊的領導，帶動團隊成長呢？

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

• The earliest known publication of the term "software" in an engineering context was in August 1953 by Richard R. Carhart, in a Rand Corporation Research Memorandum.（最先在工程背景下出版的術語「軟件」是由Richard R. Carhart在蘭德公司研究備忘錄中於1953年8月出版的。）
• Margaret H. Hamilton began to use the term "software engineering" during the early Apollo missions in order to give software the legitimacy of other fields such as hardware engineering.（<font face="微軟雅黑"在早期的阿波羅任務中，瑪格麗特·漢密爾頓開始使用「軟件工程」這個術語，以使軟件具備硬件工程等其餘領域的合法性。）

3.軟件工程發展的過程當中有趣的冷知識和故事？

​  說一說Lua語言的由來吧。Lua 是一個小巧的腳本語言，由標準C編寫而成，幾乎在全部操做系統和平臺上均可以編譯，運行。是由三個巴西人Roberto Ierusalimschy、Waldemar Celes、Luiz Henrique de Figueiredo發明。發明的緣由是巴西石油公司PETROBRAS沒辦法使用指定的硬件，使用公衆的資金須要經過一系列的嚴格手續，而且現有設備中什麼平臺什麼系統都有，因此Lua被設計成一個基於ANSI C開發能夠任意跨平臺的語言。

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

​   目前流行的源程序版本管理軟件和項目管理軟件：Microsoft TFS，Git, SVN, Mercurial，Trac等。其中版本管理軟件排行榜

• Microsoft TFS

  優勢：

  1. ​任務版上能將需求、項目進度盡收眼底，對於小團隊而言，比甘特圖更有用集成了項目管理、版本控制、BUG 跟蹤。
  2. 能有效實現 SCRUM，能與 VS 無縫接合。

  缺點：

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

• Git

  優勢：

  1. 公共服務器壓力和數據量都不會太大。
  2. 速度快、靈活。
  3. 任意兩個開發者之間能夠很容易的解決衝突。

  缺點：

  1. 學習週期相對而言比較長。
  2. 不符合常規思惟。
  3. 代碼保密性差，一旦開發者把整個庫克隆下來就能夠徹底公開全部代碼和版本信息。

• Trac

  優勢：

  1. 有良好的擴充性。
  2. Trac的權限體系是比較完備的設計。
  3. 很是靈活，能夠爲所欲爲的定製，能夠和TortoiseSVN集成。

  缺點：

  1. 不支持多項目。
  2. 需求和缺陷沒有分離。
  3. 核心功能不多，不安裝插件基本上無法用。

• SVN

  優勢：

  1. 管理方便，邏輯明確，操做簡單，上手快。
  2. 易於管理，集中式服務器更能保證安全性。
  3. 代碼一致性很是高。
  4. 有良好的目錄級權限控制系統。

  缺點：

  1. 對服務器性能要求高，數據庫容量常常暴增，體量大。
  2. 分支的管控方式不靈活。

• Mercurial

  優勢：

  1. 學習門檻較低。總體上看，須要掌握的命令要比git少不少。
  2. 能夠一鍵徹底恢復到歷史版本的某一個切面。
  3. 封裝好。相比git，不多暴露一些實現內的細節。

  缺點：

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

  參考資料

  [1]幾種經常使用的版本控制系統優缺點比較

  [2]http://www.javashuo.com/article/p-bgcdcykv-ch.html