hi，我是熵減，見字如面。

在軟件開(kai)發中(zhong)，你是否(fou)遇到(dao)過這種情況：

你正在(zai)開發一(yi)個(ge)(ge)購物(wu)車的(de)功(gong)能，需要(yao)在(zai)用戶添加(jia)商(shang)品到購物(wu)車時，將商(shang)品的(de)信息存(cun)儲到數據庫(ku)中。你設計(ji)了一(yi)個(ge)(ge)簡單的(de)方法，如下所示(shi)：

public void addToCart(Item item) {
    // 將商品信息存儲到數據庫中
}

在(zai)這(zhe)個方法(fa)中，你假設了將商品信(xin)息(xi)存儲到數據(ju)庫的操作總是會成功，而(er)沒有考慮到可(ke)能會出現任何錯(cuo)誤(wu)。然而(er)，在(zai)實際(ji)情況中，可(ke)能會發生各(ge)種錯(cuo)誤(wu)，例如(ru)數據(ju)庫連接失敗、寫入失敗、數據(ju)格式不正(zheng)確等(deng)。

如(ru)果你只是(shi)假(jia)設操作總(zong)是(shi)會成功，并且(qie)沒(mei)有(you)考慮到錯誤情況，那么你就會遇到海勒姆定(ding)律的問題。

什么是海勒姆(mu)定律呢(ni)？其(qi)有什么意義和啟示(shi)呢(ni)，下面我(wo)們來具體(ti)看一下吧。

什么是海勒姆定律

海勒姆定律（Hyrum's Law）是(shi)一(yi)個軟件(jian)開(kai)發中的概念，它指的是(shi)：

“當你依賴于一個 API 的時候，你實際上也依賴于這個 API 的實現細節。”

換(huan)句話說，即使(shi)一個 API 已(yi)經被定義和文檔化了(le)，但由于實現(xian)的(de)方(fang)式可能存在(zai)多種(zhong)選(xuan)擇(ze)，所(suo)以你(ni)在(zai)使(shi)用這個 API 的(de)時候也要考(kao)慮到其(qi)實現(xian)的(de)細(xi)節，而不僅僅是其(qi)所(suo)聲明的(de)功能。

海勒姆定律得名于 Google 工程師 Hyrum Wright，他(ta)在一次演講中提出了這個概念。

Hyrum Wright強調了開(kai)發者應該更(geng)加注意(yi) API 的(de)實(shi)現細(xi)節(jie)，因為這些細(xi)節(jie)可能會影響到(dao)你的(de)代(dai)碼在未(wei)來的(de)可維護性(xing)和穩定性(xing)。

海勒姆定的意義

海勒(le)姆定律(lv)（Hyrum's Law）是(shi)一條關于(yu)軟件開發中 API 使用的(de)規(gui)律(lv)。其(qi)意義在于(yu)以下3點(dian)：

海勒姆(mu)定律的意義在于提醒開(kai)發(fa)人員，當使用 API 時不僅要考慮其功能，還要了解其實現細(xi)節和限制(zhi)。在軟件開(kai)發(fa)過程中，API 是非常常見的工具，它們可以幫助我(wo)們快(kuai)速(su)實現功能，提高開(kai)發(fa)效率。

然而(er)，API 的(de)實(shi)(shi)現方式和(he)細節(jie)可(ke)能(neng)會對代(dai)碼的(de)行(xing)為產生影響，甚至可(ke)能(neng)導致不可(ke)預料的(de)問(wen)題。海勒姆定(ding)律強調(diao)了這一點，提(ti)醒開發人員在(zai)使用 API 時需要仔細評估其實(shi)(shi)現細節(jie)和(he)穩定(ding)性，以避免出現潛(qian)在(zai)的(de)問(wen)題，提(ti)高代(dai)碼的(de)可(ke)維護性和(he)穩定(ding)性。

此外，海勒姆定律(lv)還強調(diao)了(le)軟(ruan)件(jian)開發的迭代性(xing)(xing)和變化性(xing)(xing)。隨著軟(ruan)件(jian)需求和技術環境的不斷變化，API 的實(shi)現方式也可(ke)能(neng)隨之(zhi)發生變化。因此，及時了(le)解(jie)并適(shi)應 API 的變化，對于(yu)保持軟(ruan)件(jian)的可(ke)維護性(xing)(xing)和穩定性(xing)(xing)也非常重要(yao)。

一個常見的案例

