軟件開發定律：海勒姆定律（Hyrum's Law）

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

在軟件開發中，你是否遇到過這種情況：

你正在開發一個購物車的功能，需要在用戶添加商品到購物車時，將商品的信息存儲到數據庫中。你設計了一個簡單的方法，如下所示：

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

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

如果你只是假設操作總是會成功，並且沒有考慮到錯誤情況，那麼你就會遇到海勒姆定律的問題。

什麼是海勒姆定律呢？其有什麼意義和啓示呢，下面我們來具體看一下吧。

什麼是海勒姆定律

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

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

換句話說，即使一個 API 已經被定義和文檔化了，但由於實現的方式可能存在多種選擇，所以你在使用這個 API 的時候也要考慮到其實現的細節，而不僅僅是其所聲明的功能。

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

Hyrum Wright強調了開發者應該更加註意 API 的實現細節，因爲這些細節可能會影響到你的代碼在未來的可維護性和穩定性。

海勒姆定的意義

海勒姆定律（Hyrum's Law）是一條關於軟件開發中 API 使用的規律。其意義在於以下3點：

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

然而，API 的實現方式和細節可能會對代碼的行爲產生影響，甚至可能導致不可預料的問題。海勒姆定律強調了這一點，提醒開發人員在使用 API 時需要仔細評估其實現細節和穩定性，以避免出現潛在的問題，提高代碼的可維護性和穩定性。

此外，海勒姆定律還強調了軟件開發的迭代性和變化性。隨着軟件需求和技術環境的不斷變化，API 的實現方式也可能隨之發生變化。因此，及時瞭解並適應 API 的變化，對於保持軟件的可維護性和穩定性也非常重要。

一個常見的案例

一個經典的海勒姆定律案例是在多線程環境下使用 Java 的 ArrayList，具體表現爲對 ArrayList 的併發修改可能會導致線程安全問題。

下面是一個簡單的 Java 代碼的示例，演示了對 ArrayList 的併發修改可能導致的線程安全問題：

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());
    }
}

在這個示例中，我們創建了一個固定大小的線程池，然後啓動 1000 個線程，每個線程都向 ArrayList 中添加一個整數。最後，我們打印 ArrayList 的大小。

在單線程環境下，這段代碼可以正常工作，輸出的結果應該爲 1000。然而，在多線程環境下，由於 ArrayList 不是線程安全的，可能會出現併發修改問題，導致結果不確定，例如輸出的結果可能小於 1000。

要解決這個問題，我們可以使用線程安全的 List 實現，例如使用 Java 的 Vector 或者 Collections.synchronizedList 方法來包裝 ArrayList，以保證併發修改時的線程安全性。

海勒姆定律的實踐建議

以下是一些有助於在實踐中落實海勒姆定律的建議：

• 瞭解 API 的文檔和規範。 在使用 API 之前，應該先仔細閱讀相關文檔和規範，瞭解 API 的功能、用法、限制和可能的問題。

• 編寫健壯的代碼。 在使用 API 時，應該編寫健壯的代碼，考慮到各種可能的錯誤和異常情況，以保證代碼的可靠性和穩定性。

• 使用穩定的 API 版本。 如果有多個版本的 API 可以選擇，應該儘量選擇穩定的版本，並儘量避免使用過時或廢棄的版本。

• 進行集成和單元測試。 在使用 API 時，應該編寫集成測試和單元測試，驗證 API 的正確性和穩定性，並及時修復可能出現的問題。

• 注意 API 的依賴關係。 在使用 API 時，應該注意其依賴關係，避免引入不必要的依賴，同時也要確保其依賴的組件或庫是可靠的和穩定的。

• 及時處理 API 的變更。 隨着軟件需求和技術環境的變化，API 的實現方式也可能隨之發生變化。在使用 API 時，應該及時瞭解並適應 API 的變更，以保持軟件的可維護性和穩定性。

綜上所述，在通過遵循這些實踐建議，可以更好地落實海勒姆定律，提高代碼的可維護性和穩定性，同時也能夠更好地適應軟件開發過程中的變化和創新。

海勒姆定律的反模式

除了常見的實踐建議外，以下是一些常見的反模式，這些做法不利於落實海勒姆定律：

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

• 忽略 API 的限制和異常。 有些開發人員可能會忽略 API 的限制和異常情況，而直接假定 API 總是能夠正常工作。這種做法會增加代碼的不確定性和出錯概率，導致代碼的不可靠性和難以維護性。

• 直接使用底層庫或組件。 有些開發人員可能會直接使用底層庫或組件，而忽略了 API 的規範和封裝。這種做法會使代碼與底層實現緊密耦合，增加了代碼的複雜性和難以維護性。

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

• 不合理地添加或刪除依賴。 有些開發人員可能會不合理地添加或刪除依賴，而忽略了 API 的依賴關係和穩定性。這種做法會使代碼的依賴關係變得混亂和不可控，增加了代碼的複雜性和難以維護性。

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

最後

海勒姆定律是一個非常重要的原則。其告訴我們，在處理複雜系統時，我們不能只關注系統的主要功能，還需要考慮系統中的各種依賴關係和副作用。

如果我們只是假設一切都是正確的，並沒有考慮到系統的各種依賴關係和副作用，那麼就會遇到各種意外和問題，這可能會導致系統崩潰或出現其他嚴重問題。

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

總之，海勒姆定律的重要性不能被忽視。對於開發人員來說，瞭解這個原則，並在實踐中應用它，將有助於提高代碼的質量和穩定性，從而爲用戶提供更好的體驗。

---

閱讀，思考，練習，分享，日日不斷之功。

嗯，寫完了。

新的一天，加油哦 (ง •̀_•́)ง