前言

晚上好，我是 miruky。

前陣子黃金週期間，我和高中學長（技術負責人）一起去喝酒。
當時聊到學長經歷過的失火專案，學長說了類似「不是有布魯克斯定律嗎？那次真的就是那樣」的話；雖然我以前在書上看過，但很慚愧地說，老實講我完全想不起意思。

不只這個，工程師圈裡不知道為什麼有很多大家都知道的「◯◯定律」「◯◯原則」「◯◯效應」之類的詞。其他行業也有格言或經驗法則，但工程師圈特別容易在對話中冒出這類詞吧。我想大概是受重視哲學思想的英語圈文化，以及反映這種文化的書籍影響。

具體來說，像是剛剛提到的布魯克斯定律、康威定律、海勒姆定律、喬舒亞樹定律、石頭湯、青蛙效應、重造輪子、剃羊毛，等等。

也許不一定非得記住不可，但作為工程師的素養，也作為自己的自尊，我想還是記下來比較好（避免重蹈覆轍……）。
有些在 code review 時也會派上用場，所以這篇文章會把工程師總有一天會聽到的知名說法，整理成簡短的意思與使用情境。請當成備忘錄來看。

這篇文章比起學術上的嚴謹，更重視「工程師在對話中常不常用」「會不會出現在名著或古典軟體工程脈絡中」。刻意省略了一些比較冷門的詞。

目次

1. 定律類
2. 其他
3. 使用注意事項

1. 定律類

星號是我主觀上「工程師圈的對話或 review 裡，當成術語使用的頻率」的目安。不是嚴格排名，請把它看成技術文章、設計討論、程式碼審查中的出現頻率。

星級目安★★★★★ 5 顆星。對話或 review 中非常常用★★★★☆ 4 顆星。作為常識知道，設計或閒聊中會出現★★★☆☆ 3 顆星。知道的人有，但日常對話中少一些★★☆☆☆ 2 顆星。在書或古典文獻中看過，但平常不太聽到★☆☆☆☆ 1 顆星。相當冷門。本文幾乎不使用首先是，常被當作軟體開發現場「定律」來看待的項目。

1-1. 專案與組織的定律

$$
康威定律 ★★★★☆
$$

系統的結構會像建立它的組織溝通結構，這就是這個定律。

例如，認證團隊、付款團隊、庫存團隊彼此完全不交流的組織，就容易讓這種斷裂反映在 API 邊界與畫面流程上。看起來是在談架構，其實也在談組織設計。微服務拆分、團隊拆分、責任邊界的討論裡很常出現。

$$
布魯克斯定律 ★★★★☆
$$

對已經延遲的軟體開發再加人，反而可能更慢，這就是這個定律。

這不是單純地說「不要加人」而已。因為要花時間向新人說明、對齊認知、做 review、合併、協調決策，所以對延期專案事後再加人，通常沒有立刻效果。這常被拿來當作對失火案件加人前的警告。

$$
帕金森定律 ★★★★☆
$$

工作會膨脹到把可用時間填滿，這就是這個定律。

如果截止日期是 1 週，就會做 1 週；如果是 1 個月，就可能做 1 個月。會議也是一樣，明明 30 分鐘就能討論完的議題，若排成 1 小時，有時就真的會花掉 1 小時。這也是把 deadline、review 期間、會議時間切短的理由。就像暑假作業，認真做幾週其實就能結束，但最後往往要到暑假快結束才會完成。

$$
90-90 法則 ★★★☆☆
$$

前 90% 的程式碼會花掉 90% 的開發時間，而剩下 10% 的程式碼又會再花掉 90% 的時間，這是帶點諷刺的說法。這句話常被認為出自 Tom Cargill，也曾在 John Bentley 的 Programming Pearls 中介紹過。

重點在於總共會變成 180%。這也解釋了為什麼「差不多完成了」「剩下只是小修」通常不可信。最後的邊界案例、例外處理、文件、測試、營運相關工作，往往比想像中重很多。這應該是很容易從經驗中體會到的吧。

