《人月神話：軟體專案管理之道(20週年紀念版)》筆記

一. 人月神話

1.安排軟體專案的時程：

1/3 規畫

1/6寫程式

1/4組件測試和早期系統測試

1/4系統測試，完成所有的組件
﹡不可以單獨先估計寫程式所佔的時間，然後配上這些比例數據，就這樣得到全部時程的預估值。寫一個獨立的小程式所花的時間，不能拿來做為預估整個軟體系統產品的開發時程之用


2.在新時程中安排能夠保證工作可以很仔細、很徹底地完成的足夠時間，使後頭的工作不會再發生需要重新安排時程的事情

3.在一個時程已經落後的軟體專案中增加人手，只會讓它更加落後




二. 外科手術團隊

1.外科手術團隊：

（1）外科醫師: 首席程式設計師。他負責定義功能上和效能上的規格、設計程式、編寫程式、測試程式，並撰寫文件。他擁有實質上的存取權來使用一套電腦系統，在這套電腦系統上，不僅可以進行測試，也保存了程式的不同版本，允許簡易的檔案更新，也為文件的撰寫工作提供了文書編輯的功能。他必須要有過人的天分、十年的工作經驗，以及豐富的系統與應用知識

（2）副手: 相當於外科醫師的分身，能夠做任何外科醫師做的事，只是經驗較為缺乏。其主要職責，就是在設計時擔任出主意、參與討論、評估的角色，外科醫師可以把一些構想交給他去嘗試，但不盡然要接受他的意見。副手常常代表外科醫師去開會，和別的團隊討論功能、介面等事宜，他對所有的程式也都很熟悉，並研究其他不同的設計方法。他甚至也會寫一點程式，但並不對任何程式負責

（3）行政助理: 外科醫師是首腦人物，對人員的調度、升遷、場地等等有最後的決定權，但他必須盡可能不被這些庶務給牽絆住，所以需要一位專門的行政助理，來幫忙處理財務、人事、場地、裝備，以及對外的一切行政事務。除非專業與顧客之間在法律、合約、報表或財務方面的確有實質上的需要，否則，行政助理不需要全職，一位行政助理可以同時處理兩個團隊的行政工作

（4）文書編輯: 外科醫師有製作文件的責任–盡他最大的可能把文件寫清楚，無論是內部或對外文件。文書編輯負責擬稿，筆錄外科醫師的口述指示，然後加以潤飾，編篡、加上參考文獻與目錄，處理文件的改版，並監督整個製作文件的過程

（5）兩位秘書: 行政助理和文書編輯都各需要一位秘書，行政助理的秘書負責處理專案的協調事宜，以及與產品無關的文件

（6）程式助理: 這個角色要負責維護團隊在軟體產品程式庫中所有技術上的紀錄，他被訓練成像秘書一樣，不論是供電腦執行的檔案，或是供人員溝通用的文件，都是其職掌範圍。

所有的輸入資料在餵給電腦執行之前，都必須先透過程式助理，視需要登記並納入管制，而輸出資料到最後也都要交給他歸檔並設定索引。任何模型的最新執行狀況都記錄在狀態日誌中，較早的日誌就按照日期的先後順序予以歸檔。

程式助理的專業職責，就是分擔程式設計師的一些例行工作，並保證在一定的效率之下，很有條理地處理一些容易忽略的瑣事，並強化整個團隊最珍貴的資產–工作產品


（7）工具專家: 服務設施是否足夠，以外科醫師一人的判定為準，他需要一位工具專家來負責，以確保擁有充分的基本服務設施，並建立、維護、更新特殊工具，只要是他的團隊用得著，不必考慮其他團隊的需要。這位工具專家將會常常製作他們專用的工具程式、一系列經過分類整理的函式與巨集庫

（8）測試員: 外科醫師需要一個充足的測試案例(test case)資料庫，以用來測試他所寫的程式片段，並供後續的整合測試之用，因此，測試員不但要擔任對立者的角色，根據規格來設計測試案例，同時也是協助者的角色，為日復一日的除錯工作來設計測試資料。他也負責規劃測試程序，建立供組件測試之用的鷹架

