SSOT Single Source of Truth

單一真理來源、唯一事實來源。資訊系統架構中的一個核心概念。其核心目標在於確保組織內的每個人、每個系統，在需要特定數據時，都參考同一個來源，從而避免數據不一致導致的決策錯誤。

這樣做可以確保：

• 所有資訊的一致性和準確性

• 減少重複數據和資訊衝突

• 方便查找與更新

• 簡化備份、遷移和共享流程

• 促進團隊協作與溝通

SSOT 並不是指將「所有數據」都存在同一個資料庫中，而是指對於某個特定的數據點（例如：客戶地址、產品價格、庫存數量），在整個系統中只有一個權威的來源（Master Copy）。

在 IT 領域的應用意義

1. 確保數據一致性 (Data Consistency)

在大型 IT 架構中，多個系統（如 ERP、CRM、電商網站）往往會共用相同的數據。若沒有 SSOT，當客戶修改地址時，若只更新了 CRM 而沒更新 ERP，就會導致出貨錯誤。實施 SSOT 後，所有系統都會向「客戶主資料庫」看齊。

2. 降低數據冗餘與維護成本

重複的數據存儲不僅浪費空間，更增加了維護難度。透過 SSOT，開發人員不需要編寫複雜的邏輯來比對多個資料庫之間的差異，簡化了系統整合的複雜度。

3. 提升決策與分析的準確性

對於商業智慧（BI）與大數據分析而言，SSOT 是基礎。如果財務部門和銷售部門提供的營收報表數據對不起來（可能因為計算邏輯或數據來源不同），管理層將難以做出正確判斷。SSOT 確保了「數據來源一致」。

4. 加速開發與自動化

在 DevOps 或現代軟體開發中，SSOT 的概念也被應用於：

• Infrastructure as Code (IaC): 例如 Git 就是基礎設施配置的 SSOT。

• API 驅動架構: 透過統一的 API 接口存取權威數據，避免直接對原始資料庫進行多點讀寫。

實施 SSOT 的挑戰

雖然 SSOT 理想上很完美，但在實際運作中常遇到以下困難：

• 跨部門溝通: 定義「誰才是權威來源」往往涉及組織權責分配。

• 系統效能: 若所有系統都即時請求同一個數據源，可能造成效能瓶頸（通常透過緩存同步機制解決）。

• 舊系統轉型: 整合缺乏標準接口的舊有系統（Legacy Systems）需要極大成本。

抽象洩漏定律 (The Law of Leaky Abstractions)

Joel Spolsky 於 2002 年提出 Leaky Abstractions 抽象洩漏定律

All non-trivial abstractions, to some degree, are leaky. 所有難以理解複雜的抽象機制，在某種程度上，都是有漏洞的。

因為軟體的開發與運作環境複雜，開發人員不可能自造所有的輪子，而必須依靠各種抽象化的機制（大部分是 API 函式庫）進行開發，在隱藏細節的環境下，進行開發。經過一個開發人員的實作與開發後，某個程度下，又多了一層抽象封裝。但這些抽象封裝機制，不可避免都會洩漏出底層的一些問題，洩漏出無法封裝的問題。

在使用者使用抽象化後的介面後，在遇到不可預期的問題時，就必須要去了解底層的細節，才能知道發生的原因，也才能解決問題與除錯。雖然抽象封裝節省了開發的時間，但踩雷與除錯所耗費的時間也不少。因此我們才會在很多 QA 網站中，找到一些其他人的踩雷經驗與技巧。有經驗的開發人員，也會因為這些經驗的累積，避開可能會遇到的問題。

以下是一些抽象洩漏的例子

• TCP 是現今網路的基礎，大部分的網路溝通，都需要利用 TCP 的可靠傳輸協定傳送資料，但不可避免的是 TCP 的流量控制機制本身就是有缺陷的協定，網路無法在一個穩定的流量通道上進行傳送，延遲跟 throughput 的波動對於 TCP 來說，都是正常的現象。但一般來說，沒有經驗的開發人員是無法預知到這些問題。

• SQL 查詢語言是關聯式資料庫的查詢語法，但某些 SQL 查詢語法卻是有性能差異的，例如 select * from table 就會比 select column1, column2 from table 速度來得慢。另外因為 AP Server 跟 DB 是分屬不同機器的狀況下，查詢時把整個資料表的所有欄位都取出來，也會造成網路頻寬的耗費而影像整體效能。

當我們遇到了一項新技術，宣稱因為良好的封裝，可以加速開發時。這時候最好是停下來想想看，這樣的封裝是不是真的有帶來實際的效益，還是會因為採用了這樣的抽象化封裝，而帶來一些無法預期的問題。

我們曾經使用過可以在 ios 與 android 同時運作的開發工具，但最終因為封裝後的函式庫本身的限制，無法微調，且函式庫無法跟隨作業系統的更新就馬上更新，最終只能放棄而採用原生的方式開發。但這不代表這種工具是不好的，對於畫面簡單的應用程式來說，使用者種方式開發，確實會帶來一些好處，但要有心理準備，可能會遇到一些根本且無法解決的問題。

References

The Law of Leaky Abstractions – Joel on Software

抽象泄漏_百度百科

為什麼任何系統都會存在Bug？什麼是抽象漏洞定律？ - 每日頭條

抽象漏洞定律The Law of Leaky Abstractions

抽象泄漏定律 | 张吉的博客

抽象泄漏 - Wikiwand

複雜性守恆定律 Tesler's Law

Larry Tesler 於 1984 年提出複雜性守恆定律 Tesler's Law。每個程式都有其內在無法簡化的複雜程度，無法被刪除或是隱藏，到了臨界點，就無法再被簡化，因此，必須在人機介面的設計中，不斷地調整與平衡，適當地將使用介面跟產品內部的複雜度調整與轉移。

例如傳統的電視機，畫面裡面的顯示設定很簡單，複雜的是在電視遙控器，遙控器上有數十個按鈕可以進行設定。新的智慧電視，遙控器的介面非常簡潔，但畫面內的功能與設定卻非常多。使用者跟電視之間的交互作用關係的整體複雜度不變，但透過介面設計的不同，轉移了複雜度的比重關係。

