中心思想是基於react的前端自動化開發框架的搭建思路及探索
文章前說明：此文章不涉及教授前端自動化架構搭建，而是細節探討，
如發現程式碼刺眼，看完身體不適著，可點贊保留，等掌握自動化開發後再來看這篇文章
先說寫題外話，現在前端這個行業，已經從原始時代走進了基於node.js的自動化開發時代。
我們曾經寫程式碼像是反翻垃圾桶，你想要什麼外掛就需要浪費很多時間去尋找資源，找不到的話只好自己造輪子，或者自己封裝一個，就像我曾經就拿著自己的行動硬碟，裡面裝滿了我封裝的原生js外掛，和一些動畫特效例子。
現在是在逛超市，所有的外掛，方法元件，ui元件放在貨架上，只要你推著購物車，就可以輕易的拿到他們。
現在大勢所趨，無論vue、angular、react都已經越來越符合這種元件化開發的模式，說來也不好笑，angular寧可不向前相容，也要做出這樣的改變。
言歸正傳，這篇文章並不是要跟你們溝通如何構建前端開發框架的，而是對比一些基於react的自動化開發的技術組合，以及一些開發的條理性的分析，細節才是最重要的
因為最近在和阿里開發一個專案，這個專案中的架構搭配，程式碼結構，語法風格等是我看到過最好的開發方案，可以滿足多人開發場景，我說的這個滿足是清晰明瞭，哪怕你這個專案多年後是新人來維護也可以一目瞭然，雖然其程式碼清新規範的功勞大多歸結於eslint-airbnb,但是其目錄結構，備註，整體的資料結構存放，都是很重要的點。
一、分析主角程式碼
1、首先看看package.json
(注：這是我精簡過後的，不可以直接拿到init初始化目錄直接生成專案結構)
- cool-cli - 主要負責編譯，打包功能你可以換成你喜歡的webpack、roadhog等
- eslint - 程式碼規範檢查工具
- eslint-config-airbnb - 這個就厲害了，這個airbnb是一般人不敢用的程式碼規範規則，真的很嚴格，如有希望自己程式碼風格嚴肅嚴謹的自己瞭解下。
- antd - 不多說 完善的企業級UI框架
- classnames - 為了配合cool內嵌的scss 方便引入樣式，也為了防止樣式全域性汙染
- isomorphic-fetch - 封裝請求核心
- mobx - 資料管理核心，適合團隊開發，方便修改、維護（下面將介紹幾種別的資料管理js）
- mobx-react - 同上 有些更貼合react的api
- react-router - 路由核心
上述這些除了 推薦Airbnb之外沒什麼好說的了
在自動化開發的結構中，上述這些就是車零件，有些零件沒了車就跑不了。
2、專案目錄結構
雖然專案目錄結構這個東西怎麼放、怎麼巢狀大多純靠自己的心情，而且一般不會影響什麼，因為編譯打包配置的時候一個正則就全覆蓋了。但是下面這個結構我只能說“欣賞”。
src
asset ：共有靜態資源目錄
images ： 共有圖片
common ：共有js檔案目錄
utils.js ： 一些共有方法
components ：React元件目錄
ant ：對ant的一些基礎元件進行封裝
common ：共有的業務元件
somePage ：這裡是業務模組的開發->業務頁面寫在這裡
config ：配置檔案目錄
dataConfig.js ：應用一些常量配置
routeConfig.js ： 路由變數配置
model ：儲存全域性資料模型目錄
Store.js ：儲存資料，可以剝離出子倉庫，mobx倉儲
routes ：路由元件目錄
index.jsx ：頂層路由入口 Main ： 頁面結構
services ：service請求目錄
Service ：service請求
styles ：全域性樣式目錄
animation.less ：主題首頁，專題首頁應用的動畫
antd-theme-file.less ： 覆蓋ant樣式變數定義
index.less ：入口樣式檔案，引入antd官方提供的 less 樣式入口檔案
index.scss ：一些全域性樣式
vars.scss ： 自定義一些樣式變數
antdIconfont ：本地ant字型圖示
fonts ：本地字型
iconfont ： 本地其他字型圖示
index.html ：入口html檔案
index.jsx ：入口jsx
.cool.dev.config.js ：覆蓋cool開發模式下的一些配置
.cool.prod.config.js ：覆蓋cool生產模式下的一些配置
ps: 上述目錄結構為刪減後精簡版本，僅供參考
上面的層次調理清晰無比，公共方法-資料層-業務配置-元件開發-樣式-路由-請求，這些都放在了同一層，我個人認為這樣是比較合理的，他們這些的層級很高並且層級應該相同，因為每個模組下面都有可能隨著專案的開發擴大，而衍生出很多子模組。如果這些邏輯之間相互巢狀，隨著需求的不斷變更，結構會越來越混亂，別說你閉眼睛都知道哪個檔案在哪，我談的是拿出去給別人開發，別人看你的專案時候所耗費的時間成本，這種繼承性在我看來在前端中很少有人做到。
3、備註的重要性
內部具體的程式碼由於有eslint-airbnb的規則約束，很嚴格，所以很美觀（主要是我這邊不好展示出來），有需要了解的朋友可去開源的airbnb那裡看看例子和規則。
備註這方面的話，我舉個我平常寫的一個參考。
變數的話使用 // 方式來註釋
方法的話 /* */ 方式來註釋
元件的話用 /** + enter 這種
4、整體邏輯
Mobx 倉 來存放業務公共資料 方法 變數
通過inject注入到元件的props中， 在constructor中轉化為本地變數， 事件觸發model裡的action
@observer監聽 被監聽者，被監聽者變化引發render。
上述內容並不重要，一帶而過即可，想學mobx的推薦直接去找中文文件，簡單易學
二、分析其他程式碼
我本想把另一個專案的程式碼放這裡跟上面進行對比，
其實我發現並不用，殊途同歸，好程式碼都是相似的模樣，亂的，各有各的亂。
1、package.json 來說，外掛搭配不合理，這是一個重病，就像不合腳的鞋，越穿越磨腳。
2、目錄巢狀嚴重，或者剝離太徹底，在很多場景中，比如業務邏輯有條線很長的時候，就會陷入找檔案困難的情形， import * from './../../../../../' 或者 import * from 'xx/xx/xx/xx/xx/xx/'等情況。
3、備註方面的話，估計也不用我多說，接盤別人專案的時候如果沒有備註或者備註不全面的話，該怎麼砸鍵盤就是個問題了。
4、整體邏輯這一點，如果你寫過原生的react + redux模式的話你就會深有體會，所有的資料最開始像織毛衣一樣，織成了一件衣服後，頻繁的需求會把毛衣打回毛線球。
三、總結
個人觀點：
前端這幾年的發展可以用百花爭豔來修飾，沉寂了太長時間，現在跑上了高速公路，辛苦了各位。
分久必合，這個道理誰都懂，現在大家也應該有了個雛形，至少前端發展目前的穩定版本是元件化自動開發。
共勉。
四、宣告
注：上述關於目錄、專案結構僅供技術層面溝通交流使用，不摻雜任何業務邏輯，禁止轉載，點贊儲存即可