（9）語言專家: 他樂於鑽研程式語言的奧妙。他們的天分和外科醫師不同，外科醫師專攻系統設計，著重在系統的外在呈現方式，而語言專家則可以為你找出語言方面最簡潔有效的方法，以解決棘手、模糊、技巧性的問題。通常他需要做一些小規模的研究，以掌握某些好的技術。一位語言專家可以同時為兩到三位外科醫師提供服務


5.程式設計是「將個人技藝化為團隊合作成果」的轉換過程，電腦「所有的」執行情形對所有的團隊成員都是公開的，所有的程式和資料也都視為團隊的資產，而非個人的私藏




三. 專制、民主與系統設計

1.如果系統要提供的功能已經確定了，那麼最好能夠讓使用者用最簡單、最直接的方式來使用這些功能，所以只考慮簡單性還不夠，你必須讓使用者養成固定的使用習慣，也就是為這功能提供一整套同一系列的操作方式。

想要同時達到簡單與直接的要求，就得從概念整體性著手，每個部分都必須反映出這樣的理念


2.一個系統的架構設計師，是使用者的代言人，他的工作就是運用專業的技術和知識去為使用者真正的利益著想，而不是去考慮我們的推銷員、裝配員的喜好

3.架構旨在說明「做什麼」，而實作則是說明「如何做」

4.使用便利性的好壞是基於系統的概念整體性，若不能與系統的基本概念相容，即使這個特色或構想再好，也要放棄它。

如果實在有太多重要的構想和基本概念都不相容，那麼就乾脆放棄整個系統另起爐灶，改採其他不同的基本概念來追求一個完整的系統比較好


5.把架構的外部規格制定出來，反而會增進實作小組的創意風格，而非貶損。他們可以立即專注於真正尚未處理的問題，創意的發揮也隨之開始。

一個沒有賦予任何限制的實作小組，就會引發很多跟架構有關的不同想法或爭論，而真正的實作也就不會成為關注的部分


6.先不要成立實作小組，直到規格已經完成之後再找人

7.在系統設計時，保有概念整體性，是最重要的原則

8.功能概念複雜度「比」，才是系統設計的最終測試標準。功能多，不見得是好事

9.將架構設計獨立於實作之外是取得概念整體性強而有力的方法

10.如果系統必須保有概念上的整體性，就必須有人來控制這些概念，這就是需要專制的原因




四. 第二系統效應

1.架構設計師若要成功影響實作方式，必須：

（1）記住實作人員有發揮創意完成實作的責任，所以架構設計師只能建議，不能命令

（2）在建議時，永遠只提出一個能夠符合規格的實作方式，同時也接受其他能夠達成目標的方案

（3）默默地，私底下提出建議

（4）準備為提出的建議付出喪失信任的代價

（5）傾聽實作人員所提出來的修改架構建議


2.架構設計師要避免第二系統效應，就得為每一項小功能賦予價值：功能x要值回票價的話，所耗用的記憶體至少要小於m位元組，且耗用的時間至少要小於n微秒

3.專案經理要避免第二系統效應，就得堅持採用具有至少兩個以上系統設計經驗的架構設計老手，對一些特別的誘惑保持清醒，也可以藉由詢問自己一些適當的問題，來確保正確的概念與目標已貫徹到設計的細節之中

4.就一個人所做過的設計而言，第二個系統是最危險的系統，一般來說，都傾向於過度設計

5.為每一項功能賦予耗用多少記憶體、耗用多少時間的一個先驗(priori)值




五. 意念的傳達

1.手冊：

（1）載明產品外部的規格，用來描述並制定出使用者從外觀上將會看到的所有細節，撰寫手冊便是架構設計師的主要工作

（2）在時程上應該要有載明日期的版本資訊

（3）手冊不僅要描述使用者將會看到的所有細節，這其中包括了所有的介面，同時也要避免描述使用者看不到的東西，這些是實作人員的事，屬於他們的設計自由，就不應該對它做任何限制

（4）對於所描述的任何產品特色，架構設計師都必須隨時準備好提出「一種」實作方式供人參考，但不應該企圖硬性規定採用「特定的」實作方式