$$
帕金森凡俗法則 ★★★☆☆
$$

人們比起重要又困難的問題，往往更容易把時間花在明顯又瑣碎的問題上，這個定律也叫作自行車棚效應。

最有名的比喻是，原子爐的設計反而不如自行車棚的顏色那麼容易引發討論。開發現場則常表現為，明明應該先處理架構難題，結果會議卻老是在變數名稱、按鈕顏色、文案細節上延長。

$$
彼得定律 ★★★☆☆
$$

人會一路升遷，直到能力達到極限為止，並且停在那裡，這就是這個定律。

把優秀的工程師升成主管，不代表一定會變成好主管。工程師的能力，和招募、評估、團隊設計、預算協調的能力並不是同一件事。這是工程管理職或技術負責人角色設計時，很值得想到的一句話。

$$
霍夫施塔特定律 ★★☆☆☆
$$

做一件事總會比預想花更久，即使你把這個定律考慮進去，還是會更久，這是一種自指式的定律。

在估工、發佈規劃、移轉作業、舊系統翻新時特別有感。它簡短地描述了現場現實：你以為已經留了餘裕，但最後還是不夠。

1-2. 設計與程式碼的定律

$$
波斯特爾定律 ★★★★☆
$$

送出要嚴格，接收要寬容，這是源自網路通訊協定的原則。

它以 TCP/IP 的舊 RFC 中提出的 Robustness Principle 而聞名。在早期網際網路中，能接受一些小幅變動的寬容性，提升了相容性。不過在現代 Web 與資安情境下，過度寬容的接收有時會導致規格含糊或漏洞。對輸入驗證來說，也要注意不要「寬容過頭」。

$$
德米特定律 ★★★★☆
$$

物件只應該認識很近的夥伴，這是設計原則。也稱為最少知識原則。

像 user.getCompany().getAddress().getZip() 這種很長的連鎖呼叫，會增加對內部結構的依賴。呼叫端知道太多遠端細節時，就會對結構變更變得脆弱。這在類別設計、領域模型、API 設計中特別重要。

$$
洩漏抽象化定律 ★★★★☆
$$

任何抽象化，最後都會在某處洩漏底層的事情，這就是這個定律。

就算用了 ORM，還是得懂 SQL。就算用了雲端，還是得懂網路與 IAM。就算用了 React 或 Next.js，瀏覽器機制還是會滲出來。抽象化很方便，但它不會把底層完全消除。

$$
卡尼漢定律 ★★★★☆
$$

除錯比寫程式更難；所以，若寫出連自己都難以修正的過於聰明程式，就會很麻煩。

這是對單行程式、過度巢狀的三元運算子、過度的 metaprogramming、以及像在考驗讀者的抽象化的一種提醒。程式不該只看「能不能寫出來」，而要看「之後能不能讀懂」「出 bug 時能不能修」。

$$
阿特伍德定律 ★★★★☆
$$

凡是可以用 JavaScript 寫的東西，最後都會被用 JavaScript 寫出來，這就是這個定律。

它簡潔地描述了 Web 技術從瀏覽器擴展到伺服器、桌面、行動裝置、CLI、IoT 的過程。看著 Electron、Node.js、React Native 這些技術時，會莫名地覺得很有道理。

$$
海勒姆定律 ★★★☆☆
$$

只要使用者夠多，系統可觀測到的行為就一定會被某些人依賴，這就是這個定律。

如果你有對外公開 API，應該很能理解。比方說，「剛好回傳欄位順序固定」「錯誤訊息每次都一樣」「處理時間大致固定」這種看似不起眼的行為，使用者也會依賴它。即使規格文件沒寫，眼前看得到的行為也可能變成契約，這很可怕。

$$
李納斯定律 ★★★☆☆
$$

只要有足夠多的眼睛， bug 就會變淺，這是在開源脈絡中很有名的一句話。這裡的李納斯定律並不是 Linus Torvalds 本人的原話，而是眾所周知由 Eric Raymond 在《大教堂與市集》裡提出的想法。

