前端項目實踐之「道」：用對了方法，效率翻番

如今前端很是火熱，相關的技術更是層出不窮，前端人也在不停地學學學。那麼有沒有什麼「偷懶」的方式，幫助咱們更加有效地完成編碼的KPI呢？本人從事前端開發工做多年，負責公司多個大型項目前端架構設計與落地實踐，本文就和你們聊一聊前端的「項目實踐之道」與「變化之道」。

 

在進入正題以前，咱們先回顧一下前端的發展史。前端在最先期的階段，又被稱爲「切圖仔」——寫一些簡單的靜態頁面，而後交給後端組裝起來；後面隨着業務的發展，產生了更復雜的業務需求，jQuery，bootstrap等相繼問世幫助咱們更快地開發；而隨着外部對前端業務需求的增強，頁面變得愈來愈複雜，原有模式的開發變得愈來愈吃力。這時誕生了MVVM概念，angular、react、Vue框架相繼出現，這使得整個前端的發展進入到一個新時代。那麼，如何在發展的浪潮中找到前端的「道」呢？

 

首先來看一則小故事：

 

行者問老和尚：「您得道前，作什麼？」老和尚說：「砍柴擔水作飯。」行者問：「那得道後呢？」老和尚說：「砍柴擔水作飯。」行者又問：「那何謂得道？」老和尚回答說：「得道前，砍柴時惦記着挑水，挑水時惦記着作飯；得道後砍柴即砍柴，擔水即擔水，作飯即作飯。」

 

不難看出，老和尚得的「道」指的是同一時間專一作一件事。作前端也是同理。在得道前，咱們以爲前端工做複雜，緣由在於同一時間考慮了好幾項功能，一不留神就把全部東西都寫出來，但代碼的質量並不高。

 

1、何爲前端工程化之道？

最重要的工做是對代碼層次有效地拆解，咱們能夠簡單地將其劃分爲項目的框架、組件、服務、業務頁面四個部分。框架分爲基礎框架和業務框架，搭建業務框架，目的在於提供總體的解決方案讓其它區塊（層）更加純粹；善用組件庫【基礎組件（含樣式）、業務組件】，減小重複的輪子；服務即爲統一的方法集或者對於某一模型層的統一處理；而業務頁面的重點在於專一業務自己。此外，還有模塊化，微服務等等。咱們默認層與層之間是互相信賴的，當咱們在作其中某一項工做的時候，能夠看成其餘部分不存在，僅着手於咱們須要的。

此外，咱們也能夠從另外一個角度將層區分爲：數據層（包括封裝了對數據的一些基礎處理）、邏輯層（項目較大，邏輯層可能會被拆成多層）和視圖層。

在拆解項目的過程當中，劃分目錄結構很關鍵。固然，如今的CLI在目錄結構上幫咱們拆好了一部分，好比下面這個vue-cli給咱們生成的結構：

它在建立項目的時候會自動幫咱們建立目錄結構，簡化了咱們初始化項目時的工做。但這個項目結構仔細來看過於簡單，更接近demo的狀態，於是咱們須要再對這個結構進行改進。咱們須要創建一個業務框架，規劃更健全的目錄結構，同時包一層方法庫（如權限、請求）並提供統一處理函數及全局攔截相關的處理，搭配好必要的全家桶套餐等。

2、前端工程化之目錄結構拆分實踐

下圖是咱們某一個項目的結構。它相對複雜，包括PC端和移動端兩部分，共用的部分就在common文件裏。它包括assets（圖片、資源信息）、components（一些公共的組件）、過濾器、mixin（一些用於合併的模塊）、service（公共服務）、stores（數據存儲）、utils（預處理函數，工具）。

PC文件夾裏有一些特有的靜態資源、文件、插件。Mobile這個文件夾也是同樣的道理。這個項目裏的components更傾向於通用業務組件，plugin則傾向於放一些引起效果變化的插件；router是一些路由信息；views是一些業務的組件。經過這樣的分層，寫業務的同窗能夠在views裏去寫；即使是一我的負責全部部分，他也可以在各個環節都保持專一。

3、實例：個推部分產品架構設計實踐

個推擁有較爲豐富的產品線，其中有的產品線下不一樣產品的主要功能模塊近似，但這些產品之間又相互獨立。因此，若是咱們逐個開發單個產品，代碼會被重複拷貝屢次，若其中一個須要修改，則其餘的都要作相應的調整。那麼咱們如何解決這個問題呢？

 

這裏先介紹幾個具體的概念。

產品：每一個具體的APP就是一款產品。