（5）手冊的風格應該要準確、完整、詳細，由於使用者將會經常個別地參考到各項定義，所以每一項定義都免不了必須重複所有的基本要點，而且仍然都必須保持一致，這雖然會使手冊閱讀起來較為無趣，但精確地說明比生動的表達來得重要

（6）手冊撰寫者應致力追求描述精確程度，哪些有規範，哪些「並未」規範，都一樣要仔細定義清楚


2.正式定義：

它是精確的，講究的是周延性，如果說法有漏洞，很容易就會被突顯出來，因此也很快地就可以加以彌補。

缺點是不易看懂，如果採用較口語的散文式說法，則較能用一個個步驟、有層次的方式寫成具有架構性的原則，還可以舉例說明，因此能輕易地指出例外情形，並強調對比差異，更重要的是可以解釋「緣由」


3.對於架構設計師而言，可建立一些用來描述內部模組介面的語法（注意，不是用來描述語意的），來幫助它強化定義和傳達意念。這種技術就是去設計傳達參數或共用儲存空間的宣告方式，並要求實作時得透過某個編譯時期的操作把宣告含入。

此外，如果這整份文件是透過一個符號名稱來參用的話，我們就可以在這份介面宣告中增加或插入新的變數，然後只需要重新編譯即可，不必大改程式


4.開會：

（1）固定每周召開會議，進行的時間大約是半天，參加的人員包括: 架構設計師、軟硬體實作小組的代表、行銷規劃人員，並由首席系統架構設計師擔任會議的主席

（2）任何人員都可以提出問題或異動提案，但書面的提案資料必須於會前分發給所有的與會人員。通常，一個新的提案會先花一點時間進行討論，但重點並不在討論，而在於激發創意，待眾多的解決方案提出來之後，其中的一些將交由一位或某幾位架構設計師整理為更精細的修正提案報告

（3）當詳細的修正提案報告彙整完成，便可以開始做決策，經過實作人員和使用者反覆而周詳的考慮後，正反兩面的看法都清楚地條列出來。如果彼此無法達成共識，就由首席系統架構設計師來裁決。會議記錄將予以保存，決策的結果也必須正式、即時、全面地公告周知

（4）隨著時間過去，有些決策並沒有持續落實，有些細瑣的事物並沒有被某些與會人員認同，另外也會有些當初無法預見的問題浮現出來。這些每周會議不被允許重新討論的議題，應開闢另一個管道以處理細瑣事務、公開討論、讓大家發洩不滿，也就是召開每半年舉辦一次，為期兩周的年度檢討大會

（5）年度檢討大會通常會在文件的重要版本敲定之前召開，參與人員不僅包括架構設計小組和程式設計小組的代表，還包括了程式編寫、行銷與任何實作小組的經理


5.如果有任何不清楚的地方，實作人員都應該打電話向負責的架構設計師詢問，而不要妄加猜測或自行解釋。重點是必須認知到，對於這些問題所做的回答，同樣是具有解釋架構上的「效力」，應該公告給所有人知道。

這些對話內容應由架構設計師負責維護紀錄，上頭記錄了所有他被問到的問題，以及他對該問題所做的回答。每個禮拜，每個架構設計師都要把記錄彙整過，然後分發給各個實作人員與使用者


6.建立一個獨立的產品測試小組，這個小組的工作就是檢查軟硬體是否符合規格，這是一個扮演黑臉的角色，負責點出你能想得到的任何缺失或矛盾之處。顧客也是獨立的稽核者，唯有透過實際使用的殘酷考驗，所有的缺點才會顯現出來

7.將定義直接融入到實作之中，可以強化架構上的標準

8.如果一開始就至少開發兩個以上的實作產品，將有助於維持架構定義的純淨與嚴謹




六. 巴別塔為什麼失敗？

1.讓每個小組之間進行溝通的方法：

（1）非正式方法: 良好的電話聯繫制度並明確定義出團隊之間的從屬關係，將可鼓勵電話的大量使用，從而使書面文件得到共同的理解

（2）會議: 一個個小組上台做技術簡報，許多系所的誤解都可以透過這種方式消除掉