意思是：越多人看，就越容易發現 bug 或找出原因。它很適合用來說明 review、OSS、稽核、bug bounty 的價值。不過，光有人數不夠，還必須有看得出問題的專業、容易 review 的設計、測試，以及可重現性，才會真的有效。

$$
札溫斯基定律 ★★☆☆☆
$$

方便的程式最終往往會膨脹到連郵件都能讀，這是帶點諷刺的說法。

本質上是在說：方便的工具會一路加功能，最後不知不覺變成巨型平台。原本只是小型待辦工具，結果加上聊天、行事曆、郵件、AI、工作流程，最後什麼都包進去的那種現象。

$$
豪豬定律 ★★☆☆☆
$$

大多數東西的大多數部分都很普通，這是很不留情面的定律。

你可以用它來提醒自己，在看函式庫、範例程式、技術文章、OSS、AI 生成程式時要保持冷靜。不是看到世上的東西都要奉為圭臬，而是要有能力找出真正好的那 10%。

1-3. 效能與擴展的定律

$$
摩爾定律 ★★★★☆
$$

半導體的整合密度在一定期間內大致翻倍，這是經驗法則。

最初是針對積體電路上的元件數做出的預測，後來也廣泛用在「計算效能持續提升」的脈絡。不過，現在受限於物理極限與製造成本，已經不像以前那麼單純了。

$$
阿姆達爾定律 ★★★★☆
$$

即使做了平行化，直列部分仍然會限制整體速度提升，這就是這個定律。

它會讓「把伺服器加多就會變快」這種粗略想法冷靜下來。如果瓶頸在資料庫鎖、單一佇列、外部 API、同步處理，那麼只增加 worker 也有極限。它常出現在多執行緒、分散式處理、GPU 使用時的主機端處理或資料傳輸等存在直列瓶頸的情境。

$$
威爾特定律 ★★★☆☆
$$

軟體往往會比硬體變快的速度還更慢，這是帶點諷刺的說法。

即使硬體變快了，依賴關係膨脹、抽象化增加、Electron 化、過度新增功能，還是可能讓體感速度上不去。這常出現在效能改善或輕量化的討論中。

$$
梅特卡夫定律 ★★★☆☆
$$

參與者數量增加時，網路價值會大幅成長，這就是這個定律。

假設參與者數是 n，那麼可連接的配對數會以 n(n-1)/2 成長。當 n 很大時，會接近參與者數平方的成長，因此常被描述成網路價值與參與者數平方成正比。常用於社群平台、交易市場、通訊網路、開發者社群的說明。

$$
古斯塔夫森定律 ★★☆☆☆
$$

如果問題規模也能一起變大，那麼平行化的效果會看起來更大，這就是這個定律。

阿姆達爾定律關注的是「固定工作能加速多少」，而古斯塔夫森定律則從「資源增加之後，可以解更大的問題」來看。常出現在 HPC、批次處理、大規模資料處理。

1-4. 指標與決策的定律

$$
巴列圖法則 ★★★★★
$$

這個連工程師以外的人也很有名。結果往往是由少數原因造成的，這就是這個定律。也叫做 80/20 法則。

例如，很多障礙集中在少數功能、很多詢問集中在少數畫面、很多營收來自少數客戶。它可用來分析重要 bug、主要使用者、常見詢問。

$$
墨菲定律 ★★★★★
$$

通常可簡化為「凡是可能出錯的事，最後都會出錯」的定律。

在實務上，它不是要你想「不會失敗」，而是要你思考「如果失敗，要怎麼安全停下來」。它和障礙設計、重試、監控、備份、冪等性、失敗保護很合拍。那個把塗了果醬的吐司掉到地上，結果偏偏果醬那面朝下的故事，也很有名。

$$
古德哈特定律 ★★★★☆
$$

當指標變成目標時，那個指標就不再是好的指標，這就是這個定律。這個說法廣為流傳，並常被視為 Marilyn Strathern 的著名轉述。