項目代碼：包括廣義的gulp/src/cloud等，與狹義的src文件夾。

 

基於這些，咱們想到了一個方法：源代碼做爲獨立的一部分，對於不一樣產品使用不一樣配置及特殊組件，而後打包成不一樣的產品。

咱們內部有一個組件庫，包括基礎組件和樣式組件。

 

個性化的部分

首先把這些模塊拆分爲一個個小的組件，這裏咱們用三角形、圓形和方形表示；而後結合原來的基礎組件，組成部分功能組件；接下來經過功能組件的堆積，造成各個具體的業務功能。於是總體上，個性化部分（業務功能的不斷自我調用）至關於一個模塊了，能夠組裝到某個產品中，它的最終形式是由相關的配置決定的。此外，view裏的插槽的區塊，是由產品來定義插槽中業務組件的最終展示形式。

 

公共的部分

數據層會提供一些支撐服務，主要是帳號服務，與臨時存儲相關。咱們也針對數據層進行了劃分：API call借鑑RPC思惟，造成通用發請求的方法；Model call是比較早期的一種模式，會把具體的請求服務分裝好；get json是針對某一部分沒有封裝成後端接口源數據的文件。

視圖層主要有兩部分，不一樣產品的配色不一樣，文案也不一樣。

以上就是咱們總體的一個架構。

 

4、關於架構模塊劃分的一些TIPS

下面給你們介紹一下咱們須要的一些工具：一、自寫node小程序用於檢查一些權限，比肉眼更精準；二、自建CLI，基於項目實踐流程，將一些固化的工做寫成工具集成到自有的CLI裏面。隨着項目演進，咱們將apps文件夾拆成了獨立的倉庫管理，並寫了一個腳本，讓其和主程序軟鏈，從而直接能夠運行。

前面，咱們也提到了組件庫。除了業務框架的細分，咱們還須要對組件進行分類，包括：樣式庫、公共函數庫、**js**的插件、業務組件、模塊化。

至於組件庫的範圍，咱們能夠分爲全範圍級別組件庫、產品線級別組件庫、項目自有組件庫、專項組件庫。

 

5、前端的變化之道

由於如今前端很火熱，因此相關的一切皆在變化，包括技術棧、業務、設計思路、架構等等。不只如此，業務需求、開發人員、項目複雜度、實現思路等等也在變化，這些變化有可能有意無心地致使咱們的代碼正在慢慢「變壞」。

咱們發現代碼寫得越大，壞得越快，由於接觸的點太多。於是，當代碼出現了「壞味道」的時候，咱們須要儘快地把它們校驗出來。有一個效應叫「破窗效應」——即一個地方有不少窗戶，其中一塊玻璃被打破了，若是你不去管它，以後你會發現愈來愈多的玻璃被打破。於是代碼出現了問題須要當即解決，不然問題通過多年積累，到最後咱們會發現項目已經改不動了，只能棄船逃跑，新起爐竈。

上一個實踐的優點，有可能成爲下一個實踐的劣勢。早期咱們發現二級菜單中的幾個列表業務功能很是接近，咱們將其合起來求同存異，很容易管理。後來，功能近似的二級菜單愈來愈多，全部的二級模塊混在一塊兒，差別內容也聚沙成塔，咱們再想改的時候便異常痛苦。對此，咱們的一個解決思路是，當咱們發現代碼實踐方式有些「彆扭」的時候，就要作一些重構和修正方案。但這不是一蹴而就的，也不是到某個點爲止，而是須要一直去作。

還有一個不得不提的變化，是官網內的一些項目，即從SSR到SSR。在先後端未分離的時候，須要ASP、PHP、JSP之類的服務端靜態頁面渲染。後來前端工程的能力愈來愈強，能夠實現瀏覽器端渲染；再到現在，誕生了vue的SSR。如今咱們可能會用SPA的方式開發，其缺點是SPA對於官網而言可能會比較「重」，或者說咱們更加習慣目前的開發方式，難以適應jQuery時代的開發。可是另外一方面，多頁面也存在必定好處——每一個頁面都很是獨立，能夠更好地SEO，用戶也能夠享受更快的到達時間。因此，從SSR到SSR，看上去好像倒退了，但實際上這是一個螺旋上升的過程。

此外，外部也在發生着一些變化。好比，angular到6了，Webpack 4發佈了，Node之父推新產品了等等…

六：結語

市場變化太快，雖然技術很重要，但思想比技術更重要。技術是學不完的，但思想能夠類比，甚至是能夠創新的。基於新的思路，也許你也能寫出新的算法，新的技術。