Doppler Radar

都卜勒效應 波源和觀察者有相對運動時，觀察者接受到波的頻率與波源發出的頻率並不相同的現象。這一現象最初由奧地利物理學家都卜勒於1842年發現。

物體的相對運動會引起頻率的增大或減小。當物體和波源相背離時時，波長會增大，頻率會降低，稱為都卜勒紅移，當物體和波源相向運動時，波長減小，頻率增大，稱為都卜勒藍移，根據探測到的都卜勒頻移 f′ 可以計算出物體的速度。

在馬路上，最常遇到的是消防車與救護車的警報，我們通常會發現，當車子往我們的方向靠近跟遠離時，我們聽到的警報聲音是不一樣的，而且一直在改變。

都卜勒雷達 Doppler radar 是利用都卜勒效應測量物體在雷達波束方向上的路徑運動速度的一種雷達。常用於氣象觀測。

為了檢查心臟、血管的運動狀態，了解血液流動速度，可以通過發射超聲來實現。超聲振盪器產生一種高頻的等幅超聲信號，激勵發射換能器探頭，產生連續不斷的超音波，向人體心血管器官發射，當超音波束遇到運動的臟器和血管時，便產生都卜勒效應，就可以根據反射波與發射的頻率差異求出血流速度，根據反射波以頻率是增大還是減小判定血流方向。

交通警察取締超速行車所使用的雷達槍也是都卜勒雷達的一種。交通警察向行進中的車輛發射頻率已知的超音波同時測量反射波的頻率，根據反射波的頻率變化的多少就能知道車輛的速度。裝有都卜勒測速儀的監視器有時就裝在路的上方，在測速的同時把車輛牌號拍攝下來，並把測得的速度自動列印在照片上。

References

都卜勒雷達 - 維基百科，自由的百科全書

杜卜勒超音波(Doppler ultrasound) - 小小整理網站 Smallcollation

多普勒效應 Doppler Effect

抽象洩漏定律 (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