如果把測試涵蓋率當目標，就會出現很多沒意義的測試；如果把 velocity 拿來評價，就會把票券切得更細、變成遊戲化；如果把障礙件數當目標，可能會有人不報小障礙。指標是拿來看的，但如果只剩「追指標」，就會壞掉。

$$
蓋爾定律 ★★★☆☆
$$

能運作的複雜系統，都是從能運作的簡單系統演化而來。

與其一開始就做出巨大又理想的系統，不如先做出能跑的小東西，再慢慢長大，成功率通常更高。這在新產品、大規模重構、基礎平台翻新時特別有用。

$$
坎貝爾定律 ★★☆☆☆
$$

越是被用來做重要決策的指標，就越容易被扭曲，這就是這個定律。

它和古德哈特定律很接近，但常用在評估制度、教育、行政、KPI 運作等場景。若放到開發團隊，把 PR 數、commit 數、story point、review 數直接和評價綁在一起，就很容易產生扭曲。

2. 其他

接下來是嚴格來說不一定是定律，但在工程師圈裡非常通用的原則、策略、指標、比喻，以及來自名著的說法。

2-1. 設計原則

$$
DRY ★★★★★
$$

這個我真的在 code review 裡被指正過。DRY 是 Don't Repeat Yourself 的縮寫，意思是不要讓同一份知識在多個地方重複。

但常常被誤解成「不要重複寫一模一樣的程式碼」。其實不該重複的是主要的 知識，像是商業規則、常數、schema、規格。如果把只是長得像的程式碼硬要共用，反而可能更難修改。這部分很值得去讀《The Pragmatic Programmer》。

$$
KISS ★★★★★
$$

KISS 是 Keep It Simple, Stupid 的縮寫，意思是盡量保持簡單。

它對設計、API、營運流程、團隊規則都很有效。比起聰明的抽象化，更該優先考慮能讀懂的結構、能說明的結構、壞掉時能修的結構。真的，簡單就是最好。

$$
YAGNI ★★★★★
$$

YAGNI 是 You Aren't Gonna Need It 的縮寫，意思是還不需要的功能就不要先做，這是 Extreme Programming（XP） 來的原則。

這不是叫你不要思考未來，而是提醒你不要為了還沒確定的未來，提前做出複雜抽象化或一堆設定項目。很多自以為是為未來準備的程式，最後其實一次也沒用到，這種事非常常見。

$$
SOLID ★★★★★
$$

這是物件導向設計中常被提到的五項原則首字母縮寫。

包含單一職責原則、開放封閉原則、里氏替換原則、介面隔離原則、依賴反轉原則。現代也有人用批判性角度來看，但作為思考依賴關係、變更理由、職責切分的共同語彙，仍然很有力量。

$$
單一職責原則 ★★★★★
$$

這個也超常聽到。意思是讓模組或類別的變更理由盡量只有一個。

這不代表「一個 class 只能有一個 method」。如果使用者畫面變更、收費規則變更、資料庫儲存格式變更都塞在同一個 class 裡，那很可能就是責任範圍太大了。

$$
關注點分離 ★★★★★
$$

意思是不要把不同的關注點混在一起。

UI、領域邏輯、資料庫存取、驗證、日誌、通知、外部 API 呼叫一旦混在一起，修改就會變得可怕。這也是分層架構、整潔架構、MVC 的根本想法之一。

$$
最小權限原則 ★★★★★
$$

這可以說是一定要知道的原則。意思是只給完成工作所需的最小權限，屬於資安原則。

它可以廣泛用在 IAM、資料庫權限、CI/CD、GitHub Actions、AI agent、MCP 工具、管理後台等。權限不是「先放大再說」，而是「先確認需要範圍，再盡量縮小給予」。

$$
開放封閉原則 ★★★★☆
$$

對擴充開放，對既有修改封閉，這就是這個原則。

當要新增新的付款方式或通知目的地時，希望不用到處改舊程式。只是如果做過頭，會變成一堆抽象化，所以要和 YAGNI 取得平衡。

$$
最小驚訝原則 ★★★★☆
$$

讓使用者不會感到意外，這就是這個原則。