一個經典(dian)的(de)海勒姆定律案例是在多線程環境下使用 Java 的(de) ArrayList，具體表現為(wei)對 ArrayList 的(de)并發修(xiu)改可能會(hui)導致線程安全問(wen)題。

下面(mian)是(shi)一個(ge)簡單的 Java 代(dai)碼的示例，演示了對 ArrayList 的并(bing)發修改(gai)可能導(dao)致的線程安全問題：

import java.util.ArrayList;
import java.util.List;
import java.util.concurrent.ExecutorService;
import java.util.concurrent.Executors;

public class ArrayListConcurrencyExample {
    private static List<Integer> list = new ArrayList<>();

    public static void main(String[] args) {
        ExecutorService executorService = Executors.newFixedThreadPool(10);
        for (int i = 0; i < 1000; i++) {
            executorService.submit(() -> list.add(1));
        }
        executorService.shutdown();
        while (!executorService.isTerminated()) { }

        System.out.println("Size of list: " + list.size());
    }
}

在這個(ge)示例中，我們(men)創建了一個(ge)固定大小(xiao)的線程池(chi)，然后啟(qi)動 1000 個(ge)線程，每個(ge)線程都向 ArrayList 中添加(jia)一個(ge)整數。最后，我們(men)打印 ArrayList 的大小(xiao)。

在單線程環境(jing)下(xia)，這段代(dai)碼可(ke)(ke)以(yi)正常工(gong)作，輸(shu)出(chu)的(de)結(jie)果(guo)(guo)應該為 1000。然而，在多線程環境(jing)下(xia)，由于 ArrayList 不是(shi)線程安全的(de)，可(ke)(ke)能會出(chu)現并發修改(gai)問題，導致結(jie)果(guo)(guo)不確定(ding)，例如(ru)輸(shu)出(chu)的(de)結(jie)果(guo)(guo)可(ke)(ke)能小于 1000。

要解決這個問題，我們可以(yi)使用(yong)線程安全(quan)的(de) List 實(shi)現，例(li)如使用(yong) Java 的(de) Vector 或者 Collections.synchronizedList 方法來(lai)包裝 ArrayList，以(yi)保證并發修(xiu)改時的(de)線程安全(quan)性。

海勒姆定律的實踐建議

以下是(shi)一些有助于在實踐中落(luo)實海勒姆(mu)定(ding)律的建(jian)議：

• 了解 API 的文檔和規范。 在使用 API 之前，應(ying)該(gai)先(xian)仔細(xi)閱讀(du)相關文(wen)檔和規范，了解 API 的功能、用法(fa)、限制和可能的問題(ti)。

• 編寫健壯的代碼。 在使用 API 時，應該編寫健壯的(de)代碼，考慮到各種(zhong)可(ke)能的(de)錯誤和(he)異(yi)常情況(kuang)，以保證(zheng)代碼的(de)可(ke)靠性(xing)和(he)穩定性(xing)。

• 使用穩定的 API 版本。 如果有多(duo)個版本(ben)的 API 可以選擇(ze)，應(ying)該盡(jin)量(liang)選擇(ze)穩定(ding)的版本(ben)，并盡(jin)量(liang)避(bi)免使用過(guo)時或廢棄的版本(ben)。

• 進行集成和單元測試。 在(zai)使用(yong) API 時，應該編(bian)寫集(ji)成測(ce)試(shi)和單元測(ce)試(shi)，驗證 API 的正(zheng)確性(xing)和穩定性(xing)，并(bing)及時修復(fu)可(ke)能出現的問題。

• 注意 API 的依賴關系。 在(zai)使用 API 時(shi)，應該注意(yi)其依(yi)(yi)賴(lai)(lai)關系(xi)，避免引入不必要的(de)依(yi)(yi)賴(lai)(lai)，同時(shi)也要確保其依(yi)(yi)賴(lai)(lai)的(de)組(zu)件或庫是可靠的(de)和穩定(ding)的(de)。

• 及時處理 API 的變更。 隨著軟(ruan)件需求和(he)技術環(huan)境的(de)變化，API 的(de)實現(xian)方(fang)式(shi)也可能隨之(zhi)發(fa)生變化。在(zai)使用 API 時，應該及(ji)時了解(jie)并適應 API 的(de)變更，以保持軟(ruan)件的(de)可維護(hu)性和(he)穩定性。

綜上所述，在通過(guo)(guo)遵循這些實(shi)踐建議，可(ke)以更(geng)好(hao)地(di)落實(shi)海勒(le)姆定(ding)律，提高代(dai)碼的可(ke)維護性和(he)穩定(ding)性，同(tong)時也(ye)能夠(gou)更(geng)好(hao)地(di)適應軟件(jian)開發過(guo)(guo)程中(zhong)的變化和(he)創(chuang)新(xin)。

