《神話故事》讀書筆記(精選多篇)

第一篇：希臘神話故事讀書筆記

希臘神話故事讀書筆記

袁櫟晴

書是人們生活中不可缺少的一部分。就像小魚離不開水的滋養，小狗離不開骨頭一樣。當我們寂寞時，它將為我們趕走寂寞；當我們有困惑時，它將指引我們正確的方向。書還會給我們一把智慧大門的鑰匙。

而今天，我將來給大家推薦一本好書《希臘神話故事》，這本書是一位德國名叫：古斯塔夫·施瓦布的著作這本書主要講了：希臘神話主要由諸神傳說和英雄故事兩大部分組成。在神的傳說中，諸神都具有超越自然的力量，但他們也於普通人類一樣，有著平凡的喜悅、悲傷、嫉妒等各種各樣的感情（也就是喜怒哀樂）。英雄故事則起源於古希臘人們對祖先的崇拜，敬仰。書中的英雄們無不智慧過人、力大無窮，體現了人類征服自然的自信和頑強。

這本智慧的“領跑者”將帶給我們無限的樂趣。大家覺得怎麼樣，快來走進這本書裡吧。

第二篇：人月神話讀書筆記

人月神話這本書幾年前就聽別人說是本很經典的軟體開發方面的書，這本書的成功之處在於他思想的前衛性，以至於不只是軟體行業的人在讀。現在終於找到讀他的理由了，可以感受一下大師的傑作。在讀之前我已經讀過了軟體工藝和極限程式設計，為什麼留到最後讀人月神話呢？主要是因為我覺得一本能夠流傳30年還被人們津津樂道的書，肯定是本學要好好細讀的書，所以留到了最後。按照前兩篇讀書筆記的慣例，前面幾段是一些我讀書時的感受和收穫，還有一些對內容的評價。

從這本書的內容來看，對於一個專案經理來說肯定會有更大的收穫，這本書主要是針對軟體開發管理方面的內容，這主要原因可能是因為作者以前就是專案的管理者，他是站在管理者的角度寫的。即便這樣，對於一個從來沒有參與過真實專案開發，更沒有領導過團隊的我還是有一定的吸引力，這本書中我最喜歡的就是前四章（焦油坑、人月神話、外科手術隊伍、貴族專制、民主政治和系統設計）和沒有銀彈這章。這本書裡面為了論證某一觀點，會舉出許多實際的專案作為證據，這一點非常好，事實勝於雄辯嘛！這些例子也許對於作者那個年代的人來說很好理解，但是放在30年後來看這些例子又有些陳舊和難懂了。另外，從文中我發現作者非常注重文件，一個優質的文件就是專案成功的保證，這一點與傳統的軟體工程很相似，但是卻與極限程式設計的觀點相悖。下面就是一些讀書的總結了。

焦油坑 1. 程式設計系統產品開發的工作量是供個人使用的、獨立開發的構件程式的九倍。

2. 程式設計行業的一些內在固有苦惱：

l 將做事方式調整到追求完美，是學習程式設計的最困難部分。

l 由其他人來設定目標，並且必須依靠自己無法控制的事物。

l 真正的權威來自於每次任務的完成。

l 任何創造性活動都伴隨著枯燥艱苦的勞動，程式設計也不例外

l 人們通常期望專案在接近結束時（bug、工作時間）能收斂得快一些，然而軟體專案的情況卻是越接近完成，收斂得越慢。

l 產品在即將完成時總面臨著陳舊過時的威脅。 人月神話 1. 缺乏合理的時間進度是造成專案滯後的最主要原因，它比其他所有因素加起來影響還大。

2. 良好的烹飪需要時間，某些任務無法在不損害結果的情況下加快速度。

3. 我們的構思是有缺陷的，因此總會有bug。

4. 我們圍繞成本核算的估計技術，混淆了工作量和專案進展。人月是危險和帶有欺騙性的神話，因為它暗示人員數量和時間是可以相互替換的。

5. 在若干人員中分解任務會引發額外的溝通工作量--培訓和相互溝通。

6. 關於進度安排，作者的經驗是為1/3計劃、1/6編碼、1/4構件測試以及1/4系統測試。

7. 因為我們對自己的估計技術不確定，所以在管理和客戶的壓力下，我們常常缺乏堅持的勇氣。

8. brook法則：向進度落後的專案中增加人手，只會使進度更加落後。

9. 向軟體專案中增派人手從三個方面增加了專案必要的總體工作量：任務重新分配本身和所造成的工作中斷；培訓新人員；額外的相互溝通。 外科手術隊伍 1. 同樣有兩年經驗而且在受到同樣的培訓的情況下，優秀的專業程式設計師的工作效率是較差程式設計師的十倍。關於這一條我在極限程式設計裡看到，sackman和humphrey分別做了實驗發現優秀程式設計師工作效率比較差程式設計師的工作效率最高要高達28倍。

2. 小型、精幹隊伍是最好的。這一點在軟體工藝和極限程式設計裡都得到了充分的體現。

3. 兩個人的團隊，其中一個專案經理，常常是最佳的人員使用方法。

4. 對於真正意義上的大型系統，小型精幹的隊伍太慢了。

5. 實際上，絕大多數大型程式設計系統的經驗顯示出，一擁而上的開發方法是高成本、速度緩慢、不充分的，開發出的產品無法進行概念上的整合。

6. 一位首席程式設計師、類似於外科手術隊伍的團隊架構提供了一種方法，既能獲得由少數頭腦產生的產品完整性，又能得到多位協助人員的總體生產率，還徹底地減少了溝通的工作量。圖1是10人的程式開發隊伍溝通模式。 圖1 10人程式開發隊伍溝通模式