前端程式碼質量優化交流
若不碎我，必逆境生花
目錄
- 專案角度
- 格式角度
- 程式碼角度
- Git 角度
- 編輯器角度
前言
相信大家都有過這種情況，接盤。沒錯，你不知道在你面前放著的程式碼經過幾個人的手，裡面有幾種風格。我見過一個專案，7、8個人接手過，輪到我接手的時候先吐了半個小時。在中大型專案中，這是一種常態，我通常稱此類專案為shi山。那麼我們怎麼才能把專案code質量這一款把的死死的呢？程式碼的健壯性如何增強？
我的上一篇文章《前端效能優化交流》講了一下在專案開發流程中，進行專案效能的優化。這一篇則是基於優化的前提下，對於程式碼質量、健壯性的一個把控。
一、專案角度
搭建框架，定製技術
1、 統一框架 - 統一技術手段
如果你做的是中大型專案或者是團隊開發模式，這一點一定是基礎原則，在評審需求文件步驟，瞭解到專案中大概的業務核心及技術難點，然後專案中前端同學們統一調研技術手段。
然而這點為什麼拿出來說呢，我見過蠻多沒按照這個標準的。
例1：因為找不到開源js
react 專案引用 jquery （貌似是為了引用一個jq拖拽外掛）
這種不多說了，根本不應該存在這種情況，應該多探討，多摸索解決方式，拓寬自己對於各種業務的解決手段。
在此推薦大家推薦一個找技術庫的網站，也可以在排行榜上了解到最新、最受歡迎的技術庫。
例2：UI元件不滿足專案需求
專案中運用兩種UI框架，antd、antd-mobile
當UI元件不滿足專案需求的時候，肯定也不可能引入兩種UI框架，對於專案來說負擔變太大。
我推薦每個專案在開始的時候自己抽分UI元件庫，建立一個公司的私有npm庫，然後大家所做的專案中的元件，都能沉澱下來，建立自己的npm庫，其中不光可以有UI元件、還可以有業務元件、腳手架等。
二、格式角度
1、eslint（lint: 包紮傷口的紗布）
js程式碼規範重要的一步。因為javascript是弱語言，很靈活，規則範圍很大。所以經常就形成一種“怎麼寫都不會出錯”的問題，每個人的程式碼風格不一。例如：Tab和空格混用、使用棄用方法、等。
如果你配置過eslint，我這邊整理了一些配置屬性，你可以搭配一些專案中需要的規範：
如果你沒有配置過eslint配置檔案，傳送門：eslint簡單介紹
我這裡把我專案中的eslint配置檔案共享出來。放到你的專案中直接使用。
2、stylelint
stylelint 跟eslint 一樣，只不過是對於css的一系列規範。
傳送門：stylelint簡單介紹
傳送門中的文章講解比較詳細，我就不多餘闡述了。
三、程式碼角度
-
變數命名
很基礎的一點，也是很多人最惆悵的一點，為變數起名字太難了。
老生常談的格式方面：
駱駝式命名法（Camel-Case）又稱駝峰式命名法，是電腦程式編寫時的一套命名規則（慣例）。正如它的名稱CamelCase所表示的那樣，是指混合使用大小寫字母來構成變數和函式的名字。程式設計師們為了自己的程式碼能更容易的在同行之間交流，所以多采取統一的可讀性比較好的命名方式。
駝峰命名法 我應該不用多說了，這個是最最最基本的命名規範。
之後，問題來了
很多業務詞語我不知道英文怎麼拼怎麼辦？
統一走相同的翻譯平臺。講道理，谷歌翻譯跟百度翻譯，翻譯一個單詞不一定一樣。
之後，問題又來了。
變數名拼接過長，按什麼順序拼？
這個問題我也是前一段時間看過一種思路，按照英語課本上的來。統一走英文語法，動詞、名詞、形容詞。英文造句語法圈起來重點考。
比如說有個方法叫“坐火車去拉薩的途中做一些事情”，我認為正確的：onTheWayToLhasaByTrainDoSomeThing()，常見的寫法：ByTrainToLhasaOnTheWayDoSomeThing() -- 途中坐火車去拉薩做一些事情。語法還是要注意一下的，否則上面這就變成兩個方法了
1、元件細化
1、元件不超過250行
經常看到某個專案中元件一開啟，1000+行，維護性、可繼承性都很差，開啟之後一臉懵逼。大多數情況下（非業務需要）超過250行的元件都可以拆分成更小的元件來維護。當你把所有元件都拆完了，你會拆出很多純元件-不摻雜業務的元件，這是就可以進行公共元件抽象提取，你會發現有很多可以提取的公共元件。
2、全域性樣式汙染問題優化
當元件抽象夠多，拆分夠細後，注意一下樣式汙染問題，我接觸的專案直接走style hash時候居多，但這裡推薦classnames外掛，拼接業務唯一標識到className前面，這樣比直接用hash更好除錯，並且每個元件就算格式一樣 className 起名字一樣也不會混淆。
使用方式：
npm i classnames --save
設定公共方法
元件中使用的時候
3、渲染次數優化
這個問題我在 《跟大家聊一下前端效能怎麼優化》 那篇文章中提到過，在目錄 四-2。
問題的解決方法在於合理觸發render。
2、 資料抽象-邏輯解耦
這兩個詞語有些官方了，大概的意思為‘拆’。拆完再合併。
上面說了元件抽象的時候我們規定250行左右。方法定製在100行。相信大家也總會見到很多龐大的方法，這種方法仔細分析的話一定是摻雜了業務在裡面，並沒有把單獨邏輯與業務分開來維護，使得這種方法即使寫了備註，一動則牽引全身，修復完一個問題，出來10個問題，這就很恐怖了。
所以我們規定方法不許超過100行，如果你的方法超過100行，就說明可以拆分成兩個或幾個更小的邏輯的組合。
這種稱之為邏輯解耦，我們拆完之後會發現很多的邏輯其實是一樣的，這時候就可以進行資料抽象，提取公共方法，沉澱成公共方法庫，編寫好備註，使用文件。我們就可以很好的進行以後的維護，繼承，修改等等工作。很久以前這種方法庫我都是放u盤裡隨身攜帶...
這裡重點：jsinspect，上述中的元件抽象及邏輯抽象都可通過此外掛來整理，設定好排查路徑，則會直接生成一個檔案列表，告訴你哪裡和哪裡是相似的可以抽象，非常好用。
替換一下src路徑即可，執行npm run check:json 就會在根目錄下生成jsinspect.json檔案，裡面整理的很詳細。
3、 try catch
很重要的細節，我們常說輸在了細節是吧。大家仔細看
如果介面返回statusCode異常，可以在你的ajax層攔截掉，如果statusCode 200ok，但是介面返回資料異常，那就gg了。為什麼呢？如果你需要一個array，後臺突然返回了個object，極大多數都會觸發js錯誤，介面直接崩掉之後展示js錯誤資訊。
這種情況在專案中是不允許存在的，哪怕伺服器爆炸了前端頁面也應該面不改色的彈出一句提示“伺服器爆炸了，請明天記得看報紙”。對吧，然後我們默默的讓使用者退出系統就好了。那麼，這裡我們的try catch放在哪裡呢?
如果所有的promise都配一個try cath的話，除了麻煩， 講道理，是沒有問題的，
promise(() => {}).then(res => { try { res... } catch { ... } })
然而，這裡總會有個小轉折，我們可以把這個抓取js錯誤的方法放在入口處，沒錯，就是路由。單頁面應用的專案都是把路由插入到單頁面節點中，在插入的方法外層try catch，一勞永逸。
4、 所有節點需有唯一識別key
這一點來說也是蠻重要的，現在無論react，vue，angular，都是元件化開發模式，在這種模式下，底層原理都是構造虛擬樹的diff演算法，用來判斷哪些元件重繪，哪些不用重繪。
通常的DOM元素的key是自動生成的。然而，在什麼時候會有問題呢？舉個例子
我需要渲染一萬條資料，後臺沒返回唯一識別id，用角標代替
這樣，我們的資料的key為“0、1、2、...”，表面上看沒什麼問題。如果我們進行刪除操作，刪除第一條資料，那麼重繪的時候key就會重新排列，曾經的第二條就變成了第一條，key變為了0，以此類推，diff演算法用key判定是不是相同DOM節點，然後比較內容，剩下的9999條資料的內容跟上次記錄的樹全變了，因為對比的時候是拿 上次第一條資料的內容去比較現在第二條資料的內容，因為第二條資料的key變成了0，不知道我闡述明白沒有。所以會重繪9999個DOM節點。
那麼：如果key是唯一的
對比key之後對比內容，就不會重繪9999個DOM，只是單獨刪除掉了第一個dom元素而已。新增功能於此相同。所以大家要注意一下唯一值key的問題。
5、 prettier
此外掛用來格式化程式碼，使程式碼哪怕在開發的時候格式混亂，是吧，編譯一下，就會變成統一格式。非常適合團隊開發使用。
這個時候有些同學可能會有個疑問，我的開發工具，比如vscode，可以下載開發工具外掛，如圖。
開發工具中也可以裝一些外掛輔助你開發，但是這個，只能輔助你自己，如果你的同事沒有裝，或者裝了跟你配置的不一樣，那麼就非常不理想了，所以說，還是在專案中配置eslint，prettier等規範為上策。
四、Git角度
通過git precommit鉤子，每個人在上傳程式碼的時候做一層攔截，保證上傳到gitlab上的程式碼質量。
這裡話不多說，大家看完package.json配置就懂了
1、husky：對 git 進行 hook，可以在 git 操作之前做一些操作； 2、lint-staged：對當前 git 提交的程式碼進行一些操作。
直接按照我這樣配置好就可以了，每次上傳程式碼的時候都會走一遍上述所說的eslint、stylelint、prettier等規範。當然也可以自定義一些操作。
五、編輯器角度
這一點來說，專案中可以統一開發工具的配置，檔名為.editorconfig的根目錄配置。
我們通過.editorcofig檔案可以統一開發工具的配置環境，就算你的同事用的subline，你用的vscode 也不會影響程式碼風格，規則等問題。
我這邊也直接給出一個配置檔案。
END
上週很忙，手裡同時三個專案，真是在抽時間寫文章，寫文章真的沒那麼簡單，對於一些東西的串聯的時候才發現自己不足的地方很多，多謝各位包容，如果有錯誤歡迎大家指出。這周的任務雖然還是很緊，我還是會完成我的承諾。不辜負我的28個關注人。我去改bug了，下次見。
我這邊3月底之前會寫4篇文章，分別為
《前端程式碼質量優化交流》(本篇)
《前端code監控交流》
《前端安全問題交流》
沉澱一下去年在開發流程方面的一些知識。 謝謝各位。