金句-人月神話

32 週年中文紀念版

7

神話和傳說中的魔術在我們的時代已變成了現實。在鍵盤上鍵入正確的咒語，屏幕會活動、變幻，顯示出前所未有的也不可存在的事物。

８

誠然，產品開發所基於的技術在不斷地進步。一旦設計被凍結，在概念上就已經開始陳舊了。不過，實際產品需要一步一步按階段實現。實現落後與否的判斷應根據其他已有的系統，而不是未實現的概念。因此，我們所面臨的挑戰和任務是在實際的進度和有效的資源範圍內，尋找解決實際問題的切實可行方案。

１３

美食的烹調需要時間；片刻等待，更多美味，更多享受。－－新奧爾良Antoine餐廳的菜單

１４

所有納種人員都是樂觀主義者。可能是這種現代魔術特別吸引那些相信美滿結局和幻想中的聖母的人；也可能是成百上千瑣碎的挫折趕走了大多數人，只剩下了那些習慣上只關注結果的人；還可能僅僅因為計算機還很年輕，程序員更加年輕，而年輕人總是試樂觀主義者，無論是什麼樣的程序，結果是勿庸置疑的：＂這次它肯定會運行。＂或者＂我剛剛找出了最後一個錯誤。＂

１５

所以系統編程的進度安排背後的第一個錯誤的假設是：一切都將運作良好，每一項任務住花費它所＂應該＂花費的時間。

在許多創造性活動中，往往很難掌握活動實施的介質，例如木頭切割、油漆、電氣接線等。這些介質的身型約束限制了思路的表達，它們同樣對實現造成了許多預料之外的困難。

由於物理介質和思路中隱含的不完善性，實際實現起來需要花費大量的時間和汗水。對遇到的大部分實現上的困難，我們總是傾向於去責怪那些物理介質，因為它們不順應＂我們＂設定的思路。其實，這只不過是我們的驕傲使判斷帶上了主觀主義色彩。

然而，計算機編程基於十分容易掌握的介質，編程人員通過非常純粹的思維活動－概念以及靈活的表現形式來開發程序。正是由於介質的易於駕馭，我們期待在實現過程中不會碰到困難，因此造成了樂觀主義的彌漫。而我們的構思是有缺陷的，因此總會發現ｂｕｇ。也就是說，我們的樂觀主義其不應該是理所能當的。

１６

第二個謬誤的思考方式是在個評估進度安排中使用的工作量單位：人月。成本的至隔開發上路的人數和時間等不同。有著很大的變化，進度卻不是如此。…因此用人月作為衡量一項工作的規模是一個危險和帶有欺騙性的神話。它暗示著人員數量和時間是可以相互替換的。

人數和時間的互換僅僅適合用於以下情況：某個任務可以分解給參與人員，並且他們之間不需要相互的交流。

２０

由於我們的樂觀主義，通常實際出現的缺陷數量比預料得要多得多。因此，系統測試主度的安排常常是編程中最不合理的部分。對於軟件任務的進度安排，以下是我使用了很多年的經驗法則：

１／３計劃

１／６編碼

１／４構件測試和早期系統測試

１／４系統測試，所有的構件已完成

２５

簡化Ｂｒｏｏｋｓ法則：向進度落後的項目中增加人手，只會使進度更加落後。

４１

蘭斯Ｒｅｉｍｓ大教堂指南

大教堂是藝術史上天與倫比的成就。它所宣揚的理念既不乏味也不混亂…它是一種風格上的極致，要完成這樣一件藝術品，建築大師要首尾融會貫通其前輩建築師的成果，同是也完全掌握他們那個時代的建築技術，並在運用這些技術時做到恰如其分，避免輕浮的炫耀，也絕不花哨。

…這就是這個宏偉的建築能夠如此和諧統一的原因之一。

４３

由於目標是易用性（ｓｉｍｐｌｉｃｉｔｙ），功能與理解上複雜程度的比值才是系統設計的最終測試標準。單是功能本身或者簡潔都無法成為一個好的設計評判標準。

