軟體開發定律:海勒姆定律(Hyrum's Law)

2023-04-04 09:00:31

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

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

最後

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

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

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

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


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

嗯,寫完了。

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