它適用於函式名稱、API 回應、UI、預設值、CLI 選項。例如 deleteUser() 明明叫刪除，卻只是軟刪除；get 卻會更新資料庫，這都會造成驚訝。

$$
Unix 哲學 ★★★★☆
$$

把東西做小，並且把它們組合得好，這是 Unix 文化中的設計思想。

代表性的概念包括「一個工具做好一件事」「用文字串流串接」「小工具彼此組合」。它影響了 CLI、pipe、微服務，以及給開發者用的工具設計。

$$
WET ★★☆☆☆
$$

WET 可以解釋成 Write Everything Twice、Write Every Time，或 We Enjoy Typing，是 DRY 的反面，表示不好的狀態。

意思是同一個處理、同一條規則、同一份設定被寫得到處都是。這會導致修改時只改到一邊、文件和程式碼脫節、測試還在看舊行為等事故。DRY 和 WET 這種對應，還滿有趣的。

$$
ETC（易於變更） ★★☆☆☆
$$

ETC 是 Easier to Change 的縮寫，意思是把「容易變更」放在設計判斷的中心。

在《The Pragmatic Programmer》第 2 版中，ETC 被說明為一種價值，而不是規則。DRY、KISS、YAGNI、關注點分離等，看起來是不同原則，但最後都可收斂到「之後能不能安全修改」這件事。猶豫不決時，可以回頭問：這個實作，是讓下一次變更更容易，還是更困難？

2-2. 名著中常見的開發方法與比喻

$$
原型 ★★★★★
$$

這是用來學習、並且打算之後丟掉的東西。

它通常用於試驗未知技術、UI、函式庫、效能特性。重點是不要把「會拿去正式上線的東西」和「會丟掉的東西」搞混。原本打算丟掉的程式如果直接變成正式版，會很危險。它和追蹤彈（曳光彈）在開發方法中的差異，也常被拿來討論。

$$
重造輪子 ★★★★★
$$

這是指把已經存在的東西又白白重新做一遍的比喻。真的很常聽到。

常用在不查函式庫或標準功能，卻自己做框架、自己做加密的情況。不過，如果目的是學習，或限制條件很明確，重新實作其實也有價值。真正的問題不是重寫本身，而是在明明已有成熟知識時，還故意忽略它而重複犯同樣的錯。

$$
青蛙煮死效應 ★★★★☆
$$

如果問題是逐漸惡化，人們就不容易注意到危險，這是一種比喻。

《The Pragmatic Programmer》裡和石頭湯並列提到的就是這個故事。傳說中，青蛙被慢慢加熱的水包圍，結果無法察覺危險。這就成了形容「對緩慢劣化變得遲鈍」的說法。

例如，build 慢了一分鐘一分鐘地變慢、測試越來越容易壞、型別錯誤慢慢被忽略。這些都不是瞬間事故，所以容易被忽略，但最後會拖慢整個團隊速度。這就是技術債增加的樣子。要注意，這最好當作軟體開發的比喻，而不是生物學事實。

$$
破窗理論 ★★★★☆
$$

如果小小的荒廢被放著不管，整體就會越來越亂，這個理論很有名，不限於工程師圈。

如果套到程式碼上，就是壞掉的測試、隨便取的名稱、被放置的 TODO、沒有格式化的檔案、失敗的 CI。小荒廢若不處理，就會形成「這個 repo 可以隨便對待」的氣氛。

$$
橡皮鴨除錯 ★★★★☆
$$

把問題說給別人聽，自己就會注意到原因，這是一種除錯方法。

對象不一定要是真人，桌上的橡皮鴨也可以。透過一行一行解釋程式碼，你會看見自己理解上的漏洞。這也很適合當作 review 前的自我檢查。

$$
沒有銀彈 ★★★★☆
$$

沒有任何技術能一次解決軟體開發本質上的困難，這是 Frederick Brooks 很有名的主張。

即使出現新的語言、框架、雲端、AI 工具，規格理解、複雜性、變更、溝通的難題也不會消失。這句話是用來抑制對新技術過度期待的。這裡的「銀彈」是指傳說中可以一擊打倒怪物的武器隱喻。

