本週我閱讀了《人月神話》
程式設計，乙個許多人痛苦掙扎的焦油坑以及一種樂趣和苦惱共存的創造性活動。焦油坑確實是乙個新穎而又貼切的比喻，大型系統開發就猶如這樣乙個焦油坑，樂趣與痛苦交織，各種團隊在其中掙扎，而這本書試圖提供橋梁，為通過這樣的焦油坑提供一些指導。
人月神話，初讀書名實在是有些疑惑。實際上，人月是估計和進度安排中的乙個單位，他暗示著人員數量和時間是可以相互轉化的。然而這僅僅是個神話。書中分幾點說明了這一點：
1. 樂觀主義導致的錯誤進度安排
乙個普遍假設是：一切都將運作良好，每一項任務僅花 費它所「應該」花費的時間。我們可能不會意識到，但往往這正是大多數時候我們安排計畫存在的假設。然而現實不會如此，意外的概率總是存在，墨菲定律也告訴我們這一點。
2. 試圖以增加人數趕上進度並不現實
軟體開發本質上是一項系統工作，錯綜複雜關係下的一種實踐，溝通、交流 的工作量非常大。時間不是工作量除以人數，一味地新增人數甚至可能導致延長工作安排。
3. 充足的系統測試非常重要
不為系統測試安排足夠的時間簡直就是一場災難，其導致的二次成本遠高於其他花銷。
4. 空泛的估算
非階段化方法的採用，少得可憐的資料支援，加上完全借助軟體經理的 直覺，這樣的方式很難生產出健壯可靠和規避風險的估計。
5. 削減任務往往是唯一可行的方法
團隊是軟體開發的核心，不同組織形式的團隊在效率上可能有天壤之別。外科手術隊伍，通過專業化的角色分工，避免了一擁而上的情況，使簡單的交流成為可能。而對於非常大型的專案，需要很多人協作，概念的完整性至關重要。這就需要少數架構師，專注考慮結構的完整性，所謂貴族政治。這不意味著實現人員不能具有創造性，但是不能與系統基本概念進行整合的良好想法和特色，最好放到一邊， 不予考慮。
巴比倫塔，乙個工程壯舉，同時也是第乙個徹底失敗的工程。我們可以從這個故事中得到很多借鑑的地方。故事中的人們具有人力，材料，技術等條件，至少沒有在失敗前造成限制，他們缺少的是交流，以及交流的結果——組織。當交流無法進行，或者進入歧途，左手不知道右手在幹什麼，必然會導致工程的失敗。團隊中的交流途徑主要包括：非正式途徑（日常）；會議；工作手冊。我們往往認為較小的專案不需要手冊或者規範，但往往會導致一系列的問題。口頭的規範和守則，往往缺乏約束力，實施起來也有頗多困難，乙個精簡有效的工作手冊是有必要的。
軟體工程方面有很多不同的技術，管理方法，但並沒有像銀彈那樣對狼人有效的一勞永逸的方法。這其中的根本困難是規格化、設計和測試概念上的結構。現代軟體系統中無法規避的內在特性：複雜度、一致性、可變性和不可見性，同樣告訴我們這一點。
《軟體工程》 讀書筆記一
對於第一章主要介紹了軟體工程的發展歷史和基本原理，討論ieee和acm提出的軟體工程體系和 軟體工程職業道德規範。沒上這門課時，我想當然認為 軟體 程式 可是當我開啟課本時，卻發現他們之間是不等號，軟 件除了程式之外，還包括了與之相關的文件和配置資料，以保證這些程式的正確執行。軟體工程三要素 過程 ...
軟體工程導論讀書筆記
第一章 軟體工程概論 1.1軟體危機 表現 輕視需求分析，認為軟體工程就是寫程式，輕視軟體維護。1.2軟體工程 軟體工程方法學三要素 過程，工具，方法。1.3軟體生命週期 軟體定義 問題定義 可行性研究 需求分析 軟體開發 總體設計 詳細設計 編碼單元測試與綜合測試 軟體維護 1.4軟體過程 1 瀑...
《軟體工程》 讀書筆記三
有錯是軟體的特性，而且無法改變，我們應該去避免錯誤的產生和消除已經產生的錯誤，為了使程式中的錯誤 密度達到盡可能低的程度。軟體測試就是必須的了。軟體開發從獲取需求 分析設計到編碼實現，是乙個自頂向下，逐步精化的過程，而軟體測試過程卻是自底向 上，從區域性到整體，逐步整合的過程，在開發的不同階段會出現...