這篇記錄了閱讀人月神話所得到的感想或者筆記，閱讀的是中文版本，但一樣輔助英文版的電子書。這是一本被譽為經典的好書，雖然程式方面我還沒熟悉與精通，但看此書也得到非常多的建議與觀念，而且現在閱讀與以後閱讀我想也是可以有更多新的感觸。
Chapter 1-焦油坑 (The Tar Pit, P19)
Chapter 2-人月神話 (The Mythical Man-Month, P31)
軟體專案時程：(P41)
1/3- 規劃(Planning)
1/6- 寫程式(Coding)
1/4- 組件測試(Component test & early system test)
1/4- 系統測試，完成所有組件(System test, all components in hand)
惡性循環的時程災難(P43~P47)
1. 這幾頁可以提供計算人月關係與思考拖延的後果
2. 軟體專案會耗費多少時間是看他有多少連續性的限制。
Chapter 3-外科手術團隊 (The Surgical Team, P49)
盡可能用最少的人來完成專案！！-P53
Chapter 4-專制與民主 (Aristocracy, Democracy, and System Design, P79)
整體概念性(Conceptual Integrity)-P67
功能概念複雜度比(ratio of function to conceptual complexity)，好的設計既不可單獨偏重功能性，也不可只偏重簡單性。
創意工作: 架構設計-實作-實現; 事實上是可以同時開始合並行的。
以整體概念性為主軸，時程壓力終會迫使系統開發由更多人一起合作，使用兩個方式解決達成整體概念性：
1. 將工作分成“架構(architecture)”與“實作(implementation)”-P70
---architecture, 做什麼? ; implementation, 如何做?
2. 外科手術團隊(第三章)
約束對藝術而言是件好事(Discipline is good for art)-P73
形式就是解放(From is liberating)
成本校能比(Cost-performance ratio)
Chapter 5-第二系統效應 (The Second-System Effect, P79)
架構設計師 vs. 第二系統效應(chapter 5)-p87
架構設計師要如何避免第二系統效應呢？很明顯地，他無法跳過他的第二系統，但可以留意造成第二系統效應的獨特原因，再加上自律，以特別提醒自己避免設計出不相干的功能，或是做出違反原先假設與目的的功能。
Chapter 6-意念的傳達 (Passing the Word , P93)
量化(quantize)
”精確的說明“應該比”生動地表達“來得重要
英語，或任何其他人類語言，原本就不是用來精確描述定義的。
--使用"正式標記法(formal notation)"，另外好的規格書應該同時包含“正式定義”和“散文式定義”，以口語化的解釋使規格書易於領會和傳授。
Chronometer：羅盤
贊同開會：P98
第一種：每週會議，成功的原因，共五點
第二種：年度檢討大會（作者prefer半年一次）
Chapter 7-巴別塔為什麼失敗？ (Why Did the Tower of Babel Fail?, P107)
(p107即)提到五個重要的成功條件，但是皆以失敗結束。因為缺乏了兩樣因素：溝通(communication)以及隨之而來的組織(organization)。
--溝通：非正式方法(informally)，會議(meeting)以及工作手冊(workbook, P109)
--組織, P112：目的在於減少溝通介面和協調的需要量->人力配置(division of labor)以及專業分工(specialization of function)。
Chapter 8-預估(Calling the Shot, P123)
1. 練習就是最好的教練-西流士, Practice is the best of all instructors.- PUBLILIUS
2. 經驗的代價是昂貴的，但愚人就只能從經驗中學習, Experience is a dear teacher, but fools will learn at no other.- POOR RICHARD'S ALMANAC
ref:上面的第二點出自“窮查理年鑑”（中譯），也就是Benjamin Franklin(1706-1790)在1733-1758年在費城發表的年鑑。
另個比較有趣的是提到“即使只考慮個人創作，不含任何跟別人溝通的代價，寫程式的費力程度仍然跟程式的大小呈現指數倍數的關係”-雖然是淺顯易懂一句話，不過有時候還是會成為判斷錯誤的原因之一。
兩個新的名詞：
控制程式(control program)
包含：操作，維護
語言轉譯程式(language translator)
包含：編譯器，轉譯器（資料組譯器）
(p129), 在章節末段提出的兩點結論之一：若以“行”來算生產力，似乎是個固定的值，因為每一行程式得花多少腦筋思考，可能藴藏多少錯誤，都是固定的...。
好奇點在，對程式語言開發系統來說，“每一行”的長度很接近或一樣嗎？因為前述有提到每一行大概可抵三到五個字。恩！恩？
Chapter 9-地盡其利，物盡其用(Ten Pounds in a Five-Pound Sack, P135)
The author should gaze at Noah, and ... learn, as they did in Ark, to crowd a great deal of matter into a very small compass- SYDNEY SMITH, EDINBURGH REVIEW
空間就是金錢->A:程式大小的控制->B:節省空間的技術
A:
技術上 & 管理上
(p137)，存取規劃(access budget)
提到的兩種問題：
1. 重疊(overlay)
2. 分頁錯亂(page thrashing)
提到的三個教訓：
1. 做好“整體空間規劃(total size budget)”，
2. (p138)在規定某個模組的大小之前，先精確定義出這個模組該做的事情，
3. 系統架構師對系統的整體性保持警覺。
B:
“創意” & “技術”取代“規劃”與“管制”
第一種技術：功能和空間做取捨
1. 功能越單一，程式所佔的空間也會越少
第二種技術：空間和時間做取捨
1. 對同一個函式而言，能用的空間越多，執行的速度就越快，這道理幾乎在任何情況下都能成立，可以作為安排空間規劃的參考。
(p140)管理者可以做的兩件事情：
1. 確保程式設計師的本事是技術訓練而來，
2. 認知到寫程式有其專業的技術。
（兩套手冊必備：副程式或者巨集- queuing, searching, hashing, sorting，分成＝執行速度最快以及使用空間最少的）
(p141)又小、又快、又好的程式幾乎都源自於“策略”上的突破。
”譯註“資料(Data)或表格(Table)地呈現方式指的是“資料結構”，而“流程圖”所隱含的意義就是“演算法(algorithm)”。
(p142)有一段話寫得很好：
為了空間不足的問題而顯得黔驢技窮之際，通常最好的做法就是從程式碼中跳脫，回過頭重新思考所使用的資料。
“資料的呈現方式是程式設計的本質”
“Representation is the essence of programming”
Chapter 10-文件假說(The Documentary Hypothesis, P147)
假說：
在成堆的書面資料中，有一小部份關鍵性文件記錄着任何專案管理的核心工作。而這些文件是身為管理者最重要的工具。
The hypothesis:
Amid a wash of paper, a small number of documents become the critical pivots around which every projects management revolves. These are the manager's chief personal tools.
(p147)準備這一小部分文件是為了讓思考集中，並且使討論言之有物，而非淪為漫無目的的空談。
(p150)任何管理工作所關心的五件事情：
人、地、時、物、錢
(p150)規劃軟體開發專案的文件(很受用，值得參考！)
做什麼(What)：目標
做什麼(What)：產品規格
何時做(When)：時程
多少錢(How much)：預算
哪裡做(Where)：場地配置
由誰做(Who)：組織編制圖
(p151)最後一點有一句定律如-Conway定律：從事系統設計的組織所設計出來的系統將會是組織溝通結構的翻版。意思就是組織編制圖會初步反映出系統的第一次設計成果，而此設計幾乎可以確定並不是我們要的。
(p151)提到為什麼需要正式文件
第一：只有“寫”下來，才能引導更多細節的決定(mini-decision)，而這正是從模糊不清之中理出清晰而明確政策的具體方法。
第二：有“傳達決策給他人的功用”
-管理者的工作就是“制定計劃“，然後”實現它”，但唯有將計劃“寫”下來，整個開發工作才能做精確地推動與溝通。(p152)
Chapter 11-失敗為成功之母(Plan to Throw One Away, P157)
這世界唯一不變的就是這世界一直在變-斯威夫特
There is nothing in this world constant but inconstancy.-Jonathan SWIFT(1707)
你得以平常心看待失敗，試試這個，如果行不通，就老老實實接受行不通的事實，再試試那個。總之，要成功，就得去試試。-富蘭克林·羅斯福
It is common sense to take a method and try it. If it fails, admit it frankly and try another. But above all, try something.-FRANKLIN D. ROOSEVELT
"丟掉重做"
1.毋須煩惱是否做一個試探性的系統，因為到時候勢必就會這麼做。
2.計畫做得再完美也會有百密一疏，因此必須有丟掉重做的準備。
3.所以無論如何，把必然的一次失敗納入正式計畫之中-plan to throw one way; you will, anyhow.
4.硬體是有形的且可以量化(quantize)並加以節制，但軟體是無形的，且易於操控(tractable)，使得開發人員面臨需求上無窮無境的改變。
5.定義出一個底線是必須的，而且隨著專案進行，這項限制應該要越來越嚴格，否則沒有任何產品會完成。
6.丟掉重作的改念本身就是要讓你接受先學到竅門、然後改變設計的事實。
使系統利於改變
7.(p159) 說的多做的少-設計一個系統且利於改變: 模組化、副程式、為內部模組之間定義出明確且完整的介面，並寫出完整的文件。盡可能使用標準的呼叫程序(calling sequence)和表格驅動技術(table-driven)。
使組織利於改變
8.類似"外科手術團隊"
軟體維護(program maintenance)在於軟體交付之後的變動
-主要來自"修正設計錯誤"、"增加新功能"。維護起碼付出相當於開發成本的40%，甚至更高。
-軟體使用者越多，維護成本越高。(p162-163)
可能遭遇到一個重要的問題，就是因修正錯誤而導致其他錯誤的可能性相當高(about 20~50 %)
-做到完整的迴歸測試(regression test)所需的成本相當高。
Pascal: 任何事物總是在開始的時候最完美。(p164-165, 進一步，退一步)
Chapter 12-神兵利器(Sharp Tools, P171)
巧匠以他所使用的工具而聞名。-諺語
A good workman is know by his tools.-Proverb
有哪些工具是管理者需要思索、規劃和組織的呢？
『目標機器』
機器（電腦設備）->作業系統（服務法則）->語言（語言政策）
『工具機器與資料維護』
另外還有：工具程式、除錯輔助軟體、測試案例產生器以及文書處理系統
p175, 可靠(dependable)跟精確(accurate)不同，模擬器需要可靠性，雖然新型機器架構相對來得精確。
p175, 對於模擬器(simulator)的描述必看（到p176)
p182, 交談式工具必須搭配高階語言。這兩者的結合確實造就了一組神兵利器。
Chapter 13-化整為零(The Whole and the Parts, P187)
我可以招喚地底的幽魂。
啊!這我也會，甚麼人都會；可是當您招喚它們的時候，它們就真的會來嗎? - 莎士比亞，《亨利四世》，上篇
I can call spirits from the vasty deep.
Why so can I, or so can any man; but will they come when you do call for them? - SHAKEPEARE, KING HENRY IV, PART I
測試方案有三大面向:
設計-組件-系統
(避免發生錯誤的設計方案-組件除錯-系統除錯)
p188, A good top-down design avoids bugs in several way.這裡面的第三點:The suppression of detail makes flaws in the structure more apparent.不是很瞭解!?為什麼隱藏的細節卻可以使結構中的缺陷更容易被突顯出來呢?
名詞解釋：dump (for computer)
(n) The act of copying raw data from one place to another with little or no formatting for readability. Usually, dump refers to copying data from main memory to a display screen or a printer. Dumps are useful for diagnosing bugs. After a program fails, you can study the dump and analyze the contents of memory at the time of the failure. Dumps are usually output in a difficult-to-read form (that is, binary, octal, or hexadecimal), so a dump will not help you unless you know exactly what to look for.
p193, 系統除錯:系統除錯所耗費的時間將超乎預期，而其困難也證明了有必要準備一套條理分明、規畫良好的測試方案。而在系統除錯中有5點:
A:
大致上提到的為:嘗試整合(bolt-it-together-and-try)還有讓各個組件互相測試。另外不建議"先將錯誤記錄起來"的做法。
B:
建立充分的測試鷹架(scaffolding)，屬於鷹架的部分占了產品全部程式碼的一半其實並不為過。
C-E
控制改變、一次只整合一個組件以及固定改版的時機
Chapter 14-釀成大災難(Hatching a catastrophe, P203)
沒有人會給報壞消息的人好臉色看。- 沙孚克里斯
None love the bearer of bad news.
為什麼專案會落後一年?
......因為每次落後一天。
How does a project get to be a year late?
...One day at a time.
p203, 時程總在不知不覺之間延誤，而且非常無情；事實上，顯而易見的事故很容易克服。
Milestone vs. Millstone (p203, 里程碑或者包袱?)
里程碑必須是具體、明確、可量測的事件，有沒有達成應該是一翻兩瞪眼的事情，絕不模稜兩可。
p206, 善用要逕網路圖 (critical-path network)[通稱"計畫評核圖"]
p206, 兩種必須知道的資訊:未如計畫預期的意外狀況，計畫的執行現況。
p207, 兩種知道真相的方法:降低角色的衝突以鼓勵據實回報，審查制度。
p207, 降低角色衝突:執行狀況報告 & 討論解決方案 應該明確分開。
p211, 建立"計畫監控小組"是可以擔任守門員的角色，也就是早期預警系統。
Chapter 15-一體兩面(The Other Face, p217)
我們無法主宰我們不了解的東西。- 歌德
What we do not understand we do not possess. GOETHE
哦!請賜予我簡單平實的評論者，他們不諱莫如深到讓人困惑不解。 - 克拉布
O give me commentators plain, Who with no deep researches vex the brain. CRABBE
**p217, 程式，其實就是人對電腦說話，其內容必須經過審慎、嚴謹的語法編排與定義，這都是為了能將意圖明確地傳達給那台笨電腦。
p218, 為使用程式而寫的文章，最常犯的毛病就是“缺乏”“概觀性的描述（Overview）”，通常可以歸納九點：
目的、環境、輸入＆輸出值域、欲達成的功能與使用的演算法、輸出入格式、執行過程中的指示、選項、執行時間、輸出結果的精確度＆檢驗方式。
另外還有“為建立對程式的信心所寫的文件”，“為修改程式而寫的文件”（p218-220）
p220,惱人的流程圖，是最被過度強調的文件，許多程式一點都不需要流程圖，也很少有程式需要一頁以上的流程圖。
繪製詳細的流程圖其實是個既落伍有麻煩的事情，僅適合用來幫助初學者起個頭，協助他進入演算法的思考。
p223, 自我說明程式（Self-documenting），資料處理的基本原則告訴我們，嘗試同步維護不同的文件是件愚蠢的事，“對於同一件事物的相關，應該盡可能統一放在同一份文件中比較好。
p230, 電腦終究是服務人類的，而非由人去配合電腦。
Chapter 16-沒有銀彈：軟體工程的本質與附屬工作 (No Silver Bullet-Essence and Accident in Software Engineering, p235)
在未來的十年之內，無論是在技術上或管理上，都不會有任何單一的重大突破能夠保證在生產力、可靠度或簡潔性上獲得改善，甚至，連一個數量級的改善都不會有。
There is no single development, in either technology or management technique, which by itself promises even one order-of-magnitude improvement within a decade in productivity, in reliability, in simplicity.
p235, 所有的軟體創作都包括了“本質性(essential task)”和“
附屬性(accidental task)”。
前者是抽象的軟體實體所組成的複雜概念性結構;
後者則是用程式語言來表現這些抽象的實體，將程式對應至機器語言。
p238, 本質上軟體實體是由許多彼此環環相扣的概念所組成：
資料集合、資料項目之間的關係、演算法、各種功能的執行。
p238, 現代軟體都有的天生特質：複雜性(complexity)、配合性(conformity)、易變性(changeability)、隱匿性(invisibility)
p243, 過去的突破都是解決附屬性的難題如：高階語言、分時技術、統一的軟體開發環境。
p245, 尋找銀彈，Ada的理念比Ada語言本身更先進的地方：
模組化(modularity)
抽象資料型別(abstract data type)
階層式結構(hierarchical structure)
其它尋找銀彈的方向還有：物件導向程式設計(object-oriented programming, OOD)，人工智慧(artificial intelligence, AI)，專家系統，<自動化>程式設計(automatic programming)，圖形化程式設計(graphical programming)，軟體的驗證，環境與工具，工作站。
p247, 人工智慧，軟體開發難就難在決定要表達什麼，而不在於表達本身，表達的方式再怎麼簡化，所得到的效益也是有限的。
Chapter 17-再論『沒有銀彈』（"No Silver Bullet" Refired, p269）
無論中彈與否，都是命中注定
Every bullet has its billet.- William III of England, Prince of Orange
無論誰想要看到十全十美的東西，那麼就去想像一下那種過去不曾有過、現在也沒有，而未來也不會存在的事物。
Whoever thinks a faultless piece to see, Thinks what ne'er was, nor is, nor e'er shall be. - Alexander Pope, <An Essay of Criticism>
Chapter 18-<人月神話>的主張：是真是假？
Chapter 19-<人月神話>二十年
補充：
看到了一篇文章提到"吳信輝"先生提出的軟體開發工程師的十大特質：
0 喜歡寫程式
1 完成事情的能力
2 持續地重構你的程式碼
3 使用設計模式
4 撰寫程式碼的測試程式
5 利用現成的程式碼
6 專注在可用性上
7 必須寫出可以維護的程式碼
8 可以在不同的程式語言撰寫程式
9 必須瞭解基本的電腦科學基礎
大部分都可以在此人月神話此書中相呼應，以學術界深入研究程式語言的角度（也許也曾在業界，沒有進一步查詢）也是將好的軟體開發工程師所需具備的重要特質都提到了。
後記:
Book List:
The Mind of the Maker- Dorothy Sayers
---Idea, Implementation and Interaction
Reference:
Backus-Naur Form(P95, formal notation)
Chapter 2-人月神話 (The Mythical Man-Month, P31)
軟體專案時程：(P41)
1/3- 規劃(Planning)
1/6- 寫程式(Coding)
1/4- 組件測試(Component test & early system test)
1/4- 系統測試，完成所有組件(System test, all components in hand)
惡性循環的時程災難(P43~P47)
1. 這幾頁可以提供計算人月關係與思考拖延的後果
2. 軟體專案會耗費多少時間是看他有多少連續性的限制。
Chapter 3-外科手術團隊 (The Surgical Team, P49)
盡可能用最少的人來完成專案！！-P53
Chapter 4-專制與民主 (Aristocracy, Democracy, and System Design, P79)
整體概念性(Conceptual Integrity)-P67
功能概念複雜度比(ratio of function to conceptual complexity)，好的設計既不可單獨偏重功能性，也不可只偏重簡單性。
創意工作: 架構設計-實作-實現; 事實上是可以同時開始合並行的。
以整體概念性為主軸，時程壓力終會迫使系統開發由更多人一起合作，使用兩個方式解決達成整體概念性：
1. 將工作分成“架構(architecture)”與“實作(implementation)”-P70
---architecture, 做什麼? ; implementation, 如何做?
2. 外科手術團隊(第三章)
約束對藝術而言是件好事(Discipline is good for art)-P73
形式就是解放(From is liberating)
成本校能比(Cost-performance ratio)
Chapter 5-第二系統效應 (The Second-System Effect, P79)
架構設計師 vs. 第二系統效應(chapter 5)-p87
架構設計師要如何避免第二系統效應呢？很明顯地，他無法跳過他的第二系統，但可以留意造成第二系統效應的獨特原因，再加上自律，以特別提醒自己避免設計出不相干的功能，或是做出違反原先假設與目的的功能。
Chapter 6-意念的傳達 (Passing the Word , P93)
量化(quantize)
”精確的說明“應該比”生動地表達“來得重要
英語，或任何其他人類語言，原本就不是用來精確描述定義的。
--使用"正式標記法(formal notation)"，另外好的規格書應該同時包含“正式定義”和“散文式定義”，以口語化的解釋使規格書易於領會和傳授。
Chronometer：羅盤
贊同開會：P98
第一種：每週會議，成功的原因，共五點
第二種：年度檢討大會（作者prefer半年一次）
Chapter 7-巴別塔為什麼失敗？ (Why Did the Tower of Babel Fail?, P107)
(p107即)提到五個重要的成功條件，但是皆以失敗結束。因為缺乏了兩樣因素：溝通(communication)以及隨之而來的組織(organization)。
--溝通：非正式方法(informally)，會議(meeting)以及工作手冊(workbook, P109)
--組織, P112：目的在於減少溝通介面和協調的需要量->人力配置(division of labor)以及專業分工(specialization of function)。
Chapter 8-預估(Calling the Shot, P123)
1. 練習就是最好的教練-西流士, Practice is the best of all instructors.- PUBLILIUS
2. 經驗的代價是昂貴的，但愚人就只能從經驗中學習, Experience is a dear teacher, but fools will learn at no other.- POOR RICHARD'S ALMANAC
ref:上面的第二點出自“窮查理年鑑”（中譯），也就是Benjamin Franklin(1706-1790)在1733-1758年在費城發表的年鑑。
另個比較有趣的是提到“即使只考慮個人創作，不含任何跟別人溝通的代價，寫程式的費力程度仍然跟程式的大小呈現指數倍數的關係”-雖然是淺顯易懂一句話，不過有時候還是會成為判斷錯誤的原因之一。
兩個新的名詞：
控制程式(control program)
包含：操作，維護
語言轉譯程式(language translator)
包含：編譯器，轉譯器（資料組譯器）
(p129), 在章節末段提出的兩點結論之一：若以“行”來算生產力，似乎是個固定的值，因為每一行程式得花多少腦筋思考，可能藴藏多少錯誤，都是固定的...。
好奇點在，對程式語言開發系統來說，“每一行”的長度很接近或一樣嗎？因為前述有提到每一行大概可抵三到五個字。恩！恩？
Chapter 9-地盡其利，物盡其用(Ten Pounds in a Five-Pound Sack, P135)
The author should gaze at Noah, and ... learn, as they did in Ark, to crowd a great deal of matter into a very small compass- SYDNEY SMITH, EDINBURGH REVIEW
空間就是金錢->A:程式大小的控制->B:節省空間的技術
A:
技術上 & 管理上
(p137)，存取規劃(access budget)
提到的兩種問題：
1. 重疊(overlay)
2. 分頁錯亂(page thrashing)
提到的三個教訓：
1. 做好“整體空間規劃(total size budget)”，
2. (p138)在規定某個模組的大小之前，先精確定義出這個模組該做的事情，
3. 系統架構師對系統的整體性保持警覺。
B:
“創意” & “技術”取代“規劃”與“管制”
第一種技術：功能和空間做取捨
1. 功能越單一，程式所佔的空間也會越少
第二種技術：空間和時間做取捨
1. 對同一個函式而言，能用的空間越多，執行的速度就越快，這道理幾乎在任何情況下都能成立，可以作為安排空間規劃的參考。
(p140)管理者可以做的兩件事情：
1. 確保程式設計師的本事是技術訓練而來，
2. 認知到寫程式有其專業的技術。
（兩套手冊必備：副程式或者巨集- queuing, searching, hashing, sorting，分成＝執行速度最快以及使用空間最少的）
(p141)又小、又快、又好的程式幾乎都源自於“策略”上的突破。
”譯註“資料(Data)或表格(Table)地呈現方式指的是“資料結構”，而“流程圖”所隱含的意義就是“演算法(algorithm)”。
(p142)有一段話寫得很好：
為了空間不足的問題而顯得黔驢技窮之際，通常最好的做法就是從程式碼中跳脫，回過頭重新思考所使用的資料。
“資料的呈現方式是程式設計的本質”
“Representation is the essence of programming”
Chapter 10-文件假說(The Documentary Hypothesis, P147)
假說：
在成堆的書面資料中，有一小部份關鍵性文件記錄着任何專案管理的核心工作。而這些文件是身為管理者最重要的工具。
The hypothesis:
Amid a wash of paper, a small number of documents become the critical pivots around which every projects management revolves. These are the manager's chief personal tools.
(p147)準備這一小部分文件是為了讓思考集中，並且使討論言之有物，而非淪為漫無目的的空談。
(p150)任何管理工作所關心的五件事情：
人、地、時、物、錢
(p150)規劃軟體開發專案的文件(很受用，值得參考！)
做什麼(What)：目標
做什麼(What)：產品規格
何時做(When)：時程
多少錢(How much)：預算
哪裡做(Where)：場地配置
由誰做(Who)：組織編制圖
(p151)最後一點有一句定律如-Conway定律：從事系統設計的組織所設計出來的系統將會是組織溝通結構的翻版。意思就是組織編制圖會初步反映出系統的第一次設計成果，而此設計幾乎可以確定並不是我們要的。
(p151)提到為什麼需要正式文件
第一：只有“寫”下來，才能引導更多細節的決定(mini-decision)，而這正是從模糊不清之中理出清晰而明確政策的具體方法。
第二：有“傳達決策給他人的功用”
-管理者的工作就是“制定計劃“，然後”實現它”，但唯有將計劃“寫”下來，整個開發工作才能做精確地推動與溝通。(p152)
Chapter 11-失敗為成功之母(Plan to Throw One Away, P157)
這世界唯一不變的就是這世界一直在變-斯威夫特
There is nothing in this world constant but inconstancy.-Jonathan SWIFT(1707)
你得以平常心看待失敗，試試這個，如果行不通，就老老實實接受行不通的事實，再試試那個。總之，要成功，就得去試試。-富蘭克林·羅斯福
It is common sense to take a method and try it. If it fails, admit it frankly and try another. But above all, try something.-FRANKLIN D. ROOSEVELT
"丟掉重做"
1.毋須煩惱是否做一個試探性的系統，因為到時候勢必就會這麼做。
2.計畫做得再完美也會有百密一疏，因此必須有丟掉重做的準備。
3.所以無論如何，把必然的一次失敗納入正式計畫之中-plan to throw one way; you will, anyhow.
4.硬體是有形的且可以量化(quantize)並加以節制，但軟體是無形的，且易於操控(tractable)，使得開發人員面臨需求上無窮無境的改變。
5.定義出一個底線是必須的，而且隨著專案進行，這項限制應該要越來越嚴格，否則沒有任何產品會完成。
6.丟掉重作的改念本身就是要讓你接受先學到竅門、然後改變設計的事實。
使系統利於改變
7.(p159) 說的多做的少-設計一個系統且利於改變: 模組化、副程式、為內部模組之間定義出明確且完整的介面，並寫出完整的文件。盡可能使用標準的呼叫程序(calling sequence)和表格驅動技術(table-driven)。
使組織利於改變
8.類似"外科手術團隊"
軟體維護(program maintenance)在於軟體交付之後的變動
-主要來自"修正設計錯誤"、"增加新功能"。維護起碼付出相當於開發成本的40%，甚至更高。
-軟體使用者越多，維護成本越高。(p162-163)
可能遭遇到一個重要的問題，就是因修正錯誤而導致其他錯誤的可能性相當高(about 20~50 %)
-做到完整的迴歸測試(regression test)所需的成本相當高。
Pascal: 任何事物總是在開始的時候最完美。(p164-165, 進一步，退一步)
Chapter 12-神兵利器(Sharp Tools, P171)
巧匠以他所使用的工具而聞名。-諺語
A good workman is know by his tools.-Proverb
有哪些工具是管理者需要思索、規劃和組織的呢？
『目標機器』
機器（電腦設備）->作業系統（服務法則）->語言（語言政策）
『工具機器與資料維護』
另外還有：工具程式、除錯輔助軟體、測試案例產生器以及文書處理系統
p175, 可靠(dependable)跟精確(accurate)不同，模擬器需要可靠性，雖然新型機器架構相對來得精確。
p175, 對於模擬器(simulator)的描述必看（到p176)
p182, 交談式工具必須搭配高階語言。這兩者的結合確實造就了一組神兵利器。
Chapter 13-化整為零(The Whole and the Parts, P187)
我可以招喚地底的幽魂。
啊!這我也會，甚麼人都會；可是當您招喚它們的時候，它們就真的會來嗎? - 莎士比亞，《亨利四世》，上篇
I can call spirits from the vasty deep.
Why so can I, or so can any man; but will they come when you do call for them? - SHAKEPEARE, KING HENRY IV, PART I
測試方案有三大面向:
設計-組件-系統
(避免發生錯誤的設計方案-組件除錯-系統除錯)
p188, A good top-down design avoids bugs in several way.這裡面的第三點:The suppression of detail makes flaws in the structure more apparent.不是很瞭解!?為什麼隱藏的細節卻可以使結構中的缺陷更容易被突顯出來呢?
名詞解釋：dump (for computer)
(n) The act of copying raw data from one place to another with little or no formatting for readability. Usually, dump refers to copying data from main memory to a display screen or a printer. Dumps are useful for diagnosing bugs. After a program fails, you can study the dump and analyze the contents of memory at the time of the failure. Dumps are usually output in a difficult-to-read form (that is, binary, octal, or hexadecimal), so a dump will not help you unless you know exactly what to look for.
p193, 系統除錯:系統除錯所耗費的時間將超乎預期，而其困難也證明了有必要準備一套條理分明、規畫良好的測試方案。而在系統除錯中有5點:
A:
大致上提到的為:嘗試整合(bolt-it-together-and-try)還有讓各個組件互相測試。另外不建議"先將錯誤記錄起來"的做法。
B:
建立充分的測試鷹架(scaffolding)，屬於鷹架的部分占了產品全部程式碼的一半其實並不為過。
C-E
控制改變、一次只整合一個組件以及固定改版的時機
Chapter 14-釀成大災難(Hatching a catastrophe, P203)
沒有人會給報壞消息的人好臉色看。- 沙孚克里斯
None love the bearer of bad news.
為什麼專案會落後一年?
......因為每次落後一天。
How does a project get to be a year late?
...One day at a time.
p203, 時程總在不知不覺之間延誤，而且非常無情；事實上，顯而易見的事故很容易克服。
Milestone vs. Millstone (p203, 里程碑或者包袱?)
里程碑必須是具體、明確、可量測的事件，有沒有達成應該是一翻兩瞪眼的事情，絕不模稜兩可。
p206, 善用要逕網路圖 (critical-path network)[通稱"計畫評核圖"]
p206, 兩種必須知道的資訊:未如計畫預期的意外狀況，計畫的執行現況。
p207, 兩種知道真相的方法:降低角色的衝突以鼓勵據實回報，審查制度。
p207, 降低角色衝突:執行狀況報告 & 討論解決方案 應該明確分開。
p211, 建立"計畫監控小組"是可以擔任守門員的角色，也就是早期預警系統。
Chapter 15-一體兩面(The Other Face, p217)
我們無法主宰我們不了解的東西。- 歌德
What we do not understand we do not possess. GOETHE
哦!請賜予我簡單平實的評論者，他們不諱莫如深到讓人困惑不解。 - 克拉布
O give me commentators plain, Who with no deep researches vex the brain. CRABBE
**p217, 程式，其實就是人對電腦說話，其內容必須經過審慎、嚴謹的語法編排與定義，這都是為了能將意圖明確地傳達給那台笨電腦。
p218, 為使用程式而寫的文章，最常犯的毛病就是“缺乏”“概觀性的描述（Overview）”，通常可以歸納九點：
目的、環境、輸入＆輸出值域、欲達成的功能與使用的演算法、輸出入格式、執行過程中的指示、選項、執行時間、輸出結果的精確度＆檢驗方式。
另外還有“為建立對程式的信心所寫的文件”，“為修改程式而寫的文件”（p218-220）
p220,惱人的流程圖，是最被過度強調的文件，許多程式一點都不需要流程圖，也很少有程式需要一頁以上的流程圖。
繪製詳細的流程圖其實是個既落伍有麻煩的事情，僅適合用來幫助初學者起個頭，協助他進入演算法的思考。
p223, 自我說明程式（Self-documenting），資料處理的基本原則告訴我們，嘗試同步維護不同的文件是件愚蠢的事，“對於同一件事物的相關，應該盡可能統一放在同一份文件中比較好。
p230, 電腦終究是服務人類的，而非由人去配合電腦。
Chapter 16-沒有銀彈：軟體工程的本質與附屬工作 (No Silver Bullet-Essence and Accident in Software Engineering, p235)
在未來的十年之內，無論是在技術上或管理上，都不會有任何單一的重大突破能夠保證在生產力、可靠度或簡潔性上獲得改善，甚至，連一個數量級的改善都不會有。
There is no single development, in either technology or management technique, which by itself promises even one order-of-magnitude improvement within a decade in productivity, in reliability, in simplicity.
p235, 所有的軟體創作都包括了“本質性(essential task)”和“
附屬性(accidental task)”。
前者是抽象的軟體實體所組成的複雜概念性結構;
後者則是用程式語言來表現這些抽象的實體，將程式對應至機器語言。
p238, 本質上軟體實體是由許多彼此環環相扣的概念所組成：
資料集合、資料項目之間的關係、演算法、各種功能的執行。
p238, 現代軟體都有的天生特質：複雜性(complexity)、配合性(conformity)、易變性(changeability)、隱匿性(invisibility)
p243, 過去的突破都是解決附屬性的難題如：高階語言、分時技術、統一的軟體開發環境。
p245, 尋找銀彈，Ada的理念比Ada語言本身更先進的地方：
模組化(modularity)
抽象資料型別(abstract data type)
階層式結構(hierarchical structure)
其它尋找銀彈的方向還有：物件導向程式設計(object-oriented programming, OOD)，人工智慧(artificial intelligence, AI)，專家系統，<自動化>程式設計(automatic programming)，圖形化程式設計(graphical programming)，軟體的驗證，環境與工具，工作站。
p247, 人工智慧，軟體開發難就難在決定要表達什麼，而不在於表達本身，表達的方式再怎麼簡化，所得到的效益也是有限的。
Chapter 17-再論『沒有銀彈』（"No Silver Bullet" Refired, p269）
無論中彈與否，都是命中注定
Every bullet has its billet.- William III of England, Prince of Orange
無論誰想要看到十全十美的東西，那麼就去想像一下那種過去不曾有過、現在也沒有，而未來也不會存在的事物。
Whoever thinks a faultless piece to see, Thinks what ne'er was, nor is, nor e'er shall be. - Alexander Pope, <An Essay of Criticism>
Chapter 18-<人月神話>的主張：是真是假？
Chapter 19-<人月神話>二十年
補充：
看到了一篇文章提到"吳信輝"先生提出的軟體開發工程師的十大特質：
0 喜歡寫程式
1 完成事情的能力
2 持續地重構你的程式碼
3 使用設計模式
4 撰寫程式碼的測試程式
5 利用現成的程式碼
6 專注在可用性上
7 必須寫出可以維護的程式碼
8 可以在不同的程式語言撰寫程式
9 必須瞭解基本的電腦科學基礎
大部分都可以在此人月神話此書中相呼應，以學術界深入研究程式語言的角度（也許也曾在業界，沒有進一步查詢）也是將好的軟體開發工程師所需具備的重要特質都提到了。
後記:
Book List:
The Mind of the Maker- Dorothy Sayers
---Idea, Implementation and Interaction
Reference:
Backus-Naur Form(P95, formal notation)
