做前端也不是很久，也沒做過什麼特別大型或者是特別複雜需要很多前端配合開發的專案，所以對於前端的架構我並沒有一個清晰的認識。只是最近看著新公司的專案，實在有感而發，忍不住想說說前端專案最基礎的一些架構。
現在幾乎都是前後端分離了，所以前端專案都是前端自己搭建，整個專案的結構都把握在自己手裡。一個好的專案架構有什麼好處呢，無外乎現在網上一直說的那幾點，程式碼可讀性、可維護性、可擴充套件性。當然，本人能力有限，說說基於本人認識上前端專案應該做的。
結構上，應該明確各種資源所放的位置。比如你的圖片、圖示、外掛、元件、頁面等等，比如有些人習慣所有靜態圖片放一個資料夾，有些習慣每一個大塊的圖片放一個資料夾，這都是可行的，但是固定好了一個模式之後就要嚴格遵守。千萬不要相同型別的資源為了開發方便還是什麼的就亂放，這就導致整個專案很凌亂。
初始化，每個專案應該都有一些初始化的東西，比如css、js等，你對於這些初始化的公共的東西就要找一些比較合理的使用，而不是一直用老專案的。比如我本人使用的初始化css、適配單位rem、本地快取storejs等，都是覺得比較合理的採用，現在網上各種外掛太多了，那麼就需要找一些評分高，或者是現在普遍認為比較合理的。
封裝請求，每一個專案，都會用到請求和後端互動，那麼我們就需要封裝一個適合專案的請求互動。封裝過的請求和沒封裝過的不僅在程式碼量上，在使用上也是有很大的優勢。
高內聚、低耦合，以前一直不明白這句話具體做什麼，直到後來做到一個專案才知道這句話的重要性。高內聚，很簡單，就是每個模組之間，也就是每個元件、頁面自身之間有很強的聚合度。最簡單的就是請求地址，全域性的請求地址改一個就可以了，而不是每個請求都需要改。低耦合也很簡單，就是不同模組之間關聯度很低很低，比如我改了一個欄位或者樣式，隻影響當前模組，而不是好多個模組都變化了。
元件，現在前端開發都是元件化開發，各個框架也提倡元件化開發，所以對於公共的元件封裝，很重要，對於程式碼量減少的不是一點半點。對於維護和修改提高也很大。
規範，相信很多碼農都會有所謂的程式碼潔癖，其實這就是一個規範。不同人的敲程式碼的習慣都不一樣，要是很多人開發一個專案或者是經很多手開發，那麼這個專案在不同習慣下的程式碼，是很亂很雜的。所以就需要制定一個規範，儘量讓一個專案統一一個風格，那麼不同開發者看別人的程式碼也更容易。
程式碼，相同的功能，不同人實現的邏輯有可能是不同的，不同頁面不同人寫的標籤和樣式也會不同，那麼這時候就要審視自己的程式碼，一個簡單佈局，大概需要多少行程式碼，覺得超出了就要想想是不是思路不對，一個邏輯也是，明明一個很簡單的功能，卻發現邏輯有點多，也要想想是不是思路不對。其實這部分就要看基礎了。
其實想要架構好前端開發遠不止這點內容，從UI庫的選取、基本樣式的基調、需求的劃分、細分模組等等很多都是要有一個清晰的架構和流程。暫時能力有限，所以只能隨便聊聊。
歡迎關注 Coding個人筆記 公眾號