然而這一點被廣泛地誤解了。操作系統ＯＳ／３６０由於其複雜強大的功能被它的開發者廣為推崇。功能，而非簡潔，總是被用來衡量設計人員工作的出色程度。…一旦以易用性作為衡量標準，單獨的功能和簡潔都是不均衡，都只達到了真正目標的一半。

４４

簡潔和直白（STRAIGHTFORWARD）來自概念的完整性。

５４

結構師是在向開發人員的做事方式提出挑戰。想要成功，結構師必須：

• 牢記是開發人員承擔創造性和發明性的實現責任，所以結構師只能建議，而不能支配。
• 時刻準備著為所指定的說明建議一種實玩的方法，同樣準備接受其他任何能達到目標方法
• 對上述的建議保持低調和不公開
• 準備放棄堅持所作的改進建議

一黎開發人員會反對體系結構上修改建議，通常他是對－當正在實現產品時，某些次要特性的修改會造成意料不到的成本開銷。

５５

在開發第一個系統時，工程師傾向於精煉和簡潔。他知道自己對正在進行的任務不夠了解，所以他會謹慎仔細地工作。

在設計第一個項目時，他會面對不斷上甜的裝飾和潤色功能。這些功能都被擱置在一邊，作為＂下一個＂項目的內容。和一個項目遲早會結束，而此時的工程師，對這類系統充滿了十足的信心，擁有對這一級別系統的精通，並且時刻準備開發第二個系統。

第二個系統是設計師們所設計最危險的系統。而當他著手第三個或第四個系統時，先前的經驗會相互驗証，得到對此類系統通用特性的判斷，而且系統之間的差異會幫助他識別出經驗中不夠通用的部分。

一種普遍傾向是過分地設計第二個系統，向系統添加很多修飾功能和想法，它們曾在第一個系統中被小心謹慎地放在次要位置。

５８

工程師如何避免開發第二個系統所引起的後果，所需避免畫蛇添足？…他可以有意識關注這個系統的特殊危險，運用特別的自我約束準則，來避免那些功能上的過於修飾：根據系統基本理念及目的變更，捨棄一些功能。

一個可以開闊工程師眼界的準則是為每個小功能分配一個值：每次改進，功能ｘ不超過ｍ字節的內存和ｎ微秒。這些值會在一開始作為決策和向導，在物理實現期間充當指南和對所有人的警示。

６３

英語或者其他任何一種人類語言，從根本上說，都不是一種能精確表達上述定義的方式。因此，手册的作者必須注意到自己的思路和語言，達到所需要的精確程度。一種頗具吸引力的作法是對上述定對使用形式化標記方式。畢竟，常班度是我們需要的東西，這也正是形式化標記方法存在的理由和原因。

６４

＂決不携有兩個時鐘出海，帶一個或者三個＂

６５

結果手册中有一上表述模糊的地方，＂問一問機器！＂－設計一般程序來確定其行為，新機器必須按照上述結果運行。

７３

現在整個大地都採用一種語言，只包括為數不多的單詞。在一次從東邊往西方遷徙的過程中，人們發現了蘇美爾地區的一處平原，並在那裡定居下來。接著他們奔走相告說＂來，讓我們製造磚塊，並把它們燒好。＂於是，他們用磚塊代替石頭，用瀝青代替灰泥。然後，他們又說：＂來，讓我們建造一座帶有高塔的城市，這個塔將高達雲霄，也將讓我們聲名遠揚；同時，有了這個城市，的停就可以聚居在這裡，再也不會分散在廣闊的大地上了＂於是上帝決定下來看看人們建造的城市和高塔。看了以後，他說：＂他們只是一個種族，使用一種的語言，如果他們一開始就能建造城市和高塔，那以後就沒有什麼難倒他們了。來，讓我們下去，在他們的語言裡製造一上混淆，讓他們相互之間不能聽懂＂這樣，上請把人們分散到世界各地，於是停們不得不停上建造那座城市。　－　創世紀　１１：１－８