Macbook Pro 在外接的介面孔，逐漸地簡化，導致使用者無法直接使用 HDMI、SD card、USB，機器因為孔位減少，外觀簡潔更好看。但使用者卻必須要透過外接的轉接線路，才能連接 USB、SD card。

Tesler's Law 說明了，系統「整體複雜度」是固定的，如果要簡化使用者操作，就會增加其他部分的複雜度，因為產品設計與開發的時間跟人力都需要耗費成本，無法追求極致的使用者體驗。複雜度在平衡與轉移的過程中，都會產生 cost，如果有低成本的轉移方式，就能持續進行轉移。

太過於精簡的介面，也會讓使用者嗤之以鼻，沒有難度的操作方式，會失去眼球焦點，適當的難度可讓使用者持續沈浸於產品的體驗中。更簡單的使用者體驗，通常代表更複雜的系統設計。需要由設計師跟開發團隊，進行複雜度的權衡。

在產品的發展初期，因為核心功能不多，通常介面也會比較簡單，但隨著時間與產品的演進，功能慢慢的擴張，涵蓋到其他的範圍，複雜度也會慢慢地提升。

References

「自然交互· 泰斯勒定律」如何平衡设计的复杂度？

複雜度守恆定律_百度百科

什么是特斯勒定律？

分布式計算的謬論 (The Fallacies of Distributed Computing)

Sun MicroSystem 的幾位工程師，提出了分散式系統的八個謬論，是一般開發人員，對於分散式系統的錯誤認知假設，有了這些基本的認知錯誤，設計的系統常會發生一些不能預期的問題。

前四個是 Bill Joy 與 Dave Lyon 定義的，後來 Peter Deutsch 增加了 5,6,7 三個，最後 James Gosling 定義了第八個。

1. 網路是可靠的

   任何透過網路的遠端系統呼叫，都有可能會發生意外而失敗。為了處理遠端系統可能的離線異常，通常會帶入 MQ 系統，將遠端呼叫的需求放入 MQ，然後自動 retry，但加入了 MQ，就會用非同步的方式，處理一開始的 Request，這會直接影響原始的系統設計。

2. 延遲是零

   網路因為頻寬的限制，以及客戶端到伺服器端的距離，一定會發生資料傳遞的延遲。

   傳統的電話線路是獨佔式的，一條線路只能讓一通電話使用。網路電話是不同的，需要經過語音及類比、數位轉換，然後透過分享的網路線路進行封包傳送，網路電話的延遲通常會比傳統電話還要大。

3. 頻寬是無限的

   網路封包是透過無線電或網路線傳送，但實體的傳送媒體，都會因為該傳輸媒體及資料轉換機制，而有資料傳送速度的限制。在處理大資料量的應用，例如網路電話，直播等等，更需要注意頻寬限制的問題。

4. 網路是安全的

   網路技術會進步與更新，但網路攻擊的技術也同時在進步，網路攻擊一定存在，也不存在無法被攻擊的系統，系統只能應付攻擊，而做對應的處理。

5. 拓撲結構不會改變

   機器與連線的配置與架構會不斷改變，當系統故障/更新時，會需要改變現有的系統架構。

6. 有一個管理員

   任何地方都可能會出錯，當系統發生問題，沒有一個管理員可以知道所有的狀況，並能了解所有的問題。

7. 運輸成本為零

   因為需要有頻寬、伺服器、網路、Load Balancer、防火牆等等網路架構與機制，所以網路服務都是需要花錢的，沒有能夠免費提供的服務，但現在能使用免費網路服務的原因，都是因為公司用另一個方式，取得了營運資金，用來支撐免費的服務。

8. 網路是同質的

   網路是透過各種協定交互運作組成的，如果是開放的標準通訊協定，可在不同系統上交互運作，如果是自訂的通訊規格，就可能會發生無法相容的問題。

References

驾驭分布式计算的8个谬误 - 掘金

# 圖說分佈式計算的 8 大謬誤

分布式系统中经典的八个谬误-51CTO.COM

