作者介紹：
frederick p. brooks，jr.是北卡羅來納大學 kenan-flagler 商學院的電腦科學教
授，北卡來羅來納大學位於美國北卡來羅來納州的查布林希爾。brooks 被認為是「ibm 360
系統之父」，他擔任了 360 系統的專案經理，以及 360 作業系統專案設計階段的經理。憑藉在上述專案的傑出貢獻，他、bob evans 和 erich bloch 在 1985 年榮獲了美國國家技術獎（national medal of techology）。早期，brooks 曾擔任 ibm stretch 和 harvest 計算機的體系結構師。
在查布林希爾，brooks 博士創立了電腦科學系，並在 1964 至 1984 年期間擔任主席。
他曾任職於美國國家科技局和國防科學技術委員會。brooks 目前的教學和研究方向是計算
機體系結構、分子模型繪圖和虛擬環境。
程式本身是完整的，可以由作者在所開發的系統平台上執行。它通常是車庫中產出的產品，以及作為單個程式設計師生產率的評估標準。
但要成為通用的程式設計產品，程式必須按照普遍認可的風格來編寫，特別是輸入的範圍和形式必須擴充套件，以適用於所有可以合理使用的基本演算法。接著，對程式進行徹底測試，確保它的穩定性和可靠性，使其值得信賴。這就意味著必須準備、執行和記錄詳盡的測試用例庫，用來檢查輸入的邊界和範圍。此外，要將程式提公升為程式產品，還需要有完備的文件，每個人都可以加以使用、修復和擴充套件。
程式變成程式設計系統（programming system）中的乙個構件單元。它是在功能上能相互協作的程式集合，具有規範的格式，可以進行互動，並可以用來組裝和搭建整個系統。要成為系統構件，程式必須按照一定的要求編制，使輸入和輸出在語法和語義上與精確定義的介面一致。同時程式還要符合預先定義的資源限制——記憶體空、輸入輸出裝置、計算機時間。最後，程式必須同其它系統構件單元一道，以任何能想象到的組合進行測試。由於測試用例會隨著組合不斷增加，所以測試的範圍非常廣。因為一些意想不到的互動會產生許多不易察覺的 bug，測試工作將會非常耗時，因此相同功能的系統構件的成本至少是獨立程式的三倍。如果系統有大量的組成單元，成本還會更高。
程式設計的樂趣：
首先是一種建立事物的純粹快樂。如同小孩在玩泥巴時感到愉快一樣，成年人喜歡創
建事物，特別是自己進行設計。我想這種快樂是上帝創造世界的折射，一種呈現在每片獨特、
嶄新的樹葉和雪花上的喜悅。
其次，快樂來自於開發對其他人有用的東西。內心深處，我們期望其他人使用我們的
勞動成果，並能對他們有所幫助。從這個方面，這同小孩用粘土為「爸爸辦公室」捏製鉛筆
盒沒有本質的區別。
第三是整個過程體現出魔術般的力量——將相互嚙合的零部件組裝在一起，看到它們
精妙地執行，得到預先所希望的結果。比起彈珠遊戲或點唱機所具有的迷人魅力，程式化的
計算機毫不遜色。
第四是學習的樂趣，來自於這項工作的非重複特性。人們所面臨的問題，在某個或其
它方面總有些不同。因而解決問題的人可以從中學習新的事物：有時是實踐上的，有時是理
論上的，或者兼而有之。
最後，樂趣還來自於工作在如此易於駕馭的介質上。程式設計師，就像詩人一樣，幾乎僅
僅工作在單純的思考中。程式設計師憑空地運用自己的想象，來建造自己的「城堡」。很少有這
樣的介質——創造的方式如此得靈活，如此得易於精煉和重建，如此得容易實現概念上的設
想。（不過我們將會看到，容易駕馭特性也有它自己的問題）。
程式設計的苦惱：
首先，必須追求完美。因為計算機也是以這樣的方式來變戲法：如果咒語中的乙個字元、乙個停頓，沒有與正確的形式一致，魔術就不會出現。（現實中，很少的人類活動要求
完美，所以人類對它本來就不習慣。）實際上，我認為學習程式設計的最困難部分，是將做事的方式往追求完美的方向調整。
其次，是由他人來設定目標，供給資源，提供資訊。程式設計人員很少能控制工作環境和工作目標。用管理的術語來說，個人的權威和他所承擔的責任是不相配的。不過，似乎在所有的領域中，對要完成的工作，很少能提供與責任相一致的正式權威。而現實情況中，實際（相對於正式）的權威來自於每次任務的完成。
對於系統程式設計人員而言，對其他人的依賴是一件非常痛苦的事情。他依靠其他人的程式，而往往這些程式設計得並不合理，實現拙劣，發布不完整（沒有源**或測試用例），或者文件記錄得很糟。所以，系統程式設計人員不得不花費時間去研究和修改，而它們在理想情況下本應該是可靠完整的。
下乙個煩惱——概念性設計是有趣的，但尋找瑣碎的 bug 卻只是一項重複性的活動。伴隨著創造性活動的，往往是枯燥沉悶的時間和艱苦的勞動。程式編制工作也不例外。另外，人們發現除錯和查錯往往是線性收斂的，或者更糟糕的是，具有二次方的複雜度。結果，測試一拖再拖，尋找最後乙個錯誤比第乙個錯誤將花費更多的時間。
最後乙個苦惱，有時也是一種無奈——當投入了大量辛苦的勞動，產品在即將完成或者終於完成的時候，卻已顯得陳舊過時。可能是同事和競爭對手已在追逐新的、更好的構思；也許替代方案不僅僅是在構思，而且已經在安排了。
個人感受：我過去並沒有特別規範的敲**，也沒有可以去了解過，現在我要去規範一下我的**格式了。
人月神話閱讀筆記01
本週讀了 人月神話 中的 焦油坑 和 人月神話 兩個章節，現來看看我的認識與理解。我們做專案應該滿足目標 時間進度 和預算的要求，這樣才能夠最大程度上避免陷入焦油坑中。新聞中有多兩個人在車庫中完成了大量的重要程式，其實我們應全面的看待這樣的神話。編寫陳偉乙個變成產品和程式設計系統需要編寫乙個程式的三...
人月神話閱讀筆記01
本篇閱讀筆記是我對於 人月神話 一書中中關於團隊擴建的感悟。開發團隊在很多方面滿足了迫切性的需要。十個人，其中七個專業人士在解決問題，而系統是一乙個人或者最多兩個人思考的產物，因此客觀上達到了概念的一致性。要特別注意傳統的兩人隊伍與外科醫生副手隊伍架構之間的區別。首先，傳統的團隊將工作進行劃分，每人...
人月神話閱讀筆記01
在眾多軟體專案中，缺乏合理的時間進度是造成專案滯後的最主要原因，它比其他所有因素加起來的影響還大。原因 我們對估算技術缺乏有效的研究，更加嚴肅地說，它反映了一種悄無聲息，但並不真實的假設 一切都將運作良好。第二，我們採用的估算技術隱含地假設人和月可以互換，錯誤地將進度與工作量相互混淆 第三，由於對自...