為什麼中國的程式設計師總是在不斷學習新的開發工具、鑽研程式**，而不能逐步提公升自己的視野、思維和經驗？
——摘自序
所謂人月（man-month），是軟體開發中工作量的度量，然而它卻不是線性的，10個人10個月可以完成的工作，很多情況下100個人並不能在1個月完成。
以下是我的理解與摘抄（斜體是摘抄）：
當人數增多時，平均每個人的效率會降低。甚至，到達一定程度後，隨著人數增多總體的效率反而是下降的。因為新增加的人需要進行培訓，人員交流存在成本等。
向進度落後的軟體專案中新增人手只會使進度更加落後。
首席程式設計師模型是效率較高的軟體開發模型。
**曾被要求每週創作一篇形式嚴格的歌劇，但這似乎並沒有壓制他的創造性。
功能和理解上覆雜程度的比值才是系統設計的最終測試標準。
當功能相同時，越易用越好。
概念的完整性
設計必須由乙個人，或者非常少數互有默契的人員來實現。
設計的一致性。
系統要自洽，要有一致性。
系統要相對簡潔，捨棄多餘的功能。
工作量 = 常數 x 指令數量^1.5關於完全避免go to語句的說法顯得有些教條主義，而且似乎有些吹毛求疵。
一次新增乙個構件。回歸測試，步步為營。
記憶衰退的規律會使使用者-作者失去對程式的了解，所以文件和筆記很重要。
我從來沒有看到過乙個有經驗的程式設計人員，在開始編寫程式之前，會例行公事地繪製詳細的流程圖。
但設計實現這一步還是相當相當重要。
關於自文件化，我想sgi的stl原始碼做的足夠好了。
卓越的設計人員 很重要。
如果主要部分不變，即使次要部分的任務佔據了工作的9/10，即使不占用任何時間，也不會給生產率帶來數量級的提高。
soli deo gloria.
讀《人月神話》
翻開扉頁，購書日期 2003.2.10。實在汗顏，且此類書，我的案頭還有許多。在兩周中抽出時間，翻看完了這本傳說中的經典。總的感覺，收穫並不多，雖說有些東西並未能完全理解，但大多在作者看來是未來的東西，已早成為現實。大致看來，沒有什麼新的概念。於是，也談不上讀後感，只是把看的過程中的筆記重新寫一遍，...
讀《人月神話》
人月神話的英文是 man month mythical 人月其實是軟體工程管理工程量的單位，乙個人每月的工作量，其實是想說明是使用人月的方式來估算大型專案是不靠譜的，只是乙個神話的方式。而作者frederick p.brooks,brooks被認為是 ibm 360系統之父 他擔任了360系統的專案...
2015 4 25 讀人月神話筆記
趁著這段時間還能抽出些時間，我對前一段時間在專案裡的經歷做了很大程度的思考，不得不說前端時間在專案組裡的猶如噩夢一般，詭異的後端架構 不穩定的 實現 緊張的專案進度以及不斷的需求變更都將開發推導了噩夢的邊緣。對比這些專案經歷，我重讀了人與神話這部描寫360os系統的建造者的經驗輯錄。比較令我震驚的一...