（3）工作手冊: 專案一開始，就應該準備好一份正式的專案工作手冊。「所有」在專案中使用到的文件都屬於這部分，包括:計畫目標、外部規格、介面規格、技術標準、內部規格、管理備忘錄。

首要的工作就是為所有的紀錄項目標號，好讓經過排序的標題列表能夠隨時備妥，供所有人員在需要的時候方便查閱。可以規劃成樹狀結構，必要時，也可以個別對某個子樹進行維護


2.採活頁式的裝訂方式，每次只需要抽換幾頁即可。如果要特別強調更動的部分，首先，必須使用一些標註方式，例如，在被更動的每一行文字的頁邊上畫出一條垂直線；其次，當這些抽換頁分發出去的同時，額外在附上一份簡短的改版摘要，用來列出更動的部分與重點。

電子化版本：強調更動的部分，可以在上頭標註變動的部分與改版日期（按照日期越近位置則越前的方式排序），每個使用者都可以透過電腦來查閱資料。將改版摘要放在固定的位置，並且按照日期越近則位置越前的順序排列，每天更新


3.樹狀結構的軟體開發組織，每個子樹所需具備的基本要素：

（1）任務

（2）管理者: 負責召集整個小組、分派工作、規劃時程。對外，負責爭取並掌握必要的資源。

這意味這個角色的主要任務就是和別的小組溝通，無論是對上級單位或是平行單位。對內，必須建立溝通的模式與回報制度。

最後，他對時程負責，當情況有變時，必須視狀況調整資源與人力配置


（3）技術總監或架構設計師: 負責構思整個設計，切割出子系統，界定出架構的外觀與內部架構，維持整個設計的和諧與概念整體性，盡可能使系統保持單純。

當某個技術問題浮現出來時，他得尋求解決方法，並在必要的時候修改設計。其溝通主要是對內的，而且工作內容幾乎都偏重在技術方面


（4）時程

（5）人力配置

（6）各個職掌之間的介面定義


4.在工作手冊中，有些部分應該被封裝起來。不是屬於你的東西，就不必也不被允許去看裡頭的細節，你只應該看到介面

5.模組應該要被良好的介面封裝起來，模組的內部應該是程式設計師私有的東西，不應公開讓人知道，不是他負責的模組，就要對其內部機構加以保護，而非暴露出去，這樣程式設計師做起事來會最有效率




七. 地盡其利，物盡其用

1.必須做好「整體」空間規劃，這不單包括了常駐空間規劃，背後跟這些有連帶關係的存取動作也應該一併納入考量

2.在規定某個模組的大小之前，你得先精確定義出這個模組該做的事

3.當程式設計師為了效能的問題而顯得黔驢技窮之際，通常最好的做法，就是從程式碼中跳脫，回過頭去重新思考一下他所用的資料結構。資料的呈現方式「是」程式設計的本質

4.在大型專案中，每個小組傾向於為了自己的目標，只追求局部上的最佳化，而不會思考呈現給客戶的整體效果




八. 文件假說

1.規劃軟體開發專案的文件：

（1）目標: 定義出最終必須滿足的需要、必須達成的目標、期望、限制，以及各項目標的優先順序

（2）產品規格: 以提案的形式開始，專案結束時將成為操作手冊與內部性能描述，其中，有關執行速度與耗用空間的部分是重點

（3）時程

（4）預算

（5）場地配置

（6）組織編制圖




九. 失敗為成功之母

1.要使系統利於改變的方法，包括小心地模組化、善用副程式、為內部模組之間定義出明確而完整的介面，並寫出完整的文件。

你也必須盡可能使用標準的呼叫程序(calling sequence)和表格驅動技術(table-driven)。

更重要的是運用高階語言和自我說明技術(self-documenting)，以減少因改變而造成的錯誤。透過編譯時期的操作，將標準宣告融入程式的做法也非常有助於因應變化


2.把每個改變都予以量化，每個產品都應該有一系列編號的版本，而每個版本都必須各自擁有自己的時程與凍結日期，凍結後的改變都應該算在下一個版本上




十. 神兵利器

