組件化開發與黑箱

寫於 2017.07.28

終於完成了公司的一個大project，這期間的收穫也很是多，對於「組件化開發」有了更深一層的心得體會。

在現在的前端開發中，「組件化」已經成爲了一種流行，隨之而來的各類開發框架更是把這一律念發揚光大。可是概念歸概念，真正的「組件化」實踐仍是有許多值得探討的地方，其中「黑箱」是我認爲最具備表明性的實踐方式。今天就讓咱們拋開具體的框架，直接來談一談「組件化開發」與「黑箱」。

1、組件化

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

基於組件的軟件工程（Component-based software engineering，簡稱CBSE）或基於組件的開發（Component-Based Development，簡稱CBD）是一種軟件開發範型。它是現今軟件複用理論實用化的研究熱點，在組件對象模型的支持下，經過複用已有的構件，軟件開發者能夠「即插即用」地快速構造應用軟件。這樣不只能夠節省時間和經費，提升工做效率，並且能夠產生更加規範、更加可靠的應用軟件。

在業務的開發中，咱們每每會把一些須要複用的部分抽取出來單獨封裝，在須要的時候再引入使用。這樣就至關於把這可複用的部分進行了「組件化」。組件化的操做可以大大減小開發量，同時一個好的組件也能有效提高穩定性。在現代化的web開發中，「組件」一般包含了邏輯功能和樣式，各類各樣的UI庫正是最好的例子。好比一個交互複雜的下拉菜單，若是每次使用前都要從新寫一套代碼，將會徒增巨大的時間與人力成本。而經過UI庫，只須要簡單地引入，按照約定的寫法引用便可，大大解放了生產力。

除此以外，「組件化」可以有效下降甚至消除耦合。咱們知道「牽一髮而動全身」，若是一個系統各模塊之間耦合太緊，一旦有個地方出現問題，排查起來將會很是困難，其後果多是災難性的。而「組件化」的思路可以很好地避免這個問題。由於組件之間是相互獨立，僅僅經過接口相聯繫，一旦某個組件出現問題，只須要排查這個組件的故障便可，其餘組件徹底能夠正常工做，或者等待這個組件修復後再工做。

2、純函數

維基百科定義：

在程序設計中，若一個函數符合如下要求，則它可能被認爲是純函數：

• 此函數在相同的輸入值時，需產生相同的輸出。函數的輸出和輸入值之外的其餘隱藏信息或狀態無關，也和由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
複製代碼

網絡上對於純函數和函數式編程的文章很是豐富，本文就再也不贅述了。從我我的角度出發，只要能理解什麼是「純」便可。

3、黑箱

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

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

生活中的不少東西均可以理解爲「黑箱」，好比咱們經常使用的手機，咱們可能不知道它究竟是怎麼運行的，只知道個人手指劃過，它就會做出相應的動做，這時，手指劃過就是「輸入」，相應的動做就是「輸出」。由於輸入輸出如此直觀簡單，因此手機可以被全部人輕鬆地使用。

咱們的工做離不開電腦，如今電腦只要插上電源開機就能用，可是人類歷史上的第一臺電腦，倒是要專業人士花費一番功夫才能運行的龐然大物——由於使用者須要徹底弄懂這臺機器的內部運行原理，纔可以正確地使用它。

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

可是，凡事都具備兩面性。黑箱是犧牲了使用者對於其內部構造和原理的認識，換來的易用性。若是黑箱內部出現故障，那麼使用者沒法得知具體緣由，這個對於系統故障的排查很是不利。因此黑箱對於系統的穩定性、可靠性的要求很是高。

4、工程實踐

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

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

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

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

• 組件的輸入輸出徹底肯定 結合「純函數」和「黑箱」的概念，一個組件應當是可預測的（predictable），只有徹底肯定的輸入輸出才能保證。所以在工程實踐中，強制規定輸入的數據類型、變量名之類的內容是很是必須的。

後記

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