$$
剃羊毛 ★★★★☆
$$

原本只是想做某項工作，卻在前置作業上一路連鎖下去的現象。

像是「我只是想做一個小修正，結果為了跑測試先升 Node，為了升 Node 又修 CI，為了修 CI 又重看權限，回過神來已經在做完全不同的事了」這種狀況。常發生在環境建置與依賴更新時。

$$
石頭湯 ★★★☆☆
$$

先製造一個小小的契機，再把周圍的人捲進來，讓事情變大，這是這個比喻。

原本是民間故事：旅行者說要用石頭煮湯，先借鍋，然後從周圍的人那裡一點一點拿到食材，最後真的煮出一鍋湯。

在明明直接說「我們來全面重構吧」也沒人會動的情況下，先提出一個小小的改善 PR。別人看到後就補上測試，另一個人補上文件，最後就變成一場改善活動。這就是這種做法。

$$
追蹤彈（曳光彈） ★★★☆☆
$$

這是先打通一條接近正式版的細縱切面。曳光彈讀作「えいこうだん」。

名字的由來是會發光、能看見彈道的曳光彈。先打出去觀察彈道，再命中目標，概念就是這樣。

它不是單純會丟掉的原型，而是先薄薄地通過實際架構。UI、API、DB、部署、監控先走一條最小路徑，再逐步加厚。這和 walking skeleton 也很接近。

和原型的差別在於，是不是以「保留並持續成長」為前提。兩者都是為了早期回饋，但追蹤彈是作為朝向正式版的細實作來處理。

2-3. 認知與學習的比喻

$$
喬舒亞樹定律 ★★★★★
$$

這是一個很有共鳴的說法：當你知道某個名字之後，原本看不見的東西就開始看得見了。

嚴格來說，它不太像學術上的定律，比較像 Joshua Tree principle 或 Joshua Tree effect 這類比喻。像是當你知道「海勒姆定律」這個名字後，在 API review 中就會開始注意到「這個東西會被某人依賴吧」。設計模式、反模式、障礙模式、認知偏誤，只要知道名字，就會更容易觀察到。

$$
鄧寧－克魯格效應 ★★★★☆
$$

在某個領域能力越低的人，越容易高估自己的能力，這是一種認知偏誤。

常被粗略解讀成「新手越自信」，但原本的意思還包括：因為缺乏能力，也較難察覺自己的錯誤，連 metacognition 都不足。這也很像對 AI 生成程式的過度自信。越是不熟的領域，越不能只靠直覺下結論，而要搭配驗證與 review。

$$
確認偏誤 ★★★★☆
$$

人們容易只蒐集符合自己假設的資訊，這是一種認知偏誤。

在障礙調查時，如果先入為主地認定「一定是 DB 的問題」，就會只看對 DB 有利的 log。性能調校或 review 也會發生這種事。提出假設很重要，但也要看能否推翻它的證據。

$$
奧卡姆剃刀 ★★★★☆
$$

如果多種解釋都一樣成立，就不要無謂地增加假設，這是一種思考方式。

名稱來自 14 世紀哲學家兼神學家 William of Ockham。它以「不要在沒有必要時增加東西」的簡單性原則而聞名，常被比喻成用剃刀把多餘假設刮掉。

在障礙調查時，先不要立刻懷疑複雜的分散式系統 bug；先確認設定錯誤、環境變數、部署遺漏、輸入值、時區等更簡單的原因。簡單的解釋不一定永遠對，但作為第一個假設很強。

$$
切斯特頓的柵欄 ★★★★☆
$$

還沒理解以前，不要把不知道用途的東西隨便拆掉，這是一種思考方式。

這來自 G. K. 切斯特頓的論述。看到路邊的柵欄，不應該先想「看起來沒用，拆掉吧」，而是先理解它為什麼會存在。