1.每個團隊都應該配置一位工具專家，通用型的工具他都精通，而且只要使用上有任何問題，他都可以提供指引，也能依照老闆的需要來量身打造特殊的工具

2.身為專案經理，必須建立起一套運作哲學，一方面不但要配置資源以建立共用工具，同時也必須認知到特殊化工具的需要，不吝於他所帶領的團隊建立屬於他們自己的工具

3.將目標機器的上機時間，以較長的時間區段來分配給各個小組，遠比理論上由各小組交錯使用的方法要好

4.主要的程式庫應分為：

（1）一組局部自由區域(playpen)，供個人使用

（2）系統整合子程式庫(system integration sublibrary)，供隨時進行系統測試之用

（3）正式交付的版本，使正式區隔(formal separation)與演進(progression)得以控制




十一. 化整為零

1.避免發生錯誤的設計方式

（1）規格審查: 早在進入程式編寫階段之前，規格文件就應該先由其他獨立的測試小組進行審查，以確保規格的完整和明確，開發人員本身則不會適合做這樣的工作

（2）由上而下的設計方式: 一開始，先勾勒出粗略的工作定義和執行方案以得到主要的結果，然後對此定義做更深入的探討，看看結果跟我們真正要的東西有何不同，並把方案中幾個大的步驟細分成更小的步驟，於是，在工作定義中的每個細分精製過程，都演變成解決方案演算法的細分精製，同時也可能伴隨著某個資料結構的細分精製。

透過上述的過程，就可以界定解決方案的模組，或是其他能夠獨立進行更進一步細分精製的資料，而模組化的程度便決定了軟體適應變動或修改的能力


（3）結構化程式設計: 在設計程式的時候，控制結構中的迴圈應該限定只能用像是 DO WHILE 這種語法來定義，條件部分則用括號上下標示成一段一段的敘述，並且使用像是 IF...THEN...ELSE 的語法

（4）建立充分的測試鷹架: 這些鷹架是為了除錯的用途而建立，並不會納入到最後產品的程式或資料。以程式碼的份量而言，屬於鷹架的部分佔產品全部程式碼的一半並不為過。

鷹架的形式可能是一個傀儡組件(dummy component)，僅僅包含介面、一些假資料或小型測試案例


（5）控制改變: 首先，必須有人負責監督，只有監督者有權掌握組件各個版本之間的更動或替換。接下來，系統的幾個副本必須受到監控：一個最新定版的版本，供組件測試之用；一個正在測試中的版本，某些修改正在進行當中；局部自由區域的版本(playpen copy)，這是每一個人可以對他所負責的組件持續進行修改或擴充的版本

開發軟體極度需要嚴密監控，並深深影響到紙上作業最後呈現在產品上的樣子，這其中最關鍵的，就是如何在暫時應急用的補綴版本(quick patch)與經過全盤思考、測試、文件紀錄的正式修正版本之間，把所有的改變和差異都記錄下來，並將之明確地反映在程式碼中


（6）一次只整合一個組件: 你必須有充足的測試案例，以供每當一個新的組件納入整合測試的時候進行測試之用，而且，之前通過測試的測試案例也必須在迴歸測試(regression test)的時候，通通回鍋再重新測過一遍

（7）固定改版的時機: 組件的版本更新應視同第一次加入的新組件，即使它花的時間應該會比較少，但同樣要經過完整的測試程序，所以完整而有效的測試案例必須隨時準備妥當。

每個小組在開發另一個組件的時候，都以最新通過測試的整合系統版本當作是自己除錯之用的測試基礎，當這個測試基礎改變的時候，他們就得配合著改變。

改版的時機應固定住，以使每個開發人員都可以擁有一段期間能夠維持穩定的工作效率，只有當這個基礎大改版的時候才被打擾，跟持續的波動相比，這種做法比較不會造成混亂。


2.早在程式進入編寫階段之前，規格文件就應該先由其他獨立的測試小組進行審查，以確保規格的完整和明確，開發人員本身則不適合做這樣的工作

3.你得等小片段大致可以正常運作之後，才能開始進行系統除錯。