海勒姆定律的反模式

除了(le)常見的實(shi)踐(jian)建(jian)議外，以下是一些常見的反模式(shi)，這些做法不(bu)利于(yu)落實(shi)海勒姆(mu)定律：

• 直接依賴具體實現。 有些開發人員可能會直接依賴具體實(shi)現，而(er)忽略了(le) API 的(de)規范(fan)和(he)(he)約定。這種(zhong)做法會使代碼與實(shi)現緊密耦合(he)，增加了(le)代碼的(de)脆弱性和(he)(he)難以(yi)維護性。

• 忽略 API 的限制和異常。 有些開發人(ren)員可(ke)(ke)能(neng)會(hui)忽(hu)略 API 的(de)限制和(he)異常(chang)情況，而(er)直接假定 API 總是能(neng)夠正(zheng)常(chang)工(gong)作(zuo)。這(zhe)種做法會(hui)增加(jia)代(dai)碼的(de)不確定性(xing)和(he)出(chu)錯概率，導致代(dai)碼的(de)不可(ke)(ke)靠性(xing)和(he)難以(yi)維護性(xing)。

• 直接使用底層庫或組件。 有些開發人員(yuan)可(ke)能會(hui)直接使用底層(ceng)庫或(huo)組(zu)件，而忽(hu)略了 API 的規范和(he)封裝。這(zhe)種做法會(hui)使代(dai)(dai)碼與底層(ceng)實現緊密耦合，增加了代(dai)(dai)碼的復(fu)雜性(xing)和(he)難以(yi)維護性(xing)。

• 忽略 API 的版本變更。 有些開發人員可能會(hui)忽略 API 的版本變更，而(er)仍然使(shi)用過時(shi)(shi)或(huo)廢棄的版本。這種做(zuo)法會(hui)增加代(dai)碼的不兼(jian)容性(xing)和難(nan)以維護性(xing)，同時(shi)(shi)也會(hui)使(shi)代(dai)碼與技術發展脫節(jie)。

• 不合理地添加或刪除依賴。 有些(xie)開發人員可能(neng)會不(bu)合理地添加或刪除(chu)依(yi)賴，而忽略了(le) API 的(de)依(yi)賴關(guan)(guan)系(xi)和(he)穩定性。這種做法會使代碼的(de)依(yi)賴關(guan)(guan)系(xi)變得混亂和(he)不(bu)可控，增加了(le)代碼的(de)復雜性和(he)難以(yi)維護性。

綜上所述，避免這(zhe)些常見的(de)(de)反模式，能夠更好地落實海(hai)勒姆定律，提高代碼的(de)(de)可維護性和穩定性，同時也能夠更好地適應軟件開發過程(cheng)中的(de)(de)變化和創新(xin)。

最后

海勒姆定律是一個非常重要(yao)的(de)原則。其(qi)告訴我(wo)們，在處(chu)理復雜系(xi)(xi)統時，我(wo)們不能(neng)只(zhi)關注系(xi)(xi)統的(de)主要(yao)功能(neng)，還需要(yao)考(kao)慮系(xi)(xi)統中(zhong)的(de)各種(zhong)依賴關系(xi)(xi)和副(fu)作用。

如果我(wo)們只是(shi)假(jia)設一切都(dou)是(shi)正確的(de)，并沒有考慮到系統(tong)的(de)各(ge)種依賴關系和副作用(yong)，那么就會遇到各(ge)種意外和問(wen)題，這可能會導(dao)致系統(tong)崩(beng)潰或出(chu)現其他嚴(yan)重問(wen)題。

在編寫(xie)代碼(ma)時(shi)，我們應該注意避免海勒姆定律(lv)的陷阱，并考慮使用一些(xie)最佳實踐來(lai)確保代碼(ma)的穩定性和可靠性。

總之，海(hai)勒姆定律(lv)的(de)重(zhong)要性不能被忽視。對于(yu)開發人員來說(shuo)，了解這(zhe)個(ge)原則(ze)，并在實踐中應用它，將有助于(yu)提高代碼(ma)的(de)質量和穩定性，從(cong)而(er)為用戶提供(gong)更好的(de)體(ti)驗。

閱(yue)讀，思考，練習，分享，日日不(bu)斷之功。

嗯，寫完了。

新的一天，加油(you)哦 (? ??_??)?