總結一下，自己對前段專案結構的構建。

　　匆忙寫下，後續修改。

　　對於前端的各種風格，我倒是沒有什麼所謂，每個人有每個人的風格。我比較在意程式碼的結構，程式碼的結構清晰，更容易幫助人理解業務邏輯，而不至於陷入各種api的呼叫使用中無法自拔，api使用不合理，倒無所謂，每個人都有自己的欠缺，有些知識不夠深入，就容易api使用不合理，但是，客戶端的效能很強大，這些東西在前期都可以暫時性忽略。

　　1、唯一入口。

　　每一個頁面都有一個唯一的入口，即，從資料夾，css，js，html都是從一個入口進入，往深入擴充套件，讓整個結構看起來像一棵樹，一層套一層。這樣，在無形之中，自己就會將程式碼寫在合適的地方。下一個接手的同事，在梳理程式碼的時候，更容易熟悉業務邏輯，在不是很熟悉的時候，也會將程式碼寫在合適的地方。

　　2、靜態文字，資源的管理。

　　從國際化角度來說，所有顯示在頁面上的文字都應該抽離出來；所有介面的呼叫地址，也應該獨立存放，根據上面的唯一入口原則，當專案非常大的時候，可以摺疊，查詢維護起來會更加方便。

　　3、動態資料的管理。

　　在前端構建專案的時候，大多時候都是先寫好靜態頁面，寫好互動，再接入介面；後臺版本迭代過多的時候，也可能會重構專案，將很多冗餘資料，欄位去除，整個專案重構，後臺重構，往往前端也要跟著重構，這個時候就可以將動態資料靜態化，意思是，前期構建好的專案，需要的資料，封裝成一個JSON，通過一個格式化資料的js檔案，轉化過來，之後所有通過介面返回的資料，都通過這個js檔案，轉化成前端說需要的JSON結構。即，ajax ---> js檔案 --->  JSON  --->  頁面資料。往後，後端重構，前端樣子不變，或者結構不變，我們只要在js檔案中將後端返回的新的資料結構，轉化成為之前的結構即可，將整個專案的互動和動態資料解耦。

　　4、不同頁面交接，入口分發式。

　　現在很多專案都是spa，spa很大一個問題是首屏載入，而更多時候使用者是過路式使用，即，只用之中一個功能，用完就走，例如打卡，打完卡就直接關閉頁面（沒有想解決這個問題）。比較常見的處理方式是：按模組載入，即，打包的時候將每個模組打包成一個js檔案，就減少了首屏載入的一部分問題。在不斷的迭代中，需求發展著很可能會讓多個模組耦合在一起，隨著版本的迭代，在專案的某個部分公用多個地方，又不能抽離成元件的時候，整個專案版本迭代過多之後，大多會變得不可維護，難於維護，特別是趕時間，寫了程式碼沒有時間去重新整理，就需要一個公用耦合頁面入口進行分發，以後維護，還是交接時，都知道應該在哪裡寫程式碼。

　　5、第三方元件，二次封裝。

　　現在提倡的模式是敏捷開發，各種npm，各種UI庫。剛構建專案的時候，用得很爽，擡手間就將專案寫完了。但是，現在定製化程度很高，產品經理需求也更多，更加想象不到，用著用著第三方的UI庫，特別是多個地方用上的時候，並且UI妹子沒有元件化思想，一點點改動的時候，UI庫的元件就會變成非元件，最後統一元件的時候，就會發現一個殘酷的現實，某些元件寫著寫著變成了另一個元件，某些本來不是元件的，寫著寫著變成了元件（寫程式碼沒有元件化，別人罵你，你還不能反駁），當某些某些元件變成了新的元件的時候，處理不恰當，新元件跟業務會耦合在一起，如果沒有足夠的時間梳理，那麼，最簡單的方法就是拷貝。。。從此，再無元件。

　　6、本來不是元件的，寫著寫著變成元件了。無解，求搭救。 

　　本文原創，不允許轉載，如有問題，歡迎探討。