不要用嘗試整合的方法，認為這樣就可以找出介面錯誤；也不要在所有的錯誤都被發現但未解決之前就開始進行系統除錯


4.建立大量的除錯鷹架和測試碼是值得的，這部分程式碼的份量可能相當於產品全部的百分之五十

5.你必須對改變和版本加以控制和記錄，團隊成員必須在局部自由區域的版本(playpen copy)中工作

6.系統除錯時，一次只整合一個組件




十二. 釀成大災難

1.里程碑必須是具體、明確、可量測的事件，有沒有達成應該是一翻兩瞪眼的事，絕不可模稜兩可。具體的里程碑，是百分之百完成的事件

2.計畫評核圖(PERT chart)或要徑時程表(critical-path schedule)可以幫助你辨別出哪些延誤才是真正該關心的部分

3.每一位老闆都必須掌握的兩種資訊：

（1）計畫執行的現況

（2）未如計畫預期的意外狀況


4.老闆想知道真相的兩種做法：

（1）降低角色的衝突以鼓勵據實回報: 首先，什麼是他該採取應變措施的資訊，什麼只是讓他了解計劃型現況的資訊，老闆必須分清楚。他必須克制自己「不要」去干涉部屬自己有能力處理的問題，也「絕不」在對狀況仍在進行了解的時候就馬上動手解決問題。

老闆必須將會議明確界定出是以「執行狀況報告」為主的會議，和以「討論解決方案」為主的會議


（2）審查制度: 每周都要審查計畫評核圖中的幾個部分，而全面性的審查則大約每個月要做一次


5.計畫評核圖的製作與維護，是老闆以及負責向老闆報告的各個主管的職責，對於計劃評核圖的修正、改版、報告，老闆需要一個小組(一到三人)來幫他注意這件事。

這個小組沒有其他實權，只能在設定、修改里程碑，或是在確認里程碑是否已如期完成的時候，可以向第一線的基層主管諮詢


6.在里程碑進度報告中同時標示出「規劃」日期（老闆的日期）和「預估」日期（基層管理者的日期）是很好的做法。專案經理必須克制自己不去插手管預估日期

7.對大型專案來說，非常值得成立一個「計畫監控」小組來維護里程碑報告




十三. 一體兩面

1.為程式而寫的文件：先求淺顯但涵蓋面廣泛，再逐漸深入解釋細節

（1）目的: 程式的主要功能為何？為什麼要寫這支程式？

（2）環境: 程式要在哪種機器上跑？硬體和作業系統的組態該如何設定？

（3）輸入值域與輸出值域: 程式輸入與輸出資料的合理範圍為何？

（4）欲達成的功能與使用的演算法: 很精確地說出程式到底要做什麼事情？

（5）輸出入格式: 要精確而完整地描述

（6）執行過程中的指示: 包括運作正常時，或因異常而終止時，在控制台或任何輸出裝置上應該要看得到的任何提示

（7）選項: 使用者在功能上有哪些選擇彈性？這些選項該如何正確地加以指定？

（8）執行時間: 對於某個工作，在某個組態所指定的空間大小限制之下，程式要花多少時間來完成？

（9）輸出結果的精確度與檢驗方式: 預期的結果必須精確到什麼程度？跟這種精確度相搭配的檢驗方式為何？

﹡整份文件必須密切注意是否寫得既簡單又明確。此外，由於這類文件將具體呈現出基本的規畫決策，所以多半在編寫程式之前就必須備妥


2.交付出去的程式碼都應附帶一小組測試案例，每組測試案例包含三個部分：

（1）主案例: 用於測試程式的主要功能，以一般最常發生的狀況當作測試的輸入資料

（2）罕見合法案例: 用於進行邊界值測試，包括輸入資料的最大可能值、最小可能值，以及所有例外但合理的情況

（3）罕見不合法案例，也是用於邊界值測試，不同的是採取相反的角度，以確保當輸入的資料不合理時，都能引發適當的偵錯訊息


3.為修改程式而寫的文件：

（1）流程圖或副程式的結構圖

（2）所有運用到的演算法的一份完整描述，或是在內容中參考到其他有完整描述的文件

（3）所有運用到的檔案的一份設計說明

