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

peida發表於2023-04-04

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 的依賴關係和穩定性。這種做法會使程式碼的依賴關係變得混亂和不可控，增加了程式碼的複雜性和難以維護性。

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

最後

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

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

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

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

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

嗯，寫完了。

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

相關文章