[[397738]]

大家好，我是站長 polarisxu。

對開發(fā)人員來說，其實也是有不少定律或原則的，只是很多人可能經歷了，但不知道原來是這么個定律。

「內卷」這個詞很流行，幾乎滲透到每一個角落：

• 幼兒園小朋友都學一年級知識了，你家的不學，一年級跟不上。。。
• 小學生就各種課外輔導班，你不報班，也沒人一起玩，讓他看電子產品?
• 面試造火箭，工作擰螺絲的現象更加嚴重。。。
• 公眾號各種卷：標題、內容等，卷王之王都出現了。。。
• 。。。

想起一個段子：「面試滴滴司機」，對話過程大概是這樣的。(來源網絡，如有雷同，純屬巧合)

看你簡歷，你已經有八年的開車經驗，咱們聊一聊從你按下汽車點火按鈕后，汽車發(fā)生的一系列的動作。

答：

1)按下按鈕后0.5秒，車輛完成電路自檢。2)按下1秒后，啟動機馬達的電路被接通，帶動馬達高速運轉，馬達轉子帶動發(fā)動機飛輪運動，汽車發(fā)動機在轟鳴聲中啟動。3)油門踏板控制著發(fā)動機進氣門(亦稱作節(jié)氣門)的開合角度。油門踩得越深，進氣門開合角度就越大，進氣量也就越大。4)然后，火花塞適時點火，引燃可燃氣形成“爆燃”，巨大的沖擊力使得活塞進行運動。每分鐘這樣的“爆燃”會發(fā)生幾百上千次。活塞的運動帶動發(fā)動機曲軸飛速旋轉。發(fā)動機轉速的，就是每分鐘內曲軸旋轉的圈數。5)氣缸活塞在封閉爆燃的推動下往復運動，產生連續(xù)不斷的動力。

至此，發(fā)動機順利完成啟動，掛好檔位踩油門，轉速和車速逐步攀升，我們可以出發(fā)啦!

面試官接著問：

嗯，那有在之前的工作中，做過啟動優(yōu)化嗎?盡量減少發(fā)動的時間，提高用戶體驗。

。。。

是不是卷的飛起?!

01 海勒姆定律

在程序設計中，接口和實現是很重要的兩部分。通常在一個系統(tǒng)里面，接口就是一個與系統(tǒng)交互的抽象，比如汽車的方向盤和油門，剎車這些(我們通過這些來控制汽車，與汽車交互)，而實現則是這個系統(tǒng)工作的一種方式，比如汽車的輪子和引擎(汽車實際是通過這些來工作的)。區(qū)分接口和實現的好處是非常明顯的，當一個系統(tǒng)快速迭代，變得越來越復雜和難以理解的時候，抽象能非常好的幫助我們管理這些復雜性。

可見，一個接口在理論上需要清晰的將系統(tǒng)的使用者和該系統(tǒng)的實現隔離開。汽車系統(tǒng)是如此，其他系統(tǒng)也是如此。雖然設計者很努力，但現實往往是殘酷的，當這個系統(tǒng)開始逐漸膨脹，一些用戶開始依賴一些通過接口暴露出的內部的實現細節(jié)，「內卷」開始。。。

幾年前，Google 的一名工程師，Hyrum(海勒姆)觀察指出：

當 API 有足夠多的用戶時，你在合同中的承諾已不重要：你系統(tǒng)的所有可觀察行為都將被某些人所依賴。

這也叫做「隱式接口定律」。

也就是說，當你的 API 有足夠多的用戶時，API 的所有行為(包括那些未囊括在公共說明中的一部分)最終都會被其他人所依賴。一個簡單的例子是 API 的響應時間這種非功能性因素;還有一個更微妙的例子是：用戶使用正則表達式匹配錯誤提示來判斷 API 的錯誤類型，即使 API 文檔中沒有任何關于錯誤提示的內容，而是指導用戶應該使用相應的錯誤代碼。一些用戶依然會使用錯誤提示內容(而非錯誤代碼)，這種情況下變更 API 錯誤提示信息，實際上會破壞 API 的使用。

俗稱：不按套路出牌。

02 該定律在 Go 中的體現

隨著使用 Go 的人越來越多，大家超越 Go 規(guī)范，不滿足于 Go 公開的 API，「卷入」其內部實現了。你會寫 Go 代碼，寫過大型項目可能都不夠，你必須得符合「海勒姆定律」，挖挖 GMP、GC 等 runtime 很多實現細節(jié)。

雖然 Go 官方一直在避免大家陷入實現細節(jié)，依賴實現細節(jié)，但還是擋不住「愛學習」的人們。比如 Go 中的 map 是無序的，但某個版本的實現，用戶測試輸出，咦，發(fā)現是有序的。。。然后依賴它。Go 官方「一怒之下」，故意打亂順序。

再比如一個包中多個文件的初始化順序，規(guī)范并沒有進行約定。但目前官方的實現是按照文件名順序初始化的，于是很可能就有面試題，并且多半答案就說是文件名順序，因為現在是這么實現的，源碼在那擺著呢。。。

再比如，Go 中 slice 的擴容，太多太多文章解釋，擴容的規(guī)則是怎么樣的，1.5 倍?2 倍?規(guī)范并沒有對此做約定。而且 Go 不同版本的實現還經常變。用好 slice 貌似基本不能滿足要求，你必須得知道它怎么擴容的，每次擴容增加多少?這跟開車需要知道發(fā)動機原理似乎沒啥區(qū)別~

還有很多很多例子，歡迎留言!

03 對我們有何啟發(fā)

在實際工作中，我們一方面要盡量設計好接口，將接口和實現隔離，但同時也要留意隱式接口問題。特別是對外提供服務(包括公司的基礎部門，對其他部門提供服務)，要求我們在構建和維護復雜系統(tǒng)的時候思考的更全面一點。我們需要意識到，隱示接口會限制我們系統(tǒng)的設計和發(fā)展。雖然隱式接口理論上不是你的鍋，但使用者不會這么認為。

所以，「卷」有了理論依據。谷歌很多年前就用理論證明了「卷」的普遍存在，卷的有理有據，你還能不倦嗎???

04 參考

海勒姆定律：https://www.hyrumslaw.com/

本文轉載自微信公眾號「polarisxu」，可以通過以下二維碼關注。轉載本文請聯(lián)系polarisxu公眾號。