（4）解釋階段架構(pass structure)的概觀－就是硬碟中載入資料或程式的處理順序－以及每個階段必須完成的事

（5）與修改相關的研討紀錄，包括原設計構想、可插入點與離開點的類型與位置，以及原設計者對一些可能的變化所做的推論與提供的因應之道


4.不要嘗試同步維護不同的文件，對於同一件事物的相關資訊，應盡可能統一放在同一份文件中。

你可以把書面說明整合到程式碼裡頭，這麼做可以改善維護工作，而且也保證程式使用者可以隨時便利地參考文件。


5.降低文件維護負擔的可行方案：

（1）藉助於那些基於語言的要求而必須存在的語句，盡可能容納更多的訊息在裡頭，標籤、宣告、符號名稱都可以用來傳達某些涵義給閱讀者

（2）善用留白或某些固定格式來增進可讀性，表現出從屬和巢狀的關係

（3）以註解的形式在程式裡加入一些敘述，特別是模組的標頭檔(header)


6.降低文件維護負擔的技巧：

（1）為每次的執行都取一個獨立的工作名稱，並以此名稱來維護用以記載目的、時間、結果的執行紀錄。該名稱的組成可用一個便於記憶的代號加上一個數字字尾，此字尾是用來標明某次執行的編號，以建立與各個紀錄的參考關係。

這個做法在每次執行的時候都需要準備一個工作卡，但這件事可以整批來做，於是共同的資料便可以重複使用


（2）為程式取一個易記的名稱。名稱中包含版本的識別碼，以適用於程式具多種版本的情況

（3）以一般口語化的敘述方式為此程序加上註解

（4）記錄程式中所使用的演算法可供參考的文件。由於參考文獻中已經有最詳盡的說明，所以這麼做可以節省說明的空間，並讓經驗豐富的閱讀者可以省略不看

（5）指出程式與文獻中所記載的演算法之間的關係: a.改變 b.使用上的特例 c.代表性的做法

（6）宣告所有的變數，並使用易記的名稱，以註解來對所宣告的變數做更進一步的解釋。

注意程式本身已經包括了變數名稱並進行了結構化的編排，所以註解只需要針對變數的目的來描述即可，以避免程式碼與註解重複同樣的命名與編排


（7）以標籤來標明變數的初始設定

（8）以標籤來標明一個區塊的程式片段，表示出同屬一個完整演算法的程式敘述

（9）以縮牌來突顯結構與分段

（10）手工加入邏輯上代表執行流程的箭頭，這些箭頭在除錯或修改程式時非常有用。把它們標示在註解的右側邊界上，使之成為程式的一部份，但不影響機器讀取

（11）單行註解，或是補充講解任何不夠清楚的地方

（12）把多個程式敘述寫在同一行，或將單一個程式敘述拆成多行來寫，使必須同在一起進行思考的部分放在一塊，並使它看起來與其他演算法的描述是一致的


7.即使是寫給自己使用的程式，也有必要留下一些說明

8.供程式修改者使用的文件中，所描述的應該不僅僅「是什麼」，還應該說明「為什麼」。「目的」的說明是了解與否的關鍵所在




十四. 沒有銀彈：軟體工程的本質性與附屬性工作

1.多加利用大眾市場，避免開發現成就買得到的東西

2.在制定軟體需求時，採用多次反覆的方式，並把快速原型製作(rapid prototyping)納入所規劃的每個反覆之中

3.讓軟體像生物一樣地發育成長，在系統持續被執行、被使用、被測試的過程中，逐步擴充功能

4.培養偉大設計師的步驟：

（1）有計畫地盡早辨識出頂尖的設計人才，而最好的，往往不是最資深的

（2）指派一位負責生涯規劃的老手來引導這位明日之星的成長，並掌握住一份精心規劃的生涯檔案

（3）為各個明日之星設計並維護一份生涯成長計畫，包括小心地篩選跟隨頂尖設計師見習的人員、安排更高階的正式教育，以及短期課程，過程中穿插由他獨力設計和技術領導的任務指派

（4）提供機會讓這些成長中的設計師能夠在一起交流並相互刺激