iT邦幫忙

1

有誰能夠解釋清楚 Hyrum's Law ?

最近在讀書讀到 Hyrum's Law
https://www.hyrumslaw.com/

但在看中文翻譯或者自己去理解英文的時候都有點不是很清楚?

請問有人可以用舉例例子說明嗎?

看更多先前的討論...收起先前的討論...
yesongow iT邦大師 1 級 ‧ 2021-01-25 21:23:04 檢舉
問律師,5000/hr
fillano iT邦超人 1 級 ‧ 2021-01-25 23:10:51 檢舉
哪些點不懂?
微笑 iT邦新手 1 級 ‧ 2021-01-26 09:36:37 檢舉
不如樓主先說說自己的看法吧
跟民調一樣啊,沒有足夠的母數,要如何使人信服
但有足夠的母數滿足目前的設計,任何的設計變更都會造成母數的反感
簡單說鄉愿的力量是很大的
r567tw iT邦研究生 5 級 ‧ 2021-01-27 00:32:18 檢舉
我的理解不知道這樣對不對? 如果API 使用者變多,有可能因為抽象洩漏的狀況或文件沒有講清楚,而導致之後的變更可能窒礙難行? 是這樣嗎? 但對於我們開發API 有什麼啟發? 文件要寫清楚嗎? 還是我們需要仔細的規劃小心處理,以確保我們都有處理到每一種情形嗎?
圖片
  直播研討會
圖片
{{ item.channelVendor }} {{ item.webinarstarted }} |
{{ formatDate(item.duration) }}
直播中
2
EN
iT邦好手 1 級 ‧ 2021-01-26 09:08:48

這篇寫的蠻清楚的!

r567tw iT邦研究生 5 級 ‧ 2021-01-27 00:34:39 檢舉

這篇有看過。但不知道是不是因為大陸用語所以不是很清楚,也不知道自己的理解到底對不對? 難道API使用者變多不是一件好事嗎?這對我們設計API會有怎麼樣的啟發?

0

我用比較白話的說法。

接近於防呆理論及合理化條件。
雖然我說的很簡單。

實際上來說,這個定律要講的是一種很深遠的函義。
它還包含了習慣性及廣泛性。

這不止在it界上,商場及工廠內。都有其定律存在而不自知。

這個定律來說,我個人認為比較偏向精神面或人格主觀意識的說法。
如「自主性加班」「正職責任制」...等等。
都可以看到這些定律的影子存在。

總之...它就只是一種定律學說。就程式界而言來說。
我會比較偏向於防呆機制的應用說法。
用在資料庫的條件上。你不可能有 where id=1 AND id=2
這樣的用法。這我們一看就知道,再id是唯一值的情況下。
這樣的條件保証拿不到任何資料。
所以,你在設計上會變成理所當然的id條件得要唯一性。
而這個「理所當然」。就是這個定律要說明的意思。

r567tw iT邦研究生 5 級 ‧ 2021-01-27 00:37:37 檢舉

謝謝你的回答,但我剛剛看官網好像他指的是一種軟體工程的觀察現象,感覺與你說的防呆機制好像有點不太一樣?意思是藉著這個定律的觀察,對我們API的開發就需要更強的防呆嗎?可以這樣理解嗎?

防呆的方式,只是這個定律中的其一而已。
我只是拿它來當一個解釋。

api的寫法搭配這個定律。就得規劃好使用的參數為何。
而如何去規範這個參數。就需要觀察實際應用。並符合定律的使用方式

2
yesiah
iT邦見習生 ‧ 2022-02-22 19:50:24

雖然是一年前的文,可能原po已經不在乎了,還是來說說我的看法xDDD

先貼官網的 TL;DR

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 有足夠多的使用者
不論你在文件中如何解釋
所有可見的行為
終將被某個人所依賴


聽起來有點抽象
舉個例子

假如需要實作一個 debug printer,用來把簡單 struct 內部的值都印出來
於是你寫了一個函數

/// Print all values in `SomeStruct`, separated by comma.
void DebugPrint (SomeStruct ss) {
    const char* delimiter = ", ";
    // print
}

內容很簡單,就是把所有值印出來
並用一個逗號 + 一個半形空白來分隔

一開始大家都用得很愉快
漸漸地,DebugPrint 變得越來越多人用,因為它簡單又方便

有一天你突然想要把半形空白刪掉
簡單,30 秒完成
2 分鐘後卻有數十個人來抱怨說程式碼出錯了

這就是 Hyrum's Law 在講的問題

程式碼中清楚寫了分隔符號就是 ", ",這就產生了一個 observable behavior
即便作者從來沒有保證過不會更改分隔符號,甚至隻字未提半形空白
一定有一個人,或數十個人,會假設 DebugPrint 的分隔符號就是 ", "
而他們的程式碼,更可能會建立在這個假設之上實作

一但半形空白被刪掉,只剩下 ",",這些程式碼就會出錯

此時的唯二解,就是 1. 修正所有程式碼,或是 2. 把半形空白加回去,並永遠不再變更


而最好的方法,是從一開始實作的時候就避免這個問題
也就是不要使用固定數量的空白
如此一來可以確保使用者的程式碼不依賴半型空白的個數
又同時不違背註解

/// Print all values in `SomeStruct`, separated by comma.
void DebugPrint (SomeStruct ss) {
    bool jitter = ...; // some randomized boolean variable
    const char* delimiter = jitter ? ", " : ",  ";
    // print
}
r567tw iT邦研究生 5 級 ‧ 2022-03-17 14:42:26 檢舉

你的例子與解釋非常容易清楚明瞭,對這個又更加理解了

我大概之前的理解是大概得出設計API時要小心,避免做出隨隨便便的變更決定等等

只能說設計API其實也是個專業,看起來簡單的東西其實要鑽出很深的東西也可以很多很多。感謝~~

0
samlin001
iT邦見習生 ‧ 2022-06-27 16:17:23

簡單的說, 越多人用你的API, 越高機率程式依賴它的可觀測行為,即使該行為不在API的定義中.

例子:終會有程式依靠一個hash funtion傳回的固定序列順續. 即使hash function從未承諾傳回特定順續.

我要發表回答

立即登入回答