８７

實踐是最好的老師－PUBLIIUS

實踐是最好的老師，但智者還能從其他的地方有所收獲。－可憐的理查年鑑

１０３

由於缺乏空間而絞盡腦汁的編程人員，常常能通過從自己的代碼中掙脫出來，回顧、分析實際情況，仔細思考程序的數據，最終獲得非常好的結果。實際上，數據的表現形式是編種的根本。

１１１

Conway 規律：＂設計系統的組織架構受到產品的約束限制，生產出的產品是這些組織機構溝通結構的映射＂

１１５

不變只是願望，變化才是永恆－斯威夫特

普遍的做法是，選擇一種方法，試試看；如果失敗了，沒關係，再試試別的。不管怎麼樣，重要的是先去嘗試。

１１６

對於大多數項目，第一個開發的系統並不合用。定可能太慢，太大，而且難以使用，或者三者並而有之。要解決所有的問題，除了重新開始以外，，沒有其他的辦法，－即開發一個更靈巧或者更好的系統，系統的丟棄和重新設計可以一步完成，也可以一塊塊地實現。所有大型系統的經驗都顯示，這是必須完成的步驟。而且，新的系統，因為即使是最優秀的項目經理，也不能無所不個地在最開始解決這些問題。

因此，和管理上問題不再是＂是否構建一個試驗性的系統，然後拋棄它＂你必須這樣做。現在問題是：＂是否預先計劃拋棄原型的開發，或者是否將該原型發佈給用戶？＂從這個角度看待問題，答案更加清晰。將原型發佈給用戶，可以獲得時間，但是它的代價高昂，影響了聲譽，即使最好的再設計也難以挽回名聲。

１２３

"事物在最初總是最好的"

１２７

巧匠因為他的工具而出名　－　諺語

１４２

關鍵的工作是產品定義。許許多多的失敗完全是因為那些產品未精確定義的地方而導致的

１５５

帶來壞消息的人不受歡迎　－　索福克里斯

項目怎麼會被延遲了整整一年的時間？…延遲時時間是一天天積累下來的。

１６７

不了解，就無法真正擁用　－　歌德

噢，賜予的扑素的評論者吧，他們不會有深奧的鑽研讓人困惑不解。

１８５

懷疑論者並不是悲觀主義者

１８８

軟件工程師卻無法從類似的信念中獲得安慰，他必須掌握得很多複雜度是隨心所慾、毫無規則可言的，來自若干必須遵循的人為慣例和系統

２１１

任何人若想看到一年完美無暇的作品，他所想的那種作品過去不存在，現在和將來也不會出現

２２９

思索的層次愈高，所需要處理的基本思考要素也就愈多。

２３３

我們理解也好，不理解也好，描述都應該簡短精練。　－　塞繆爾。巴特勒

２５９

只能根據過去判斷將來　－　帕特里克。亨利

然而永遠無法根據過去規劃未來　－　埃德蒙。伯克

小册子

16

尼采-我的野心是用一句話說完別人十本書才能說清的事

27

對編程系統產品的觀點:＂…然而，只有它才是真正有用的產品，是大多數系統開發的目標。＂這種觀點很有意義，至少在面對現在許多老闆對管理的觀點：＂現實世界中的管理就是在更大程度上以人員的生命為代價，讓他們更努力、更長時間地工作。姐型們總是不停地吹噓他們的人員的加班時數和能從這些人身上榨取更多時間的小把戲。＂在這種情況下，開發產品的質量一定會下降，甚至慘不忍睹，因為開發人員唯一能控制的是質量，當他們不得不犧牲，痛苦面對自己的工作，踐踏工作的樂趣時，可以想像項目成本會大量地增加，並且項目的發佈往往伴隨著一大批程序員的倒下。

５９

文言－人月神話

吾有程序員五人，需時日幾何？

一年

吾急需之！若有十人，幾何？

兩年。

百人若何？

萬世。