本週我讀的書是frederick p.brooks所著的《人月神話》這一十分著名的書籍。這是一本非常典型的外國科技作品：富含了幽默感和形象生動的比喻：「焦油坑」、「人月神話」、「外科手術隊伍」，看到這些詞，你會很快在腦海中建立起乙個很清晰的畫面，同時也會產生很多疑問：這個東西，這幅畫面的特點是什麼？為什麼要提起它？作者又想讓我關注什麼？而當我們仔細閱讀其中的內容，很快就會發現，懷揣著這些問題的我們，可以迅速的感知到作者想要表達的重點是什麼，同時還建立起了對這個概念的乙個聯想畫面，這不僅有助於我們去理解，去體悟，更能令我們的閱讀妙趣橫生，我想，這樣一本書，他的名聲在外，絕不是靠弄虛作假作出來的。
被作者繪聲繪色的描述方式所吸引，我一下子就讀了好幾章，能被稱為「一本在軟體領域絕無僅有，20餘年暢銷不衰的必讀經典」，不得不說人月神話的吸引力是巨大的。
第一章一開始，作者十分風趣的將軟體開發的過程比喻為焦油坑，讓陷入其中的猛獸越是掙扎，越是難以掙脫束縛，最終陷入坑底，而在軟體開發的過程中，軟體開發團隊就像是猛獸，在由各種問題交織在一起的開發過程面前，就好像是在焦油坑里打滾的猛獸，如果只用蠻力，那是不可能成功的。軟體開發的困難，更是讓無數的企業和團隊淹沒在了焦油坑中。緊接著，作者帶我們領略了軟體開發這個職業的樂趣和苦惱。作者將軟體開發模擬為了藝術家創作一項作品，力量蘊含在創造的過程中，很多時候是痛苦的，但卻是富含深意和力量的。在產品被創造出來以後，那樣的快樂是比之前的痛苦更具震撼力的。
在第二章，作者仔細的講述了人月的關係，也讓我恍然大悟何謂人月神話。人月，是指在估計和進度安排中使用的工作量單位。看似包含了軟體開發過程中的最重要的因素，可是實際上「成本的確隨開發產品的人數和時間的不同，有著很大的變化，進度卻不是如此。因此我認為用人月作為衡量一項工作的規模是乙個危險和帶有欺騙性的神話。」換句話來說，就是完成工作的人數與時間使不能進行簡單互換的。要理解這一點也很簡單，畢竟不是每個人都是老鳥，畢竟不是每個人都是工作狂（誤）。更進一步地來說，在人數過多的情況下，很可能會出現中國的傳統諺語中所描述的那種「三個和尚沒水喝」的情況（互相甩鍋，推卸責任）。結合我參與過的robgame的程式設計經歷想一想，的確如此，在有好幾人分塊進行程式設計時，最大的麻煩就是組合成乙個完整的專案聯合除錯的時候。編寫程式可能只用一天的時間，而**的整合與測試往往需要好幾天。各個部分分別測試都沒有問題，但是聯合起來，總會由於介面、變數名等因素的衝突產生bug。只有團隊之間的通力合作，才是加快進度的可能方法，書中說「軟體系統也是人類創造的錯綜複雜的事物。所以只有在乙個團隊的溝通了解，通力協作和努力之下，才能做出更加完善的軟體作品！」
《人月神話》讀書筆記二
進度 時間表 成本必須降低，以產出更低的 文件是有必要的，只有記錄下來，分期才會明朗，矛盾才會突出。不過我們公司從來不用文件，我也從來沒有寫過。只是聽上面分配任務，可是一般沒什麼任務分配，只好做自己的事情了。文件能夠作為同其他人溝通渠道。這個，我們老大就寫一些文件，供我們參考，我們按照他的文件，完成...
《人月神話》讀書筆記二
進度 時間表 成本必須降低，以產出更低的 文件是有必要的，只有記錄下來，分期才會明朗，矛盾才會突出。不過我們公司從來不用文件，我也從來沒有寫過。只是聽上面分配任務，可是一般沒什麼任務分配，只好做自己的事情了。文件能夠作為同其他人溝通渠道。這個，我們老大就寫一些文件，供我們參考，我們按照他的文件，完成...
《人月神話》讀書筆記
p8,程式設計的快樂在於它不僅滿足了我們內心深處進行創造的渴望，而且還喚醒了每個人內心的情感。p19,用人月作為衡量一項工作的規模是乙個危險和帶有欺騙性的神話。因為它暗示人員數量和時間是可以相互替換的。人數和時間的互換僅僅適用於以下情況 某個任務可以分解參與人員，並且他們之間不需要相互交流。p23,...