reusable：前端可複用程式碼目錄結構的設計
前端開發的主要流程就是取服務端的資料處理後渲染到本地ui，或者取本地ui的資料處理後傳送到服務端，本地可能會儲存一份副本。
圖中只是簡單花了一下主流程，可能涉及到一些store和本地localStorage的互動，元件和具體dom的互動等沒有畫上。
每一個業務模組大致都是這樣的流程，多條業務流程之間肯定是有相似或相同的部分，這部分也就是可以複用的部分。
可複用程式碼的劃分
可複用的程式碼之間也是不同的，比如是ui層的可複用程式碼，store層的可複用程式碼，api的可複用程式碼或者其他部分的可複用程式碼。
按照 流程 這個分類依據，可以分為4部分：
可以複用的程式碼可能是業務程式碼，也可能是一段業務無關的邏輯。按照 是否業務相關 這個分類依據，可以分為2部分：
專案可能使用的是不同的技術棧：vue、angular、react等等。可以複用的程式碼可能是與具體框架相關的，比如vue的directives，vuex的plugins等或者angular的service等。
按照可複用程式碼的 是否框架相關 ，可以分為2部分：
這3種分類是從不同維度對可複用程式碼進行劃分的，他們之間有幾種組合方式：
按照 流程 > 是否業務相關 > 是否框架相關 的分類順序來劃分是這樣的：
按照 是否業務相關 > 流程 > 是否框架相關 的分類順序來劃分是這樣的：
按照 是否業務相關 > 流程 > 是否框架相關 的分類順序來劃分是這樣的：
當然，3種分類依據一共會有6種組合方式，我只是列了其中3種。
但是專案中我們真的會拆分的這麼細麼？很少，這是理想狀態下的劃分。具體分類依據和不同分類依據的順序與我們的實際場景關係很密切。
比如** 是否框架相關 只有在程式碼需要 跨技術棧複用 的時候才會考慮， 是否業務相關 在可複用程式碼 跨專案 的時候會考慮，按 流程 劃分在只需要 某一層的可複用**程式碼的時候會考慮。
而且可能我們的劃分依據會涉及具體業務，比如使用者模組的可複用程式碼，訂單模組的可複用程式碼等。
頂層目錄的設計
一般專案中很常見utils、common、core等目錄，其實這些都是可複用程式碼，只是按照不同分類依據拆分的而已，這些可以合併成一個頂層目錄，然後內部再細分。
就像我一直覺得page、components、router這些都是view層程式碼，應該放在view這個頂層目錄下一樣。
當然，這也是理想狀態下，實際分這麼細的不多。 ##我們專案的劃分方式
最近在調整目錄結構，我的想法是這樣的：
首先，我們可以把所有的可複用程式碼放在一個頂層目錄reusable下， 然後再分為ui、store、api、other、common這4個二級目錄，ui、store、api、other就直接存放可服用的程式碼檔案就可以了。比如ui層的directives、filters，store層的plugins等。
other下是一些與某一層無關的程式碼，比如StringUtils，DateUtils等。
之所以這麼分是因為我們專案的程式碼不需要跨專案和和跨技術棧的複用，所以不需要考慮 是否業務相關 ， 是否框架相關 這兩個分類依據，只要按照流程分好類存放就會很清晰了。
總結
前端開發過程中，有一些程式碼是不同的業務流程所複用的，而且按照不同的分類依據：流程的那一層、是否業務相關、是否框架相關等有不同的劃分方式，甚至可以按照具體業務來劃分。
頂層目錄可以是分散開的utils、common、core等，也可以合併成reusable，然後內部再細分。就像view層的components、page、router一樣，細分程度不同。
我們的目錄調整時，因為專案特性只需要考慮按流程分類就可以了。當然，不同的專案和場景，分類依據是不一樣的，但是整體思路類似。