在舊系統裡，看到莫名其妙的 if 或怪異設定時，會很想直接刪掉。但那可能是過去障礙處理或客戶客製需求留下來的痕跡。刪之前要先看 log、Issue、commit 歷史，以及當事人的記憶。

$$
幸存者偏差 ★★★☆☆
$$

只看留下來的成功案例，卻據此做判斷，這就是偏差。

只看成功的新創、熱門 OSS、爆紅技術文章，就會以為「照著做就會成功」。但同樣方法失敗的大量案例其實看不見。這在技術選型與職涯論述上都很值得注意。

$$
巴德爾－邁因霍夫現象（頻率錯覺） ★★☆☆☆
$$

剛學到的詞，會突然覺得到處都看得到，這就是這種現象，也叫頻率錯覺。

剛記住一個新技術名詞後，常會覺得動態牆、文章、會議裡突然一直看到它。其實不一定是它變多了，而是你的注意力開始往那裡跑。

2-4. 架構與分散式系統的定番

$$
CAP 定理 ★★★★★
$$

在分散式系統裡，不可能同時完全滿足一致性、可用性、分區容錯性，這就是這個定理。

常被簡化成「三個只能選兩個」，但在實務上，更自然的理解是：當發生網路分區時，要在一致性與可用性之間怎麼取捨。

$$
冪等性 ★★★★★
$$

同一個操作重複執行多次，結果也不會改變，這就是這種性質。讀作「べきとうせい」。

更精確地說，同一個操作執行一次或多次，對伺服器狀態而言，預期效果都相同即可；回應內容不一定每次都完全一樣。網路會失敗，重試也會發生，所以才需要設計成同一筆付款請求或 Webhook 收到兩次，也不會被重複處理。這在付款、工作處理、API 設計上非常重要。

$$
故障安全 ★★★★★
$$

即使失敗，也要讓系統朝向安全的一側倒下，這是這種思考方式。

如果授權失敗，就拒絕，而不是放行。付款狀態不明時，就保留，而不是重複扣款。控制系統若出問題，就停止，而不是繼續危險運作。這是資安與安全性的基本。

$$
防呆設計 ★★★★★
$$

即使人犯錯，也盡量不會進入危險狀態，這是一種透過操作與設計降低失誤的想法。

例如刪除按鈕加確認、危險的正式環境操作要求輸入環境名稱、破壞性指令預設停用、輸入值改成選單選擇等等。重點不是依賴使用者或操作人員小心，而是讓系統本身就不容易犯錯。

$$
最終一致性 ★★★★☆
$$

不是立刻一致，但過一段時間後會一致，這就是這種想法。

常見於 NoSQL、快取、事件驅動、非同步處理。寫入後馬上讀取，可能會看到舊值；但過一陣子後就會一致。

$$
快速失敗 ★★★★☆
$$

如果有問題，就盡早讓它失敗，這是一種設計想法。

設定不夠、輸入不合法、依賴服務連不上，這些問題不要拖到後面才爆，而是要在早期就停下來。常用在輸入驗證、設定檢查、CI、啟動時檢查。

$$
背壓 ★★★☆☆
$$

當接收端處理不過來時，限制傳送端的機制。

它會出現在佇列、串流、API 限流、日誌處理中。如果接收端已經塞住還一直送，就會造成記憶體膨脹、延遲增加，最後甚至當掉。這就是流量控制的概念。

$$
優雅降級 ★★★☆☆
$$

部分壞掉時，盡量讓整體還能運作，這就是這種想法。

外部 API 壞了，核心功能仍然持續。推薦系統掛了，商品列表還是要出來。圖片轉換延遲，就先只顯示文字。常用於故障時的縮減運作與韌性設計。

2-5. 組織與開發的戰略、指標

$$
巴士因子 ★★★★☆
$$

這是工程師才會特別在意的概念。它表示：少掉幾個人後，專案會停擺？

如果巴士因子是 1，那麼那個人只要離職、調動、休假，專案就會有危險。它用來衡量過度依賴特定個人、文件不足、review 體制不足的風險。可以透過 code review、pair 作業、作業手冊、輪調來提高。

