翻開扉頁，購書日期：2003.2.10。實在汗顏，且此類書，我的案頭還有許多。
在兩周中抽出時間，翻看完了這本傳說中的經典。
總的感覺，收穫並不多，雖說有些東西並未能完全理解，但大多在作者看來是未來的東西，已早成為現實。大致看來，沒有什麼新的概念。
於是，也談不上讀後感，只是把看的過程中的筆記重新寫一遍，當作另乙個自已的索引吧。
(注：突然下決心，凡是看完一本書，都應有一篇讀書筆記，否則，有可能就白看了)。
若干前言，序言，將本書稱為神品。
來，看書吧。
一：焦油坑
程式設計是什麼？許多人痛苦掙扎的焦油坑。它是樂趣與苦惱共存的創造性活動。
有些體會嗎？沒有，那你，轉行吧。
二：人月神話
哇，這麼快就切入主題了。
2.2：1/3計畫，1/6編碼，1/4構件及早期測試 1/4系統測試。嗯，一半時間用來測試。我所在公司現在的狀況確實如此。只不過領導們把
測試多是安排在了加班時間中。
2.3：向進度落後的專案中增加人手，只會使進度更落後。這有些絕對了，如果新增的人手得力，還是可以提公升進度地。
讀《人月神話》
為什麼中國的程式設計師總是在不斷學習新的開發工具 鑽研程式 而不能逐步提公升自己的視野 思維和經驗？摘自序 所謂人月 man month 是軟體開發中工作量的度量，然而它卻不是線性的，10個人10個月可以完成的工作，很多情況下100個人並不能在1個月完成。以下是我的理解與摘抄 斜體是摘抄 當人數增多...
讀《人月神話》
人月神話的英文是 man month mythical 人月其實是軟體工程管理工程量的單位，乙個人每月的工作量，其實是想說明是使用人月的方式來估算大型專案是不靠譜的，只是乙個神話的方式。而作者frederick p.brooks,brooks被認為是 ibm 360系統之父 他擔任了360系統的專案...
2015 4 25 讀人月神話筆記
趁著這段時間還能抽出些時間，我對前一段時間在專案裡的經歷做了很大程度的思考，不得不說前端時間在專案組裡的猶如噩夢一般，詭異的後端架構 不穩定的 實現 緊張的專案進度以及不斷的需求變更都將開發推導了噩夢的邊緣。對比這些專案經歷，我重讀了人與神話這部描寫360os系統的建造者的經驗輯錄。比較令我震驚的一...