l 所有的編程人員都是樂觀主義者，無論是什麽樣的程序，結果都是毋庸置疑的：“這次它肯定會運行”或者“我剛剛找出了最後一個錯誤”。

這一個觀點，在《夢斷代碼》中也有所提及，那其中講述的是，程序員對過往錯誤不在追悔莫及，對於新的項目仍抱有良好的希望。因此，推廣到我們的日常學習中，愚認為對於過往逝去的事務不要在嘆息，珍惜現在！

l 推薦的軟件任務的進度安排：

1/3 計劃

1/6 編碼

1/4 構建測試和早期系統測試

1/4 系統測試，所有的構件以完成

項目的時間依賴於順序上的限制，人員的數量依賴於單個子任務的數量。從這兩個數值可以推算進度時間表，該表安排的人員較少，花費的時間較長（唯一的風險是產品會過時），相反，分派較多的人手，計劃較短的時間，將無法得到可行的進度表。總之，在眾多軟件項目中，缺乏合理的時間進度是造成項目滯後的最主要原因，它比其他所有因素加起來的影響還要大。

根據個人經驗，最出學習實踐中，若沒有豐富的經驗，很難對項目做出合理的時間安排表，既不能按照功能板塊平均分配時間，也不能對於每個程序員預估相同的的工作效率。因此，要想做出合理的時間安排表，離不開豐富的項目經驗，更離不開一支默契的項目團隊成員工作效率的了解。

l 對於效率和概念的完整性來說，最好由少數幹練的人員來設計和開發；而對於大型系統，則需要大量的人手，以使產品能在時間上滿足需求。要想調和這兩方面的矛盾，Mills給出了一個建議：大型項目的每一部分由一個團隊解決，但是該隊伍以類似外科手術的方式組建，而不是一擁而上。也就是說，由一個人來進行問題的分解，其他人給予他所需要的支持，以提高效率和生產力。

l 在設計人員書寫開發文檔時，設計實現人員不必坐等文檔完成。只要有一些最終將並入外部說明的系統功能雛形時，設計實現人員就可以開始工作了。首先，必須要設定良好定義的時間和空間目標，了解產品運行的平臺配置。接著，可以開始設計模塊的邊界、表結構、算法以及所有的工具 。另外，還需要花費一些時間和體系結構師溝通。

《人月神話》閱讀筆記01