$$
逆向康威策略 ★★★☆☆
$$

把康威定律反過來用，根據想做出的架構來設計組織，這是一種想法。

也就是說：「我想要這樣的服務邊界，所以團隊也要跟著那個邊界切分。」這和 Team Topologies、平台團隊、流向對齊團隊、限界上下文的討論很合。

3. 使用注意事項

前面列出的這些詞很方便，但並不是萬能的。

3-1. 不要只用名稱就結束討論

「這就是布魯克斯定律」「這就是 YAGNI」「這就是康威」如果只說到這裡，對話就會變成咒語。

重點是在講出名稱之後，要把它具體化。

【壞例子】

「這就是 YAGNI」就結束。

【好例子】

「這個擴充點，現在這個季度內有具體需求會用到嗎？」這樣來問。

【壞例子】

「布魯克斯定律，所以做不到」就結束。

【好例子】

「現在再加人，光是 onboarding 和 review 大概就會多拖兩週。」把影響具體化。

名稱只是捷徑。它不是拿來省略說明，而是拿來讓討論更深入。

3-2. 名著的話要翻譯成現場語言

《The Pragmatic Programmer》《人月神話》《UNIX 觀念》《軟體工程經典》裡的詞，即使現在讀，仍然塞滿能直接用在現場的知識。

但要直接套到現代的 Web 開發、雲端、AI agent、分散式系統上，還是需要一點翻譯。

• 石頭湯，放到現在就是「用小小的改善 PR 把團隊拉進來」
• 青蛙煮死效應，放到現在就是「CI 變慢、型別鬆掉，卻一點一點放著不管」
• 重造輪子，放到現在就是「不查既有函式庫就自己做；但若是為了學習，其實有價值」
• 洩漏抽象化，放到現在就是「就算用了雲端或 AI 工具，也不能完全忘掉底層機制」

古典不是拿來背誦的，而是拿來替現場的不對勁命名的工具。
也別變成一直狂用外來語、讓人不敢靠近的那種人喔。

結語

感謝看到這裡。

工程師圈裡那些有名的定律和比喻，不只是單純的冷知識。它們能讓你用短短的名字，想起估工為什麼老是失準、組織結構為什麼會反映到程式碼、API 相容性為什麼不容易壞、指標為什麼會被扭曲、技術債為什麼會悄悄增加。

這篇文章最想傳達的只有一件事：知道名稱之後，就更容易察覺現場的不對勁。 這正是喬舒亞樹定律本身。

那麼，我們下次再見。

參考連結

定律類

• Hyrum's Law
• How Do Committees Invent? - Melvin E. Conway
• RFC 761 DoD standard Transmission Control Protocol - RFC Editor
• The Law of Leaky Abstractions - Joel on Software
• Zawinski's Law - The Jargon File
• Ninety-Ninety Rule - The Jargon File
• Moore's Law Predicts the Future of Integrated Circuits - Computer History Museum
• Metcalfe’s Law and Social Networks - Matt Mullenweg
• Little's Law - Wolfram MathWorld
• Brewer's Conjecture and the Feasibility of Consistent, Available, Partition-Tolerant Web Services
• The Laws of Software Engineering
• Goodhart's Law - FORRT
• Assessing the Impact of Planned Social Change - Office of Justice Programs

名著與原則

• The Pragmatic Programmer, 20th Anniversary Edition - Pragmatic Bookshelf
• Tracer Bullets and Prototypes - Artima
• You Aren't Gonna Need It - C2 Wiki
• The Law of Demeter - Northeastern University
• Basics of the Unix Philosophy - Eric S. Raymond
• No Silver Bullet - Frederick P. Brooks

比喻、認知、其他

• Rubber duck debugging
• Yak shaving - TechTarget
• Bus factor - Wiktionary
• Occam's razor - Britannica
• Unskilled and unaware of it - CiNii Research
• The Joshua Tree Epiphany - O'Reilly
• The infrequency illusion - Language Log

原文出處：https://qiita.com/miruky/items/cef8169b4a10cdd790b5