柯林漢定律 (Kernighan's Law)

Brian Kernighan 在其著作 "The Elements of Programming Style" 提出一個經驗法則，稱為 Kernighan's Law。

Debugging is twice as hard as writing the code in the first place.
Therefore, if you write the code as cleverly as possible, 
you are, by definition, 
not smart enough to debug it.

除錯要比寫程式困難兩倍，
因此，如果程式寫得很精巧，
那你就沒有足夠的智慧能夠除錯。

對這句話的理解，我認為是跟程式的簡潔度及可讀性有關。

越複雜冗長的程式碼，因為程式碼太長，在 debug 時，就越不容易找到問題點。但有些人會在寫程式時，追求到極致，希望能用非常短的程式碼完成。One-liner program 的目標是，用一行程式碼完成一項功能，追求簡潔的程式碼。

這種做法沒有對錯，在高階程式語言，用很短的程式碼完成很多事情，比較容易發生，但在中低階語言，像是 C 語言，刻意追求 one-liner，會產生反效果，因為程式碼太短，而讓人難以理解在寫什麼。

因此良好的程式，應該要具有相當程度的可讀性，可讀性並不代表程式碼很多或很少，而是程式碼以大家都能理解的方式撰寫，程式的結構良好，一個可讀性高的程式，程式碼的長度可長可短。

原文中的精巧，可能是針對 C 語言的說法，因為 C 語言是中低階程式語言，精巧的程式，是聰明的寫法，也代表能用比較短的程式完成工作，在 CPU 及記憶體貧乏的時代，這種做法是有必要的，但這也代表這些程式碼會讓人難以理解，也就更難除錯。

Brian Kernighan 跟 Dennis Ritchie 是 "The C Programming Language" 這本經典書籍的作者，這本書是所有寫 C 語言要閱讀的經典書籍，也因為這本書，建立了一個規則，所有程式語言的第一個測試程式，都是要列印 "Hello, World!" 這個字串到螢幕上。另外這本書的 C 語言 coding style 也被稱為 K & R style。

Kernighan 還是 Unix 作業系統的命名者，原本被稱為 UNICS (Uniplexed Information and Computing System)，另外還是 awk 這個工具的作者。

References

80歲了還在改程式碼的大神：他是Unix命名人、寫下所有程式新手的「Hello World」起手式 | T客邦

過早優化效應 (Premature Optimization Effect)

Donald Knuth 在 The Art of Computer Programming 提出了過早優化法則

We should forget about small efficiencies,
say about 97% of the time:
premature optimization is the root fo all evel.
Yet we should not pass up our opportunities
in that critical 3%.

有 97% 的優化是不值得花時間去做的，過早優化是萬惡根源。
但還是要注意在關鍵的 3% 要提早去優化。

把開發時間花在不重要的優化上，可能會因為過度優化，而化簡為繁，讓系統太過複雜。過早的優化，會浪費大量資源，包含時間、金錢、人力，同時也可能因為這些優化，而衍生出其他的問題。

對於這個法則的爭論點在於，系統的哪個部分是關鍵的 3%。

這個問題跟開發人員的經驗、能力，專案的時程跟預算，系統規劃時設定的最大容量這些有關係。

要知道系統的 3% 關鍵，需要在產品規劃與設計時，就能夠預判系統的使用環境，同時的上線人數。但要能正確預判專案的基本條件並不容易，尤其是一個面對未知系統人數的服務，因為我們永遠不知道，這個系統是不是會爆紅而導致系統的瞬間流量突然增加。一但發生這個狀況，也只能面對，因為一般使用者，甚至是系統的 stake holder 都無法正確預判，有時候就只能等到事情發生了才知道，但也過了那個大流量的使用時機，因為使用者已經失去了信心，不會再用。

有經驗的開發人員，因為經驗的累積，能夠用以往的專案經驗，在新專案一開始的時候，就套用了一個基本能夠彈性修改的系統架構，但難免會遇到一個根本的問題，就是系統的運作硬體環境，程式語言或是 framework 本身的性能瓶頸，或是專案預算的限制。

問題都是存在的，但我們要知道，所有的系統使用時都有極限與限制，盡可能以漸進的方式使用某項新的系統與技術，用保守的態度面對，這樣應該比較能避免遇到問題。激進的方法當然也有可能成功，就看後續的問題處理，運氣好的話，也能撐過動蕩期。

References

过早优化是万恶之源——克努特优化原则 (Knuth's optimization principle) - 腾讯云开发者社区-腾讯云

# 流言終結者：過早進行優化是萬惡之源？

# 「过早的优化是万恶之源」这种说法对不对，为什么？

帕金森瑣碎定理 (The Law of Triviality)

Cyril Northcote Parkinson 於 1957年提出，大型組織會花費大量時間在無關禁藥的瑣事上，但是遇到重大議題時，卻能很輕易地通過。這是因為一般人對於重大議題，無法完全理解而怕貿然提出建議而失言。對於一般簡單瑣碎的事情，因為基本認知足夠，故會有很多意見，造成大型組織在事項的討論度，花費的時間與其重要性成反比。

Parkinson 在 Parkinson's law, and other studies in administration 這本書中提出了幾個實例：

1. 1000萬美元的核子反應爐，審查委員中有四個不知道反應爐是什麼，三個不知道有什麼用，兩個不知道預算多少，剩下的其中有兩個對預算有疑慮，一個提出要找專家，一個覺得無法講清楚，所以就不表示意見，整個議題花了2.5mins 通過。

2. 建自行車棚，大家的意見很多，爭論要用什麼材料跟預算多少才合理，花了很多時間大家聽懂了，討論了 45mins，節省 300 美元。

3. 飲料要選什麼？他們花了很多時間討論，有些人覺得不要花時間討論，但有些人爭論要不要提供咖啡，最終他們要求秘書弄清楚每個人的需求再決定。

瑣碎定理是對議題的討論狀況的描述，大部分都會是在一個會議中會發生，要避免發生瑣碎定理的問題，有幾個方法

1. 事先準備

   提前告知與會人員會議的議題，大家能預先了解議題內容，才能快速針對議題進行討論。臨時告知的議題，多數人會覺得是意外，沒有先備知識，就無法提出適當的意見進行討論。

   事先對於會議定下規則，限制每個人的發言時間，或是要求大家都要發言。

2. 預先安排議程

   一般傾向把最重要的事情留到最後再說，但應該把最重要的議題放在最前面討論，要能面對並解決問題，最好的方法就是開門見山

3. 盡可能減少或不開會

   減少沒有用的會議，訊息傳遞在現今的科技下，已經不是問題。並不是所有的資訊，對每個人來說都是必要要知道的。

References

帕金森瑣碎定理 - 維基百科，自由的百科全書

帕金森瑣碎定理 - MBA智库百科

經濟學人：如何避免出現「帕金森瑣碎定律」 - 每日頭條

帕金森定理 (Parkinson's Law)

1955年 Cyril Northcote Parkinson 在 The Economist 發表一篇短文

Work expands so as to fill the time available for its completion.

在工作能夠完成的時限內，工作量會一直增加，直到所有可用時間都被填充為止

後來在 1958年，擴充為一本書：Parkinson's Law: The Pursuit of Progress

The demand upon a resource tends to expand to match the supply of the resource (If the price is zero).

在預算之內，支出的需求會一直增加，直到所有資源被用完為止

員工會製造很多瑣碎的工作，讓自己看起來很忙，就算時間充裕，也會放慢工作速度，或是找其他的事情做，直到預定的交付時間被填滿。後續又以工作量增加要求招僱更多員工，組織漸漸膨脹，但從外面看起來，大家看起來很忙，實際上是工作效率低下。

1. 增加下屬法則

2. 增加工作法則

為避免工作拖延的狀況，管理者可以安排更多工作，或是制定不合理的交付時間。但這樣的作法可能會有副作用：

1. 期限內無法完成的事情會越來越多

2. 為了在期限內完成，無法確保工作品質

3. 員工因不堪負荷而離職

本定律要發生有四個條件

1. 要有一個組織，管理階層在組織中佔有一定的地位

2. 該管理者能力平庸，是個不稱職的管理者

3. 對該管理者而言，可能因為某些事情而喪失權力

4. 該組織是個不斷自我要求完善的組織，能夠不斷吸收新人

References

帕金森定理 - 維基百科，自由的百科全書

# 帕金森定律》為何公司的人越來越多，生產效率卻越來越差？

帕金森定律：如何克服它以提高生產力 • Asana

《每個人的商學院・管理基礎》：大企業最常犯的「帕金森定律」與「彼得原理」 - The News Lens 關鍵評論網

帕金森定律 - MBA智库百科

隱式接口法則 (Hyrum's Law, The Law of Implicit Interfaces)

在 Google 開發 C++ library 的工程師 Hyrum Wright 在網站 https://www.hyrumslaw.com 提出一個軟體工程中觀察的經驗法則：

With a sufficient number of users of an API,
it does not matter what you promise in the contract:
all observable behaviors of your system
will be depended on by somebody.

當某個 API 有了相當多的使用者以後，
原本的規格已經不重要了：
因為所有可被發現的系統行為，
都會被某人使用，並依賴該系統行為。

API 是系統模組之間互相交互運作的介面，也是某個功能模組的抽象化，因為單一功能模組的內容細節過於複雜，無法讓所有人都理解細節，故使用者會透過抽象介面使用該功能。

隨著系統的使用者增加，會漸漸地透過實作的細節，慢慢披露出該模組的未公開的功能內容，導致有越來越多的使用者，依賴於該 API 的所有系統行為。也就是隱式接口法則。

隱式接口通常是慢慢發生的，使用者並不會意識到正在發生，例如：API 通常沒有性能保證，但使用者會期待該 API 能夠達到某個程度的運算能力，這表示 API 可能需要被慢慢修改到符合使用者的期待。

例如 Hash 的輸出順序，在原本的定義中，並不會保證有固定輸出的順序，但某些語言實作時，會發生固定輸出順序的狀況，導致有使用者套用這個規則使用 Hash。

References

海拉姆定律——一个软件工程的观察

软件工程中的海仑定律 - hyrumslaw

程序员应知必会的思维模型之 16 隐式接口定律 (Hyrum‘s Law or The Law of Implicit Interfaces)_知识大胖的博客-CSDN博客_hyrum's law

赫特伯定律 Hutber's Law

Patrick Hutber 於 1970 年代提出 Hutber's Law

Improvement means deterioration.

改善等同於惡化。任何改善的細節中，都隱藏著可能的惡化因子。對於系統的某個部份的功能改進，可能會影響到其他部分，導致其他功能發生問題。

在對軟體進行改版，修改功能的時候，常會發生 side effect 副作用，有可能是功能本身定義的問題，因為該功能的定義修改，而造成其他功能的條件設定跟原本的不同了。也有可能是因為共用程式碼的關係，某個部份的修改，在另一個部分重用的時候，造成條件不符的問題。

但這種問題，常常很難在第一時間就被發現。

Test Driven 軟體開發方法，就是在開發時，要寫足夠多的測試程式碼，這些測試程式就可以用來預先發生這些可能的未知問題。用大量自動化的測試，來提醒開發人員無法預先知道的問題。

但在使用者介面測試這個部分，目前還比較不容易做自動化，目前是有自動化 UI 測試的工具，但要維護 UI Test 的成本太高，有些問題也無法用自動化測試察覺。

References

Hutber's law - Wikipedia

Hutber’s Law Explained - YouTube

0-90法則 ninety-ninety rule

貝爾實驗室 Tom Cargill 提出 90-90 法則，後來因為 Jon Bentley 寫在 ACM 的 programming Pearls 專欄的 Rule of Credibility 文章中而流行。

The first 90 percent of the code accounts for the first 90 percent of the development time. The remaining 10 percent of the code accounts for the other 90 percent of the development time.

開發軟體時，前90%的代碼要花費90%的開發時間，剩餘的10%的代碼要再花費90%的開發時間。

90-90 法則跟侯世達定律 Hofstadter's Law 都是說明同一件事，一個專案，會花上比預期還要多的時間才能完成。

軟體業的本質，其實某個程度來說，不是高科技產業，而像是一種手工業，也就是軟體手工業，因為軟體是程式設計師，用一行一行的程式碼，將程式邏輯組合而成的一種工藝品。這種耗費智力的工藝品，不同於其他工業產品，生產效率跟品質很難被評估，也可以說軟體工程師像是一種智能的純手工工人，要把程式碼一行一行打出來，才能完成作品。

References

90-90法則_百度百科

90-90法則 - MBA智库百科

90-90法則:簡介,軟體項目管理,風險策劃,有關因素,_中文百科全書

侯世達定律 Hofstadter's Law

Hofstadter 在「哥德爾、艾舍爾、巴赫書：集異璧之大成」這本書中，提到了一條 Hofstadter's Law：做事所花費的時間總是比你預期的要長，即使你的預期中考慮了侯世達定律。

在工作規劃時，總是需要做評估，在軟體工程中，評估卻是最困難的問題，永遠都會估算失準，即使開發過程中，沒有特殊的技術問題，或只是修改已經做過的事情，但還是有可能會有其他人為因素，改變了原本的時程。

這時候就變成另一種做法，在原本樂觀的估算結果後，乘上一定程度的風險值，這些增加出來的時間，就成為 buffer。但這也可能會發生另一種問題，時程只要經過一個人的加總與估算，就會多膨脹一點點，誤差也會變得更大。

如果單純只考慮開發的時程，或許還能接受，時程不準確的問題，但專案總是會有 stakeholders，也有預算成本的問題，牽涉到金錢跟最後交付的時程，還有專案誠品的成熟度，在管理階層、業務單位、客戶之間，這些問題就會不斷地放大，近一步影響到所有人。

即使大家都知道「花費的時間總是比你預期的要長」，身處不同的角色，就有不同的應對方式，也會用各種不同的手段想要達到預期的結果，但最終還是只能讓最底層的開發人員，花上足夠的時間，去完成該做的事情。

References

侯世達定律：做事所花費的時間總是比你預期的要長 - 頭條匯

每個人都應該了解的定律——侯世達定律 - 壹讀

侯世達定律 - 台部落

GitHub - nusr/hacker-laws-zh: 💻📖对开发人员有用的定律、理论、原则和模式。(Laws, Theories, Principles and Patterns that developers will find useful.)

古德哈特定律 Goodhart's Law

Goodhart's Law 是以 Charles Goodhart 命名的，在 1975 年，由於英國貨幣政策，他提出了：當壓力施加於某個統計指標，進行控制時，將會失去任何觀測得到的統計恆性。

在一個獎懲系統中，為了得到最後的結果，將會作出獲得最多獎勵的行為。也就是在有已知量化標準的表現衡量體系中，員工會嘗試最初獲得最多獎勵的行為，但該行為不一定會實現利潤最大化。

Jón Danı́elsson 用另一句話描述：當用於決策之上，任何的統計關係都會分崩離析。當用於管制之上時，任何的風險模型都會分崩離析。

古德哈特定律：「當一項指標被設定為要達成的目標時，這項指標就無法成為一個好的指標。」"When a measure becomes a target, it ceases to be a good measure.)"

這個規則是在警告，一個量度的評估標準或指標，最後將會被濫用，而失去原本的功能。

如果單以「送貨量」衡量配送員的工作績效，會讓到貨時間縮短，但也可能會發生客戶滿意度下降，或是車禍，配送員代簽等等問題。

為提升治安情況，指標訂立是觀察每月、每年每一個分局的破案率，如分局的破案率不佳，則分局長就調離現職。各分局為追求破案率，就可能會發生吃案的情況。用各種方式引導減少報案數量，自然就能提升破案率。

為提升客服人員效率，薪資由固定制改為績效制，以接電話處理案件的數量作為發新標準。客服人員會為了績效，對客戶更不耐煩，或是快速地掛斷電話，雖然案件處理量增加，但服務品質卻下降了。

量化的量測指標是不可避免的，以科學的角度來看，事件需要客觀的量測指標，才能依照這個標準，得到真正的事件發生指數。像新冠肺炎，統一以 CT 值，來作為傳染力（確診）的標準，但在精確度要求不高的情況下，一般以快篩作為量測的標準。不同的量測方式，因為誤差出錯的比例也不同。

Goodhart's Law 在討論的就是量測指標，跟最後的誤差結果。每一種量測指標，會有不同的誤差，在牽涉的量測人類的行為標準上，誤差不同於科學量測的誤差不大會改變，會因為人類的行為改變，而讓原本的量測標準誤差改變而失準。

解決的方式，就是不要使用單一量測指標，要採用多重指標。在多重觀測指標的交互影響下，讓偏差值降到最低。

References

古德哈特定律 - MBA智库百科

單一指標對決策的影響-淺談 古德哈特定律 - Growing Thinker 警惕网络安全的“古德哈特定律” - 安全内参 | 决策者的网络安全知识库

古德哈特定律 - 維基百科，自由的百科全書

坎寧漢姆定律 Cunningham's Law

根據 Steven McGeady 的說法，在 1980 年代，Ward Cunningham 曾經給他一個建議：「在 Internet 得到正確答案的做法，並不是提問，而是先貼出一個錯誤答案。」McGeady 引述為 Cunningham's Law，這個規則正好是 Wikipedia 的運作法則，Cunningham 本人則否認了這個說法，認為這是錯誤的引用。

Ward Cunningham 在 1995 年於The Portland Pattern Repository's Wiki建立了第一個 wiki site，他也是 "The Wiki Way" 這本書的作者，該書討論 wiki 協作編輯系統。

像這樣的提問，都是 Cunningham's Law 的實踐

• 「5000元左右根本買不到好的遊戲本，全是水貨」

• 「根本找不到一個形容詞可以形容現時的政府」你同意嗎？

• 問小孩問題時

  • 今天在學校做了什麼事情？

  • 沒什麼

  • 你今天翹課了喔

  • 沒有啊，我們都在學校上課

用這個方法雖然可以快速得到答案，但也會有這樣的缺點：發言的人被認為是笨蛋。因此不要在正式場合使用，可在無聊時講垃圾話使用。

跟這個法則相反的狀況，有這樣的成語：眾口鑠金、積非成是、三人成虎、人云亦云

因此，這個法則並不能用在所有的問題上，只能用在可以確定，被提問的那些人，一定會有正確答案的狀況。當有人是用「聽說」來回答問題時，就可能會被錯誤的答案誤導。

2022年底也發生過這樣的事情：遭爆假街訪！哈哈台沉默5天回應　網破盲點狠酸：避重就輕│影片│造假│路人│TVBS新聞網

我自己也常看哈哈台，哈哈台的提問方式，就是用很多網路上的說法，來詢問當地民眾，如果把它當作綜藝，博君一笑，應該是沒什麼問題，但畢竟不可能每一次拍攝，都能找到一些當地奇人來回答，為了追求收視率，找臨演來拍影片，對當地人來說，被抓到也會覺得情何以堪。

不同的講者跟受眾，也會有不同的感受。看事情的角度不同，難免就會產生不同的觀點及感受。

難怪有很多專業的喜劇演員，私底下會是沈默寡言，常常會有憂鬱症的狀況。在很多衝突下，還要盡全力搞笑真難。

公視在 2022 也有討論這樣的議題：「你敢開身障者玩笑嗎？」

@hahaping ＸLeo @chairman1227 X王榮璋 X 雪莉@sherry0813 ｜「你敢開身障者玩笑嗎？」X 《禁忌不禁忌》｜〈公視主題之夜SHOW〉 - YouTube

References

【坎寧漢姆定律（Cunninghams Law）】到底是什麼？怎麼理解？ ? - GetIt01

【沃爾得英語】坎寧漢姆定律 ：“擡槓式提問” 、“茬架式求助”, battle啊！ - 雪花新闻

坎寧安定律 - Meta

沃德·坎寧安 - 維基百科，自由的百科全書

Cunningham's Law: The sun is flat, isn’t it?

眾口鑠金 [正文] - 成語檢視 - 教育部《成語典》2020 [基礎版]

布魯克斯法則 (Brooks's Law) - 人月神話

Frederick P. Brooks, Jr. 於 IBM System/360 開發階段任職專案經理，OS/360設計階段任職軟體專案經理。在他管理的軟體專案經驗中，他將經歷寫成一本著名的軟體開發管理書本，名為「人月神話」。

在人月神話中，他提出一個觀念：在一個進度已經落後的專案再增加人手時，只會讓這個專案進度拖延更久。

在軟體專案管理中，有一些重要的事項，就是開發人力跟耗費的時間。這些估算工作，很多時候只能用經驗法則來判斷，由於這個估算無法非常準確，而且會隨著時間的前進，一直不斷地變化。

多數的管理人員都會用很單純的人月互換法則，來進行工作的估算，例如一個 10 人月的工作量，要直接分配給 5 個人用 2 個月的時間開發。

這是因為工作項目在切割的同時，就發生了項目的先後關係，且每一個項目在不同人員開發時，得到的成果跟品質不同，最後也會在整合階段，發生不同的問題，導致實際上不可能發生 10 人月 = 5 人 x 2 月。

一般在遇到進度延遲的狀況時，第一個反應會是增加人手，就像是蓋房子蓋到一半趕進度，就會想要從別的地方調派人力過來幫忙。但軟體專案沒有辦法依照這種想法處理，任意增加人手，很有可能會讓專案問題更亂更複雜。

造成這種現象的原因可能有：

1. 專業工作無法任意切割

2. 溝通成本大幅增加

3. 新人無法快速融入團隊開發

4. 舊人要暫停工作，做新人的教育訓練，需要更多時間，這些時間無法反映到實際的專案進度上

最明顯的實例，就是一個女人生小孩需要耗費 10 個月的時間，但十個女人生小孩，一樣需要 10 個月，因為這是一項專業工作，無法任意切割。

References

布魯克斯法則 - MBA智库百科

又delay了...為什麼人手增加後，專案進度反而死更慘? - Project Club 專案管理輕鬆學

專案管理你要知道事情 布魯克斯法則 ( Brook’s Law ) | lalacube

浅谈软件开发定律系列之布鲁克斯定律_柳记的技术博客_51CTO博客

阿姆達爾定律 Amdahl's Law

Amdahl's Law 是 1967 年 Amdahl 發表的論文提出的法則。

當時的命題是，在平行運算的研究領域中，一個程式可以分為可被平行運算與不能被平行運算兩個部分，當我們針對平行運算做效能提升的研究時，應該把時間跟經費做最有效率的投資，但究竟平行運算可以帶來多少效益？

\[ T = 程式以序列運算的總時間 \\ B = 程式中，無法被平行化運算的部分的運算時間 \\ T-B = 可被平行化運算的總時間 \\ N = number of Threads/CPUs \\ T = B + (T-B) \\ (T-B) 部分可被平行化，變成耗費時間 (T-B)/N \]

假設 T 為 1

\[ \text{if N=2} => T(N) = B + (T-B)/2 \\ \text{if N=3} => T(N) = B + (T-B)/3 \]

可得到程式運算的總時間

\[ T(N) = B + (T-B)/N \]

假設 T = 1, 只能序列運算的部分 B = 0.5, N = 2

\[ T(2) = 0.5 + (1-0.5)/2 \\ = 0.5+0.5/2 \\ = 0.75 \]

當 Thread/CPU 越多，就代表程式運算的總時間會減少。

---

另外有一個程式加速的指標參數

\[ Speedup = \frac{Original Execution Time}{Execution Time After Enhancement} \\ = \frac{1}{B+(1-B)/N} \]

如果程式有一半的部分可被平行化加速

\[ N=2, Speedup = \frac{1}{0.5+(1-0.5)/2} = 1.33 \\ N=4, Speedup = 1.6 \\ N=100, Speedup = 1.98 \\ N=1000, Speedup = 1.998 \\ N=10000, Speedup = 1.99998 \\ N=\infty, Speedup = 2 \]

意思就是，就算平行化運算可以無限的加強效能，減少運算時間，程式的總運算時間，會被無法平行化運算加速的部分限制住。

如果有兩件事，我們不知道應該去做哪一項時，也可以利用這個法則決定，取效益比較高的那一個。例如：讀書時不知道要先讀數學還是英文，先假設數學是無法提升的部分，算出 Speedup，再用英文為B，算出 Speedup，兩個互相比較，就可以知道哪一個效益較高。

但真實世界也不是那麼簡單的事，因為我們無法預先知道，最佳化後的成果，是不是跟預先假設的成果效益一樣。另外以讀書為例，我們也不知道一直都看不懂的英文，要花多少時間，才能改進並得到效益，反而是比較熟悉的數學還有進步空間，因為看不懂的東西，再怎麼看也不懂，就算看懂以後的效益很高也沒有用。

References

OpenMP: Amdahl's Law - YouTube

阿姆達爾定律 - 維基百科，自由的百科全書

Day27：阿姆達爾定律（Amdahl's law）——資源配置的哲學 - iT 邦幫忙::一起幫忙解決難題，拯救 IT 人的一天

Amdahl's Law · 課程筆記

阿姆达尔定律(Amdahl’s Law) 计算51CTO博客amdahl 定律

心理防衛機制 Defense Mechanism

心理防衛機制是人類的正常反應，人類在無意識中，透過心理防衛機制，減輕不能接受或可能有害的焦慮。

一個人會產生的防衛機制，跟心智成熟度有關，越原始的防衛方法，效果越差，維持的時間也會比較短。

原始的防衛機制

Denial 否認

拒絕現實發生的事情，假裝某個想法或事件沒有發生過。

Regression 退化

當承受過多壓力時，行為動作可能會回到嬰幼兒時期，像一個小孩一樣，這樣會比較有安全感

Acting Out 行動化

以極端的方式宣泄情緒，例如丟東西，搥牆壁，甚至是自殘。

Dissociation 解離

一個人失去時間感，或暫時失去人格完整性，例如在車禍後，喪失發生時那一個片段的記憶

Projection 投射

將自己無法接受的想法，賦予到別人身上，推卸責任藉此得到解脫。

Reaction Formation 反向作用

心裡想的跟實際做的完全相反，例如男生會故意捉弄喜歡的女生

稍微成熟一點的防衛機制

Repression 壓抑

遺忘造成心理創傷的事件，就不會被該事件影響

Displacement 替代

將接收到的情緒，轉移到別人身上，特別是身邊親密的人。例如工作上被責備，回家後對家人吼叫

Intellectualization 理智化作用

遇到悲傷的事，或是不如預期的事情，會想出一套說詞說服自己

Rationalization 合理化作用

用看似合理的藉口去解釋某些行為

Undoing 抵消

一個人試圖挽回下意識傷人的行為或話語

成熟的防衛機制

Sublimation 昇華

將心裡面不符合社會規範的衝動或慾望，以合於社會規則的方式表現出來。ex: 自嘲

Compensation 補償

當自己心理或生理有某些缺陷，會發展其他部分彌補這個缺陷

References

心理防衛機制是什麼？你我的潛意識都會保護自己 - Hello 醫師

心理防衛機制 - 維基百科，自由的百科全書

你心智多成熟？看你「心裡防禦機制」就知道！12種防禦機制！【心理學】 | 維思維 - YouTube

Gall’s Law

"A complex system that works is invariably found to have evolved from a simple system that worked. The inverse proposition also appears to be true: a complex system designed from scratch never works and can not be made to work. You have to start over, beginning with a simple system." - John Gall, systems theorist.

一個複雜的系統，是由簡單的系統慢慢演化而來的。如果要從無到有，設計出一個複雜的系統，是絕對不可能成功的，任何複雜的東西，都要從簡單（基本）做起。

一個外表看起來複雜的系統，如果仔細去分析內部的架構，會發現它是由很多簡單的結構組合而成的。沒有一個系統可以無中生有憑空產生。

這是系統分析要做的事情，系統分析就是要透過設計的方法，將一個完整複雜的系統，切割為多個可被容易理解的子系統/流程。但分析不能太過注意細節，系統與流程的實作細節，要交給系統設計去處理。因為一個太精細的系統分析結果，反而會讓人難以整合出整個系統全貌。

跟 Gall’s Law 類似的法則是 KISS Principle。

Keep it simple, stupid (KISS) 就是在進行系統設計時，要盡可能保持簡單。換句話說，就是不能做過度設計 over design，過度設計的系統，會因為多餘的考量，讓使用者難以理解，也會犧牲掉運作的靈活/流暢度。

另外還有一個類似的奧卡姆剃刀原則 Occam's Razor

「切勿浪費較多東西，去做『用較少的東西，同樣可以做好的事情』。」

「如無必要，勿增實體。」(Do not multiply entities beyond necessity.)

這幾個原則都有一些共同的代名詞：化繁為簡、避重趨輕、避繁逐簡、以簡御繁、避虛就實。

References

对开发人员有用的定律、理论、原则和模式 - 腾讯产业互联网学堂

KISS原則 - 維基百科，自由的百科全書

奧坎剃刀 - 維基百科，自由的百科全書

2-phase, 3-phase commit

在分散式系統，2-phase 與 3-phase commit 是用來處理多個節點的 transaction 的演算法，3PC 是解決 2PC 的缺點而設計的。

ACID

資料庫管理系統 DBMS 在寫入/更新資料時，會確保單一交易 transaction 的正確性，規定一個交易必須滿足 Atomicity, Consistency, Isolation, Durability 四個特性。

• Atomicity 原子性

  一個 transaction 裡面所有的資料操作，必須全部一起完成，或是全部一起失敗，在執行過程中如果發生任何問題，都必須 rollback 回到 transaction 一開始的狀態

• Consistency 一致性

  在 transaction 開始前，以及結束以後，資料庫要保持完整性，兩個狀態都是資料庫的某一個合法的狀態

• Isolation 隔離原則

  在多個 transaction 同時發生時，每一個 transaction 都必須各自獨立，即使對同一個資料進行異動，必須保證這幾個 transaction 之間不會互相影響，交查執行，而破壞了資料的一致性。

  隔離有不同的等級：read uncommitted, read committed, repeatable read, serializable

• Durability 持久性

  當 transaction 結束後，對資料的修改必須是永久的，即使系統發生故障異常，也不會遺失資料

2-Phase Commit

在單一資料庫時，要維持 DBMS 的 ACID 原則比較簡單，但是如果商業邏輯牽涉了多個 DBMS，例如在購物時，必須同時異動倉儲管理及出貨管理兩個系統，這兩個系統的資料庫各自獨立。為了維持 ACID 原則，兩個 DBMS 必須同時異動，或是同時失敗，倉儲管理系統減少的商品數量 = 出貨管理增加的商品數量，2-Phase Commit 就是用來在分散式系統中達到 Data Stong Consistency 的方法。

角色

1. Coordinator

   負責發起及維護 2PC 的流程，可能是 client 或 middleware，該角色不會異動到其他節點上

2. Participant

   參與交易的 DBMS 或 Storage

假設

1. 所有節點不會產生永久性破壞，異常後仍能恢復運作

2. 交易的異動動作先放在預寫式日誌上，日誌會儲存在可靠的儲存設備上，即使節點被破壞，也不會遺失日誌資料

3. 系統存在一個節點作為 coordinator，其他節點為 participants，不限制系統之間的通訊方法

方法

分為兩個 phase

Phase1 請求階段

1. coodinator 向 participants 發送 "Prepare" 詢問是否可參與交易

2. participants 執行詢問開始為止的所有 transactions，將 Undo, Redo 寫入日誌

3. participants 響應 "Prepare" 詢問，先複製一份預計被更新的資料，並回復兩種訊息

   1. "Ready"：可成功參與交易

   2. "Abort"：失敗

Phase2 執行階段

Ready

當所有 participants 都回覆 Ready 時

1. coordinator 向所有 participants 發送 "Commit"

2. participants 完成交易，釋放整個交易期間佔用的資源

3. participants 向 coordinator 發送 "Done"

4. coordinator 收到所有 participants 回送的 "Done" 完成交易

Abort

當有任一個 participant 回覆 "Abort" 時，或是 coordinator 詢問 Timeout 無法取得回覆時

1. coordinator 向所有 participants 發送 "Rollback"

2. participants 利用先前的 "Undo" 執行 rollback，釋放整個交易期間佔用的資源

3. participants 向 coordinator 發送 "Rollback Done"

4. cooridator 收到所有 participants 回送的 "Rollback Done"，取消交易

優缺點

優點：簡單，容易實作

缺點：

只有一個 coordinator，如果 coordinator 失效，則因為 participants 的同步呼叫操作，無法收到回覆而被 blocked，必須根據這種狀況另外實作 rollback 或是 abort 給 participants。

3-Phase Commit

為了解決 2PC 的問題，可使用 3PC

3PC 是一種 nonblocking 的協議。3PC 在 2PC 的第一階段與第二階段之間插入了一個準備階段，可解決在原先在 2PC 中，participant 在投票之後，由於 coordinator 發生崩潰或錯誤，而導致 participant 處於無法知曉是否提交或者中止的「不確定狀態」所產生的可能相當長的延時的問題。

3PC 將 Participants 改為 Cohorts

Phase1 CanCommit

跟 2PC 的 phase 1 一樣，coordinator 發送 "canCommit" 給所有 Cohorts。

Cohorts 收到 canCommit，如果可以執行 transaction，資料沒有被鎖定，就回覆 "Yes"，否則就回覆 "No"

Phase2 PreCommit

coordinator 根據 cohorts 的回覆，決定是否繼續

A. 所有 Cohorts 都回覆 "Yes"

傳送預提交請求，coordinator 會傳送 "PreCommit" 給 Cohorts，進入 Prepared 階段

transaction 預提交，cohorts 接收到 PreCommit，執行 transaction，並將 Undo 與 Redo 資訊記錄到事務日誌中

B. 有任一個 Cohort 回覆 "No"，或等待超時，沒有收到回覆

中斷交易，傳送中斷請求 "Abort" 給所有 cohorts

cohort 收到 "Abort" 時，或是 Timeout，就執行中斷交易

Phase3 DoCommit

進行真正的交易內容，分兩種情況

A. 執行提交

1. 傳送提交請求

   coordinator 收到 cohort 的 "Ack"，就會將預提交狀態改為提交狀態，並向所有 cohorts 傳送 "doCommit"

2. 提交交易

   cohort 收到 "doCommit" 後，執行交易提交，並在交易完成後，釋放所有交易資源

3. 響應回饋

   提交交易後，繪像 coodinator 發送 "Ack"

4. 完成交易

   coordinator 收到所有 cohorts 的 Ack 後，完成交易

B. 中斷交易 transaction

coordinator 沒有收到 Ack (可能收到的不是 ack 或是 timeout)，就會中斷交易

差異

在 2PC 只有 coordinator 有 timeout 機制，在 3PC，coordinator 與 cohort 都有 timeout 機制

PreCommit 是一個緩衝機制，確保最後提交階段前，各參與節點的狀態是一致的

缺點

進入 PreCommit 後，coordinator 發出 Abort，假設只有一個 cohort 收到並執行 abort，其他對於系統狀態未知的 cohort 會根據 3PC 選擇繼續 Commit，系統會進入狀態不一致的情況

Refereneces

二階段提交 - 維基百科，自由的百科全書

三階段提交 - 維基百科，自由的百科全書

Day 11 - 共識演算法 - 2 Phase Commitment (2PC) - iT 邦幫忙::一起幫忙解決難題，拯救 IT 人的一天

Day 12 - 共識演算法 - 3 Phase Commitment (3PC) - iT 邦幫忙::一起幫忙解決難題，拯救 IT 人的一天

Two Phase Commit

三階段提交（Three-phase commit） | 程式前沿

Saga Pattern in Micro-service Architecture

saga 在 1987 年由 Hector Garcaa-Molrna Kenneth Salem 兩個人提出，是一種分散式交易架構，可在 micro-services 之間，提供跨service 的交易操作，以保障資料一致性。saga 是用一連串的交易方法，更新每一個服務並發布訊息觸發下一個交易，如果有某一個交易失敗，則進行補償。

saga 主要有 Choreography 及 Orchestration 兩種運作機制。

Choreography

沒有中央協調的角色，由每個服務執行完後主動發出狀態或是呼叫下一個服務。

Saga 模式會使用一連串的本機交易 (local transaction) 實作交易管理。 本機交易是 Saga 參與者所執行的不可部分完成工作工作。每個本機交易都會更新自己的資料庫，同時發布訊息或事件，觸發 saga 中的下一個本機交易。如果本機交易失敗，saga 會執行一系列 補償交易 ，以復原先前本機交易所做的變更。

這個方法的優點是個服務之間的資訊交換方法簡單容易理解，但如果某一個流程中間牽涉的微服務數量太多，就會讓架構變得複雜混亂。因為服務提供者的角色數量增加，導致每個服務都需要一個訊息通道，利用 publish-subscribe 機制，處理訊息交換的問題，但 subcriber 也可能發生意外，導致訊息沒有被處理的例外狀況發生。

Orchestration

有一個交易管理中心，掌管整個商業邏輯，知道如何呼叫微服務，處理整個流程，呼叫下一個服務，並在服務發生問題時，處理補償機制。所有服務都會跟這個中央集權式的交易管理中心溝通。

優點是 Choreography 服務之間的依賴度低，降低複雜度，比較容易處理 rollback，缺點是 Orchestration 實作本身會很複雜。

References

https://medium.com/skyler-record/微服務架的資料一致性-1-saga-pattern-cf05aed1307b

微服務瞎談(7) Saga Pattern - iT 邦幫忙::一起幫忙解決難題，拯救 IT 人的一天

Saga 模式 - Azure Design Patterns | Microsoft Docs

Patterns in Event Driven Architecture

Sagas