第一次閱讀做業

一. 提問

1.第四章 代碼設計規範

「函數最好有單一的出口，爲了達到這一目的，可使用goto。只要有助於程序邏輯的清晰體現，什麼方法均可以使用，包括goto。。。」
老生常談並且也難以定論的東西：goto的簡便和難以被徹底替代的做用確實受到一部分人喜好，可也存在容易致使代碼可讀性降低難以維護，破壞結構化設計風格，或者因使用不當形成錯誤和隱患。

2.第四章 結對編程

「他們並排坐在一臺電腦前，面對同一個顯示器，使用同一個鍵盤，同一個鼠標一塊兒工做。他們一塊兒分析，一塊兒設計，一塊兒寫測試樣例，一塊兒編碼，一塊兒作單元測試，一塊兒作集成測試，一塊兒寫文檔。。。」
也許是編程經驗不夠豐富，我的閱歷不足，總以爲徹底地「二人合體」編程並非一個頗有效率的辦法。兩人合做感受沒必要那麼長時間的接近。交流當然重要，但要兩我的擠在同一張桌子前面，四隻手兩個頭去分享兩三平米空間上的同一副鍵鼠，難道不會礙手礙腳嗎？也許這其中有我的的性格緣由，不過也許也只是上面這段文字只是做者的一個說笑似的打比方。

3.第十六章 創新和做坊

「有管理專家建議，在工做須要的人數基礎再減掉一位，這纔是最優的數字」
當n-1人是成爲最優的團隊人數時，就要又有一位犧牲者出現，n-2的團隊穩定下來以後又要減掉一位。。。這種不把勞動力當人使的資本主義思想我以爲是萬萬要不得的。。。（沒有買賣就沒有殺害）

4.第一章 軟件=程序+軟件工程

「若是一架民用飛機上有需求，用戶使用它的機率是百萬分之一，你還要作這個功能麼？」
第一堂課上就提了這個問題。不過老師先說的是軟件功能百萬分之一律率使用，後來又提出飛機。。。老實說飛機和軟件仍是不能徹底互相比較的。飛機缺失某項重要功能致使的幾乎全是悲劇，但軟件缺失某功能也許並不會有巨大的影響。再從影響的大小來看，飛機一旦失事基本不會留活口，軟件出了問題或者某個功能沒實現大概就是被使用者罵，罵完再罵到寫代碼的頭上。。。這種徹底不一樣量級的問題放在一塊兒比較是狡猾的。

5.第九章 項目經理

「PM作開發和測試以外的全部事情」
「五彩斑斕的黑」之類已經玩爛了。一個徹底不去開發的PM難以瞭解一些項目的難點，而後就異想天開的提出看似美妙實際天女散花的要求。就想某位大佬博客中寫的一個有趣的故事：PM要程序員作一個能根據手機套改變手機主題顏色的小程序。在PM看來，大家都能讓搶票軟件24小時搶票，讓手機主題變個色固然也不是難事，但是在實現者面前第一個問題就是你怎麼知道手機套的顏色？靠愛確定是不行的，難道讓攝像頭本身探出來看看手機套再把顏色傳回來（？），固然有個相似的例子是堅果一代手機的手機背殼上都帶有一塊小芯片，不一樣背殼安裝後（其實就是不一樣芯片）就能讓手機識別到，詢問用戶是否要更改對應的主題顏色（不用換背殼也能換主題，可是老羅就喜歡這些花裏胡哨的（？））。

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

• 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.（在早期的阿波羅任務中，瑪格麗特·漢密爾頓開始使用「軟件工程」這個術語，以使軟件具備硬件工程等其餘領域的合法性。）

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

「故障與社會恐慌」

• 日本的D10電話系統的故障曾引發轟動。1980年10月，日本神戶元町電話局D10系統發生故障，使得確保市民安全匪警及火警緊急電話線路中斷長達9個小時，整個城市的公民們處在極度的恐怖狀態之中。第二年的3月，東京霞關電話局的D10系統也發生了故障。從國會打不出電話足有50分鐘，國家政治中樞陷入徹底麻痹的窘境。在1981年3月，關西地區經濟中心，大阪北濱電話局的D10系統也出現了故障。大約在50分鐘內，約有8000個電話打不通。這個線路範圍內是大銀行和證券公司集中的地區，一時間引發了騷亂。

四. 目前流行的源程序版本管理軟件和項目管理軟件及其優缺點

流行軟件：

1. github：約31,000,000用戶量
2. SourceForge：約3,700,000用戶量
3. Bitbucket：約5,000,000用戶量
4. GitLab：約100,000用戶量

優缺點：

GitHub

• 優勢：GitHub提供Git存儲庫服務，基於web，容許你使用Git的源代碼管理功能及其特性。
• 缺點：可能不是捕捉創意過程和記錄創意點子的最佳工具。對於這種特殊功能模擬能夠選擇LayerVault 或其餘類似工具。很是適用代碼跟蹤，但也響應的保密性較差。

Mercurial

• 優勢：有reset，擴展性，append only的存儲結構 ，上手簡單。
• 缺點：分支管理不靈活。Mercurial的branch管理和Git相比不是很方便。沒有命名空間。大型團隊不肯使用。

Trac

• 優勢：良好的擴充性，很是靈活，能夠爲所欲爲的定製，能夠和TortoiseSVN集成。
• 缺點：不支持多項目。需求和缺陷沒有分離。核心功能少，不安裝插件基本上無法用。

Bugzilla

• 優勢：免費且有中文。檢索功能強大，有強大的後端數據庫支持。
• 缺點：安裝須要Perl和配置MySQL數據庫，比較繁瑣。修改配置文件也很麻煩。流程沒法定製。