1.樂觀主義：程式設計人員潛在認為程式會一切執行良好，但我們的構思總會存在缺陷，因此總會存在bug，在大型的程式設計任務中一切正常的概率非常小甚至接近於無。
2.人月：作者認為用人月作為衡量一項工作的規模是乙個危險和帶有欺騙性的神話。 它暗示著人員數量和時間是可以相互替換的。人數和時間的互換僅僅適用於以下情況：某個任務可以分解給參與 人員，並且他們之間不需要相互的交流。這在割小麥或收穫棉花的工作中是可行的；而在系統程式設計中近乎不可能。系統程式設計在增加人力的時候需要額外增加的交流成本，這種交流和溝通的工作量巨 大，在相同人月下，增加更多的人手實際上會增加時間進度而不是減少。
3.系統測試：傳統專案往往不重視測試，不安排足夠的時間但實際中測試占用了大量時間，因此作者提出1/3 計畫 1/6 編碼1/4 構件測試和早期系統測試 1/4 系統測試
4.空泛的估算：產品經理要對自己的估算自信，避免為了顧客的期望的日期而造成不合理的進度安排
5.重複產生的進度災難：作者認為向進度落後的專案中增加人手，只會使進度更加落後
關於系統測試想起來乙個段子：
乙個測試工程師走進一家酒吧，要了一杯啤酒
乙個測試工程師走進一家酒吧，要了一杯咖啡
乙個測試工程師走進一家酒吧，要了0.7杯啤酒
乙個測試工程師走進一家酒吧，要了-1杯啤酒
乙個測試工程師走進一家酒吧，要了2^32杯啤酒
乙個測試工程師走進一家酒吧，要了一杯洗腳水
乙個測試工程師走進一家酒吧，要了一杯蜥蜴
乙個測試工程師走進一家酒吧，要了乙份asdfqwer@24dg!&*(@
乙個測試工程師走進一家酒吧，什麼也沒要
五百個測試工程師在酒吧門口呼嘯而過
乙個測試工程師走進一家酒吧，又走出去又從窗戶進來又從後門出去從下水道鑽進來
乙個測試工程師走進一家酒吧，又走出去又進來又出去又進來又出去，最後在外面把老闆打了一頓
終於測試工程師滿意的離開了酒吧
乙個顧客走進一家酒吧，點了乙份蛋炒飯，酒吧炸了
讀書筆記 人月神話 2
第5章 畫蛇添足 1，結構師的互動準則和機制 估算過高的解決方式 削減設計或採用成本更低的實現方法。一般開發人員會反對體系結構上的修改建議，通常他是對的。當實現產品時，某些次要特徵的修改會造成意料不到的成本開銷。2，自律 開發第二個系統所帶來的後果 在開發第乙個系統時，結構師傾向於精煉和簡潔，會將不...
《人月神話》讀書筆記
p8,程式設計的快樂在於它不僅滿足了我們內心深處進行創造的渴望，而且還喚醒了每個人內心的情感。p19,用人月作為衡量一項工作的規模是乙個危險和帶有欺騙性的神話。因為它暗示人員數量和時間是可以相互替換的。人數和時間的互換僅僅適用於以下情況 某個任務可以分解參與人員，並且他們之間不需要相互交流。p23,...
人月神話讀書筆記
人數和時間的互換僅僅適用於以下情況 某個任務可以分解給參與人員，並且他們之間不需要相互的交流。當任務由於次序上的限制不能分解時，人手的新增對進度沒有幫助。溝通所增加的負擔由兩個部分組成，培訓和相互的交流。相互之間交流的情況更糟一些。如果任務的每個部分必須分別和其他部分單獨協作，則工作量按照n n 1...