優異的順序員老是能文雅的構造本身的代碼，清楚的編寫思緒，合理的構造構造分別，從小的功用組件，到大的模塊構造，都能經由過程合理的奇妙的搭配，不僅能化龐雜為簡樸，更能提拔代碼運轉效力，進步代碼的可保護性。我們作為前端開闢，都應當具有如許的才。

那末怎樣才下降營業開闢的龐雜度呢？

細分組件

都說模塊化開闢，其實在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的模塊分別，能夠很文雅的完成我一切須要完成的營業邏輯功用。