代碼審查的注意事項

代碼審查的注意事項
代碼審查的目的是，一避免存在隱含的重大邏輯錯誤，上線後致使系統崩潰，二是對開發規範的檢驗，是否在開發的過程當中，遵循開發規範。
注意事項
- 命名規範
我以爲命名規範在項目中是頗有意義的，由於 開發是多人協做，版本迭代迅速，維護人員可能會更換的問題，要作到"看其名，知其意"。不能隨便亂起名字，a,b,c，這種的，應該是易讀，易理解，的。

- 註釋
註釋，起到的做用就是 解釋代碼塊，容易讓別人理解你的代碼。咱們在項目中，其實會常常遇到人事的變更，可能該階段是你負責，下階段就換成其餘人了。 那麼，若是不寫註釋的話，讓其餘人員怎麼明白的瞭解你的代碼思路，怎麼對你的代碼進行維護呢？換位思考一下，你願意去接受一個沒有一點註釋的，通篇長代碼的項目嘛？估計心裏一萬隻草泥馬奔騰而過。因此，爲了本身，爲了他人，爲了社會的和平，仍是好好寫註釋把。

註釋分爲單行註釋和多行註釋，單行註釋主要是針對一行代碼進行的標識。多行註釋通常是針對代碼塊進行的註釋，註釋內容能夠是你的實現思路，該模塊的功能是什麼。
- 目錄結構， 組件劃分
目錄結構清晰明瞭，每一個文件夾作一件事情，api 文件夾對應的時接口，view文件夾對應的是頁面，style文件對應的是樣式文件,bussiness是組件等。

按着業務組件和基礎組件對組件進行劃分，什麼是基礎組件？什麼是業務組件呢
基礎組件： 項目中不涉及到業務(內心確定想的是 這不是廢話嘛),更細一點說，該組件我在這個項目中能夠用到，在其餘項目中也能夠用到，好比封裝的表格，封裝的表格頭部的按鈕組。可是，表格的渲染的數據是不一樣的，因此，數據的獲取咱們在父組件中進行，拿到後傳到子組件，按鈕觸發，請求的接口多是不一樣的，因此，數據的傳向咱們須要在父組件中進行，子組件只須要將事件傳到父組件中便可。

**綜上所述，基礎組件就是 能夠複用的組件，數據的來源來自父組件，數據的去向也經過事件傳到父組件中去進行操做。**

業務組件：一些涉及到業務的組件，好比，咱們的新增側滑組件，該組件就只能針對當前的項目中去使用。咱們可在這裏面進行經過接口進行數據的獲取，也能夠經過接口進行數據的傳遞。

在代碼審查的過程當中，經過對組件清晰明瞭的劃分，有助於幫助咱們理解項目的業務結構。

- 方法中的邏輯
對函數中的邏輯進行審查，查看該邏輯是否有重大錯誤的問題，若是沒有的話，就要看一下 是否有須要優化的地方。

- sass 的使用
是否將經常使用的字體大小，顏色等進行變量賦值，是否對一些公共樣式 進行混入的寫入。

- 混入
在項目中，屢次調用的方法可使用混入的方式。避免重複寫大量的代碼，使代碼整潔。或者，頁面中邏輯代碼過多，爲了代碼的整潔，也可使用混入的方式。