如何下降前端開發的複雜度

優秀的程序員老是能優雅的組織本身的代碼，清晰的編寫思路，合理的組織結構劃分，從小的功能組件，到大的模塊結構，都能經過合理的巧妙的搭配，不只能化複雜爲簡單，更能提高代碼運行效率，提升代碼的可維護性。咱們做爲前端開發，都應該具備這樣的能力。

那麼如何才能下降業務開發的複雜度呢？

細分組件

都說模塊化開發，其實在AMD，CMD這些思想規範以前就已經有模塊化開發的規範了，雖然JavaScript標準從es1-es4 而後隔了n年纔有了es5，在那N年基本都是‘函數式開發’，一切皆函數。以前尚未模塊化加載的思想，畢竟也不須要，富客戶端仍是flash的天下，基本都是簡單的網頁嵌套一些後端的代碼邏輯，而後經過後端渲染引擎渲染或者解釋器解釋產出html頁面，什麼ASP，PHP，JSP等等。

然而以前的模塊化稱不上是模塊，爲何呢？由於沒有模塊加載器，主要是經過JS加載順序來控制加載的，依賴的JS文件放在前面。模塊主要是按照文件來劃分，每一個文件是個獨立的功能模塊，在自定義的命名空間下掛在須要暴露出來的函數，其餘函數能夠調用。固然也有一些打包工具，能夠根據事先定義好的文件列表，把多個文件打包成一個bundle。

而如今，且不說你是喜歡本身編寫或者用現有的模塊加載器，或者直接用像Angular，React，Vue等現成的腳手架作開發，固然自帶的就有了模塊加載，配合Webpack、Rollup等打包工具，能夠完美構建你想要的項目加購。

因此呢，建議仍是要按照功能和業務結構劃分你的組件，這樣呢一方面能夠將功能解耦，一方面方便實現各自的業務邏輯，知足keep it simple的原則，模塊自制。組件細分的得當，就不會出現一大堆函數代碼，來回修改各類狀態，一堆變量，一個函數寫幾十行那樣。

建議：ES6 module + 函數式編程 + webpack/rollup ，絕對能夠知足你的須要，關於業務如何拆分，拆分的維度，後面介紹。

獨立狀態維護

狀態是什麼？狀態是數據。

程序是什麼？程序是數據+代碼。

因此可見數據的重要性，如何維護好一份數據相當重要。那麼前面咱們說了細分組件，數據呢？ 數據是跟着組件的，那麼數據天然也是須要作劃分了。這裏面說的是獨立狀態維護。假設一個組件的代碼是這樣的。

/**  約定規範 **/
// 狀態
const state={
}
//行爲
const actions={
    init:()=>{
    //組織聲明週期
   }
}
//視圖

const view=()=>(
    <div></div>
)

這樣很清晰的將程序代碼劃分紅了狀態、邏輯和視圖。邏輯操做狀態，視圖更新展現狀態。

爲何說要獨立狀態維護呢？也是爲了下降耦合、提高組件複用。組件的狀態應該只是包含組件須要的數據，而不該該包含其餘多餘的數據，按照軟件設計單一職責的原則，組件的職責應該也是單一的，就是負責這個組件的增刪改的功能。

須要說明的是組件的開發應該也是須要遵照數據驅動化的開發模式，避免直接操做DOM，即便是從DOM上拿數據，有同窗喜歡這麼幹哈，把數據經過data-x屬性掛在節點上，而後經過節點獲取數據，這樣操做是很差的，首先這種操做有反作用，並且容易引起bug，並且也可能有安全風險。

細心的同窗可能要問，那麼組件通訊怎麼辦呢？組件之間的交互能夠經過註冊函數hook的形式進行。當前你也能夠作一個事件註冊和分發的功能，不過通常一個SPA頁面不須要作的這麼複雜，若是真的是很複雜的頁面，仍是建議作成作個頁面。不必作成一個大大的SPA。

函數式編程

關於fp函數式編程github地址：https://github.com/chalecao/fp這裏並非來討論函數式編程和OOP編程的好壞，你能夠兩者都用，也能夠用其中一種，並無限制，看我的喜愛。我我的呢以前常常都是class 還有extends混入高級的this。後來漸漸轉向了fp函數式編程，完徹底全能夠避免使用new，避免使用this，並且結合上面 獨立狀態維護 中的結構劃分，結合ES6的模塊劃分，能夠很優雅的實現我全部須要實現的業務邏輯功能。