眼睛的 Page-Fault 機制#

本文是 Joel 對 Scott Rosenberg 的《Dreaming in Code》一書的評論。Joel 從人類視覺的運作方式切入：

• 你的視力只在視野中很小的區域是高解析度的，正中央還有相當大的盲點
• 但你的眼睛能非常快速地移動，神經系統將這個過程抽象化，讓你產生一覽無遺的錯覺
• 這就像作業系統的 page-fault 機制——實際上只有很小一塊區域是高解析度的，但你從未懷疑過

你的大腦會習慣性地高估自己清晰判斷事物的能力，總覺得自己看到了全部，但事實不是如此。這在軟體開發中是一個特別危險的陷阱。

大構想的兩個致命錯誤#

當你在腦中形成一個整體的設想，覺得一切清楚無比，便一頭扎入工作時，你已經犯了兩個錯誤：

錯誤一：對自己的設想過於自信#

• 「我們完全清楚怎麼做！不需要寫詳細的說明書，直接寫代碼就行了。」
• 實際上你的「清晰構想」就像視覺錯覺一樣，充滿了你沒有注意到的模糊地帶

錯誤二：在產品設計之前就開始雇用程式設計師#

• 世界上只有一件事比你自己設計軟體更困難——一個團隊一起設計軟體
• 開會討論設計往往毫無成果，最好的設計來自一個人拿起紙筆獨自琢磨

Chandler 專案的教訓#

Joel 以開源日曆軟體 Chandler 為反面教材：

• 花了幾百萬美元和好幾年時間，成果卻只是一個充滿錯誤的半成品
• 原始設想太宏偉：「點對點」、「杜絕資訊孤島」、「自然語言日期解釋」——但細節設計嚴重不足
• 設計報告只用形容詞描述產品（「該產品將酷斃了」），而沒有提及具體細節

當設計報告只有形容詞而沒有具體細節時，你就知道麻煩了。「杜絕資訊孤島」這個設想聽起來很棒，但一旦思考如何實現，你就會發現這個想法根本做不到。

開源協作的困境#

• 如果你想複製現有軟體的功能，志願者的幫助很大
• 但如果你想做一個小小的功能擴展，志願者反而幫不上忙——因為沒有應用程式，就沒有使用者，也就沒有人為你貢獻代碼

好的軟體設計應該從具體的細節出發，而非宏大的構想。先確保每個小功能都設計清楚，再逐步拼成整體。