此文并不是介紹項目的性能的如何優化，而是介紹本人在工作中總結出來的一些開發經驗，旨在通過改善開發習慣，來提升工作效率。

 

[[219253]]
這就是埋汰.jpg

東北人有個詞兒特別有意思，叫埋汰。哈哈，不知道諸位老鐵們有沒有聽你們身邊的朋友說過。生活上，我們肯定是不想讓別人嫌棄我們埋汰。同樣，我們的項目也不應該“埋汰”。制定一個優秀的項目結構，不僅能讓我們自己看的舒服，在日常的代碼維護也能夠給我提供極大的便利。所以，工作中總結了一些前端項目結構的優化小建議，獻給諸君。

1.項目目錄優化

這個可能是很多人最不在意的地方了，但這里是影響你開發視覺效果的關鍵。

正確利用static文件夾

static，意為靜態的，就是應該將一些固定的資源放入static，比如vue-cli提供的static文件夾，將一些固定的資源，例如404圖片等圖片資源，存放地區碼的.js文件等。這些資源放在static中，不僅引入起來方便，而且static中的文件并不會被webpack處理，能夠進一步節省打包時間。

應該有一個util工具箱

util，工具，顧名思義這便是一個存放各種工具函數的文件夾。項目中難免會用到重復的處理函數，deepClone、floatCheck、moneyFormat等等。用的地方多了，我們每個頁面都復制一遍這些函數，顯然是不合理的。所以，我們就將這些公共的工具類函數，統一放到util文件夾下，這樣用的時候，直接引入即可，修改某一個函數的時候即可統一修改，又可以根據參數進行特殊處理。

 

util中根據函數功能進行合理分類.png

注意，util里面也應該根據函數功能，進行合理分類。所以你的util應該是一個工具箱，而不是一個工具欄。

注重用文件夾進行合理分類

我覺得閱讀我這篇分享的，肯定有而且還有不少人，在處理文件上存在下面這樣的問題

 

將一個類別下面的文件全堆到一個文件夾里.png

可能上面這個例子還不算太糟糕，文件數量不多，并且命名格式一致。但如果文件數量很多，并且命名又不一致的話，可以想象到在進行代碼維護時，光找目標代碼都可能會花上一段時間。

所以，建議對文件像下面這樣按功能進行細分(但要注意分割的細粒度，適可而止，不能劃分的過于細節)，這樣我們在回過頭來review代碼時，根據文件夾就能鎖定我們的目標文件的位置，快速的定位到目標。不要怕文件夾多，能提高工作效率才是我們的最終目的。

 

按功能劃分.png

將請求和接口進行統一管理

在每個項目里，我都會專門分出來一個這樣的文件夾。僅僅從名字也可以看出來，這是一個用來管理請求的文件夾。

 

image.png

我會將所有涉及到http請求的處理，統一放入到http.js中來管理。比如說像下面這樣，將參數的處理，請求方式的處理等等，封裝在內部。暴露出來一個方法，使用時只需要傳入相關接口、參數、請求方式即可，其他邏輯處理統統不需要考慮。

 

image.png

對于請求接口的管理，我覺得也有必要提一下。因為我有一次在接一個項目的時候，發現所有請求的api統統硬編碼寫在了請求方法里。這真的是寫時一時爽，修改找半天，費了九牛二虎之力才完成了工作。

目前，我對請求接口的管理呢，是將所有接口都放到了一個統一的文件中。在調用相關接口的時候，直接從這個request.js文件中獲取，這樣做的好處首先就是避免了硬編碼這種很讓人忌諱的方式，同時在一個接口多出調用時，只需要引入一下就可以獲取到，再者就是維護起來特別的方便。

 

image.png

實際上，說是維護起來方便，但這也是相對來說的。當接口數量達到某一個量時，將所有接口放到一個文件內，就顯得有些臃腫(上面圖片的右側，可以看到密密麻麻的接口)，但這個問題貌似也并不是那么關鍵。所以，這里具體怎么權衡可以參考一下上面的第3點。

config文件夾，將你的配置操作搬到這里

(注：上面說的config文件夾泛指配置，并不是具體名稱，因為使用config這個名稱，很有可能會跟一些腳手架命名沖突)

無論應用大小，項目的初始化總不能少吧。如果你需要配置很多的選項，像Vue中axios的初始化、請求攔截器、相應攔截器，路由的初始化、全局鉤子設置，還有其他一些基礎的配置等等，我們總不能將這些東西統統放到main.js里面來吧。所以，就有了下面這個結構

 

