神兵利器 | 人月神話：軟體專案管理之道

工匠與他的工具#

Brooks 以一句古老的智慧開場：

「工匠的價值，從他的工具便可見一斑。」

優秀的工具能夠大幅提升程式設計的生產力。然而，大多數軟體專案在工具方面的投資嚴重不足。Brooks 認為，專案經理必須認真對待工具的建設，就如同認真對待系統架構本身一樣。

專案團隊需要兩類工具：

Brooks 特別強調，每個團隊都應該有一位專職的工具匠（toolsmith）——一位專門負責建造和維護團隊專用工具的程式設計師。這個角色不是兼職，而是全職投入。工具匠了解團隊的需求，能夠快速回應工具方面的問題與改進要求。

工具匠的價值常常被低估。當團隊中每個人都因為缺乏合適的工具而浪費 20% 的時間，一位專職工具匠的投資回報將極為可觀。

軟體最終運行的機器稱為目標機器（target machine），它通常是稀缺的共享資源。Brooks 提出兩種開發模式：

所有團隊共享目標機器時間。問題顯而易見：排程衝突、等待時間長、資源爭奪激烈。

團隊在另一台載具機器（vehicle machine）上進行日常開發，只在需要實際測試時才使用目標機器。載具機器提供以下工具：

Brooks 建議混合排程策略：一部分時間以固定區塊分配給個人，一部分時間保持不排程以供臨時需求。全部排程或全部不排程都會造成效率低落。

Brooks 描述了一套精密的程式庫管理系統，由三個子庫組成：

程式碼的晉升路徑是嚴格單向的：遊戲場 → 整合子庫 → 目前版本。每一次晉升都需要通過相應的測試和審查。

這套三層程式庫結構，本質上就是現代版本控制系統（version control）的雛形。Brooks 在 1975 年描述的流程，與今日的 Git 分支策略（feature branch → staging → main）驚人地相似。

程式庫管理員（program clerk）負責管理程式碼在三個子庫之間的流動。這個角色維護所有版本的記錄，確保變更的可追溯性，並控制整合的節奏。

Brooks 強烈主張使用高階語言（high-level language）進行開發。他以當時的 PL/I 為例，指出高階語言帶來的好處：

使用高階語言的生產力提升不僅僅來自於「少寫程式碼」。更重要的是，高階語言讓程式設計師能夠在更高的抽象層次上思考問題，減少因低階細節而分心的認知負擔。

Brooks 引用 Multics 系統的經驗，指出互動式開發（interactive programming）——即透過終端機即時與系統互動——相較於傳統的批次處理（batch processing），能帶來約 2 倍的生產力提升。

關鍵在於回饋時間（turnaround time）。當程式設計師可以立即看到修改的結果，他的思維流程不會被打斷。而在批次處理模式下，提交一次修改後可能需要等待數小時才能看到結果，等待期間的思維脈絡早已消散。

Brooks 還提倡使用自動化文件產生系統，直接從原始碼中提取文件。這個概念在後續章節（第 15 章）中會有更深入的討論。