元件化開發與黑箱

weixin_34377065發表於2019-01-16
元件化

寫於 2017.07.28

終於完成了公司的一個大project，這期間的收穫也非常多，對於“元件化開發”有了更深一層的心得體會。

在如今的前端開發中，“元件化”已經成為了一種流行，隨之而來的各種開發框架更是把這一概念發揚光大。但是概念歸概念，真正的“元件化”實踐還是有許多值得探討的地方，其中“黑箱”是我認為最具有代表性的實踐方式。今天就讓我們拋開具體的框架，直接來談一談“元件化開發”與“黑箱”。

一、元件化

元件化開發與黑箱

首先引用維基百科的一段介紹：

基於元件的軟體工程（Component-based software engineering，簡稱CBSE）或基於元件的開發（Component-Based Development，簡稱CBD）是一種軟體開發範型。它是現今軟體複用理論實用化的研究熱點，在元件物件模型的支援下，通過複用已有的構件，軟體開發者可以“即插即用”地快速構造應用軟體。這樣不僅可以節省時間和經費，提高工作效率，而且可以產生更加規範、更加可靠的應用軟體。

在業務的開發中，我們往往會把一些需要複用的部分抽取出來單獨封裝，在需要的時候再引入使用。這樣就相當於把這可複用的部分進行了“元件化”。元件化的操作能夠大大減少開發量，同時一個好的元件也能有效提升穩定性。在現代化的web開發中，“元件”通常包含了邏輯功能和樣式，各種各樣的UI庫正是最好的例子。比如一個互動複雜的下拉選單，如果每次使用前都要重新寫一套程式碼，將會徒增巨大的時間與人力成本。而通過UI庫，只需要簡單地引入，按照約定的寫法引用即可，大大解放了生產力。

除此之外，“元件化”能夠有效降低甚至消除耦合。我們知道“牽一髮而動全身”，如果一個系統各模組之間耦合太緊，一旦有個地方出現問題，排查起來將會非常困難，其後果可能是災難性的。而“元件化”的思路能夠很好地避免這個問題。因為元件之間是相互獨立，僅僅通過介面相聯絡，一旦某個元件出現問題，只需要排查這個元件的故障即可，其他元件完全可以正常工作，或者等待這個元件修復後再工作。

二、純函式

元件化開發與黑箱

維基百科定義：

在程式設計中，若一個函式符合以下要求，則它可能被認為是純函式：

  • 此函式在相同的輸入值時，需產生相同的輸出。函式的輸出和輸入值以外的其他隱藏資訊或狀態無關，也和由I/O裝置產生的外部輸出無關。
  • 該函式不能有語義上可觀察的函式副作用，諸如“觸發事件”，使輸出裝置輸出，或更改輸出值以外物件的內容等。

從數學來說，若定義一個函式：

f(x) = x + x
複製程式碼

那麼不管何時何地任何條件，只要我輸入1，那麼一定會輸出2：

f(1) == 2
複製程式碼

正是因為這種“純”的特性，所以允許對其進行“高階”：

f(x) = x + x

g(x) = x * 2

h(x) = x * x

h(g(f(1))) = 16
複製程式碼

網路上對於純函式和函數語言程式設計的文章非常豐富，本文就不再贅述了。從我個人角度出發，只要能理解什麼是“純”即可。

三、黑箱

元件化開發與黑箱

繼續引用維基百科的一句話介紹：

黑箱，指一個只知道輸入輸出關係而不知道內部結構的系統或裝置。

生活中的很多東西都可以理解為“黑箱”，比如我們常用的手機，我們可能不知道它到底是怎麼執行的，只知道我的手指劃過，它就會作出相應的動作，這時，手指劃過就是“輸入”，相應的動作就是“輸出”。因為輸入輸出如此直觀簡單，所以手機能夠被所有人輕鬆地使用。

我們的工作離不開電腦，現在電腦只要插上電源開機就能用，但是人類歷史上的第一臺電腦，卻是要專業人士花費一番功夫才能執行的龐然大物——因為使用者需要完全弄懂這臺機器的內部執行原理，才能夠正確地使用它。

上述的兩個例子，其實都是為了闡述一個觀點：黑箱更有利於使用。

但是，凡事都具有兩面性。黑箱是犧牲了使用者對於其內部構造和原理的認識，換來的易用性。如果黑箱內部出現故障，那麼使用者無法得知具體原因，這個對於系統故障的排查非常不利。所以黑箱對於系統的穩定性、可靠性的要求非常高。

四、工程實踐

元件化開發與黑箱

經過前文的三個小節，應該不難理解我想表達的觀點。一個黑箱就是一個純函式，抽象出來的元件理應符合這種黑箱的設定：

  • 元件之間僅通過介面聯絡 一個元件可以接收多個引數，元件的巢狀和使用也是通過介面進行。元件在處理完傳入的引數後，應當把結果通過介面（或者事件）傳遞出去，而不能直接影響外部。比如下面這個例子，經過f(x)的處理，外部的num並不會被改變。

    num = 1
f(x) = x + 1
// f(num) => 2
// num => 1
複製程式碼

  • 元件內部的執行原理不對使用者開放 很容易理解，元件應當是一個黑箱，使用者無需關注內部的實現原理。當然，元件應該保證高度的穩定性和可靠性。

  • 元件的輸入輸出完全確定 結合“純函式”和“黑箱”的概念，一個元件應當是可預測的（predictable），只有完全確定的輸入輸出才能保證。因此在工程實踐中，強制規定輸入的資料型別、變數名之類的內容是非常必須的。

後記

元件化的開發還有許多最佳實踐，比如涵蓋了一定邏輯功能的“業務元件”也是值得探討的地方。本文僅為個人在開發時的一些感悟，權當拋磚引玉，歡迎各位讀者和我共同交流~感謝閱讀~~~

相關文章