初始化和配置操作.png

將初始化操作、固定的枚舉值或者其他配置內容，放到一個統一的位置中。這樣會方便我們在修改配置內容，尤其是添加新配置的時候，我們直接就會有目標的去添加相應的內容。

這里有一個點，比如項目中兩個文件都需要引入Vue，那么在每個文件中都寫import Vue from 'vue'，這就會導致項目在打包時，會多引入一次Vue，增加了項目的體積。所以，推薦引入Vue時，暴露出來一個對Vue的引用export let _Vue = Vue，而不是反復使用import語法。

2.代碼習慣

組件命名:/area-selector/area-selector.vue對比/area-selector/index.vue

項目開發的前期，我采用了前面這種寫法，但是后來我改成了后面這種寫法。原因很簡答，組件文件夾命名已經能夠將組件的功能充分表達出來了，所以組件完全可以不用重復這個描述。并且，使用index.vue這種風格，在組件引入時，可以省略index.vue，如import areaSelector from '/xx/area-selector'。

3.代碼風格

拒絕復制粘貼

魯迅說，復制粘貼是萬惡之源。沒錯，在現在的我看來，復制粘貼確實是很多問題的源頭。

在寫相同的頁面或者寫一份同樣的校驗腳本時，相信有很多偷懶的老鐵都是直接咔嚓咔嚓的大段大段的復制粘貼，起碼我身邊就有不少這樣雞賊的同事。看起來做東西的速度挺快的，但實際上是在給自己挖坑，因為到***可能連你自己都不知道你的這段代碼到底用在了哪些個頁面。一朝需求改，代碼改到哭啊。

我在項目中，通常都會將需求進行簡單的分析一波。涉及到相同或者類似的內容時，都會做一下標記。那么在開發的過程中，就會將公共的內容提取出來，留著復用。即使出了bug或者調整了需求，都能夠做到一改皆改，兩個字效率。

注釋會讓你記起曾經的代碼

關于代碼注釋，現在存在兩種完全不同的觀點。有相當一部分關于代碼注釋的文章里就認為“代碼***的注釋就是沒有注釋”，或者說“代碼才是***的注釋”。但在我看來，純屬瞎扯淡。真的，不要對自己的記憶力太樂觀，自己現在思路非常清晰的代碼，過一段時間后，可能真的都回想不到自己當初定義的這個方法到底是干嘛的了。所以，一定要給代碼寫一份好的注釋。

《代碼大全》里介紹說“一份好的代碼，注釋應該占全部的2/5”。我寫的代碼在處理一般問題時，可能也就達到1/5這種程度，僅作為簡單注釋。但在處理一些復雜邏輯的時候，寫的注釋就會非常多。會將設計的數據格式，處理思路，技術坑等內容，很詳細的記錄下來。在回頭修改的時候，根據注釋就能跳過很多不需要檢查的代碼。

 

我的部分代碼注釋.png

細節習慣

說到習慣，這里介紹我的三個習慣：

• 合理使用 &&、|| 和三元操作符來代替if…else

比如將賦值語句修改了使用邏輯運算符，就能讓我們的代碼精簡很多!

 

function getValue(value) { 
  let res 
  if(value){ 
    res = value 
  } else { 
    res = -1 
  } 
  return res 
} 

修改為

 

function getValue(value) { 
  let res = value || -1 
  return res 
} 

內部調用函數用“_”來標記

比如將頁面初始化函數initPage()修改為_initPage()，這樣做并沒有什么特別突出的好處，但是能讓你清楚哪些方法是代碼內部調用的。

消除魔術字符串

所謂魔術字符串，就是指在代碼中采用硬編碼寫入得字符串。這樣的魔術字符串通常會降低代碼的維護性，因為你修改代碼一不小心就可能漏掉了某一個。

 

//消除硬編碼 
let preText = 'hello' 
let nextText = 'world' 
if( xx ) { 
    // console.log('hello')  //魔術字符串  維護性差 
    console.log(preText) 
} else { 
  // console.log('hello world') 
    console.log(preText +' '+ nextText) 
}  

OK，以上就是想要分享的內容。整片文章內容并不是如何的新鮮，但卻都是我從實際的操作中體驗出來的感悟。一部分是自己的總結，一部分是對耳熟能詳的理論的重新認識。由衷之言，希望可以給你們帶來一些價值。