前端代碼質量優化交流

時間 2019-11-06

標籤前端代碼質量優化交流简体版

原文原文鏈接

若不碎我，必逆境生花javascript

前言

相信你們都有過這種狀況，接盤。沒錯，你不知道在你面前放着的代碼通過幾我的的手，裏面有幾種風格。我見過一個項目，七、8我的接手過，輪到我接手的時候先吐了半個小時。在中大型項目中，這是一種常態，我一般稱此類項目爲shi山。那麼咱們怎麼才能把項目code質量這一塊，掌控的死死的呢？代碼的健壯性如何加強？

個人上一篇文章《前端性能優化交流》講了一下在項目開發流程中，進行項目性能的優化。這一篇則是基於優化的前提下，對於代碼質量、健壯性的一個把控。css

1、項目角度

搭建框架，定製技術html

一、統一框架 - 統一技術手段

若是你作的是中大型項目或者是團隊開發模式，這一點必定是基礎原則，在評審需求文檔步驟，瞭解到項目中大概的業務核心及技術難點，而後項目中前端同窗們統一調研技術手段。前端

然而這點爲何拿出來講呢，我見過蠻多沒按照這個標準的。vue

例1：由於找不到開源js
java

react 項目引用 jquery （貌似是爲了引用一個jq拖拽插件）
react

這種很少說了，根本不該該存在這種狀況，應該多探討，多摸索解決方式，拓寬本身對於各類業務的解決手段。jquery

在此推薦你們推薦一個找技術庫的網站，也能夠在排行榜上了解到最新、最受歡迎的技術庫。git

www.awesomes.cn/程序員

例2：UI組件不知足項目需求

項目中運用兩種UI框架，antd、antd-mobile

當UI組件不知足項目需求的時候，確定也不可能引入兩種UI框架，對於項目來講負擔變太大。

我推薦每一個項目在開始的時候本身抽分UI組件庫，創建一個公司的私有npm庫，而後你們所作的項目中的組件，都能沉澱下來，創建本身的npm庫，其中不光能夠有UI組件、還能夠有業務組件、腳手架等。

2、格式角度

一、eslint（lint: 包紮傷口的紗布）

js代碼規範重要的一步。由於javascript是弱語言，很靈活，規則範圍很大。因此常常就造成一種「怎麼寫都不會出錯」的問題，每一個人的代碼風格不一。例如：Tab和空格混用、使用棄用方法、等。

若是你配置過eslint，我這邊整理了一些配置屬性，你能夠搭配一些項目中須要的規範：

若是你沒有配置過eslint配置文件，傳送門： eslint簡單介紹

我這裏把我項目中的eslint配置文件共享出來。放到你的項目中直接使用。

二、stylelint

stylelint 跟eslint 同樣，只不過是對於css的一系列規範。

傳送門：stylelint簡單介紹

傳送門中的文章講解比較詳細，我就很少餘闡述了。

3、代碼角度

變量命名

很基礎的一點，也是不少人最惆悵的一點，爲變量起名字太難了。

老生常談的格式方面：

駱駝式命名法（Camel-Case）又稱駝峯式命名法，是電腦程式編寫時的一套命名規則（慣例）。正如它的名稱CamelCase所表示的那樣，是指混合使用大小寫字母來構成變量和函數的名字。程序員們爲了本身的代碼能更容易的在同行之間交流，因此多采起統一的可讀性比較好的命名方式。

駝峯命名法我應該不用多說了，這個是最最最基本的命名規範。
以後，問題來了

不少業務詞語我不知道英文怎麼拼怎麼辦？

統一走相同的翻譯平臺。講道理，谷歌翻譯跟百度翻譯，翻譯一個單詞不必定同樣。

以後，問題又來了。

變量名拼接過長，按什麼順序拼？

這個問題我也是前一段時間看過一種思路，按照英語課本上的來。統一走英文語法，動詞、名詞、形容詞。英文造句語法圈起來重點考。

好比說有個方法叫「坐火車去拉薩的途中作一些事情」，我認爲正確的：onTheWayToLhasaByTrainDoSomeThing()，常見的寫法：ByTrainToLhasaOnTheWayDoSomeThing() -- 途中坐火車去拉薩作一些事情。語法仍是要注意一下的，不然上面這就變成兩個方法了

一、組件細化

一、組件不超過250行

常常看到某個項目中組件一打開，1000+行，維護性、可繼承性都不好，打開以後一臉懵逼。大多數狀況下（非業務須要）超過250行的組件均可以拆分紅更小的組件來維護。當你把全部組件都拆完了，你會拆出不少純組件-不摻雜業務的組件，這是就能夠進行公共組件抽象提取，你會發現有不少能夠提取的公共組件。

二、全局樣式污染問題優化

當組件抽象夠多，拆分夠細後，注意一下樣式污染問題，我接觸的項目直接走style hash時候居多，但這裏推薦classnames插件，拼接業務惟一標識到className前面，這樣比直接用hash更好調試，而且每一個組件就算格式同樣 className 起名字同樣也不會混淆。

使用方式：
npm i classnames --save
設置公共方法

組件中使用的時候

三、渲染次數優化

這個問題我在《跟你們聊一下前端性能怎麼優化》那篇文章中提到過，在目錄四-2。

問題的解決方法在於合理觸發render。

二、數據抽象-邏輯解耦

這兩個詞語有些官方了，大概的意思爲‘拆’。拆完再合併。

上面說了組件抽象的時候咱們規定250行左右。方法定製在100行。相信你們也總會見到不少龐大的方法，這種方法仔細分析的話必定是摻雜了業務在裏面，並無把單獨邏輯與業務分開來維護，使得這種方法即便寫了備註，一動則牽引全身，修復完一個問題，出來10個問題，這就很恐怖了。

因此咱們規定方法不準超過100行，若是你的方法超過100行，就說明能夠拆分紅兩個或幾個更小的邏輯的組合。

這種稱之爲邏輯解耦，咱們拆完以後會發現不少的邏輯實際上是同樣的，這時候就能夠進行數據抽象，提取公共方法，沉澱成公共方法庫，編寫好備註，使用文檔。咱們就能夠很好的進行之後的維護，繼承，修改等等工做。好久之前這種方法庫我都是放u盤裏隨身攜帶...

這裏重點：jsinspect，上述中的組件抽象及邏輯抽象均可經過此插件來整理，設定好排查路徑，則會直接生成一個文件列表，告訴你哪裏和哪裏是類似的能夠抽象，很是好用。

替換一下src路徑便可，執行npm run check:json 就會在根目錄下生成jsinspect.json文件，裏面整理的很詳細。

三、 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，一勞永逸。

四、全部節點需有惟一識別key

這一點來講也是蠻重要的，如今不管react，vue，angular，都是組件化開發模式，在這種模式下，底層原理都是構造虛擬樹的diff算法，用來判斷哪些組件重繪，哪些不用重繪。

一般的DOM元素的key是自動生成的。然而，在何時會有問題呢？舉個例子

我須要渲染一萬條數據，後臺沒返回惟一識別id，用角標代替

這樣，咱們的數據的key爲「0、一、二、...」，表面上看沒什麼問題。若是咱們進行刪除操做，刪除第一條數據，那麼重繪的時候key就會從新排列，曾經的第二條就變成了第一條，key變爲了0，以此類推，diff算法用key斷定是否是相同DOM節點，而後比較內容，剩下的9999條數據的內容跟上次記錄的樹全變了，由於對比的時候是拿上次第一條數據的內容去比較如今第二條數據的內容，由於第二條數據的key變成了0，不知道我闡述明白沒有。因此會重繪9999個DOM節點。

那麼：若是key是惟一的

對比key以後對比內容，就不會重繪9999個DOM，只是單獨刪除掉了第一個dom元素而已。新增功能於此相同。因此你們要注意一下惟一值key的問題。

五、 prettier

此插件用來格式化代碼，使代碼哪怕在開發的時候格式混亂，是吧，編譯一下，就會變成統一格式。很是適合團隊開發使用。

這個時候有些同窗可能會有個疑問，個人開發工具，好比vscode，能夠下載開發工具插件，如圖。

開發工具中也能夠裝一些插件輔助你開發，可是這個，只能輔助你本身，若是你的同事沒有裝，或者裝了跟你配置的不同，那麼就很是不理想了，因此說，仍是在項目中配置eslint，prettier等規範爲上策。

4、Git角度

一、precommit

經過git precommit鉤子，每一個人在上傳代碼的時候作一層攔截，保證上傳到gitlab上的代碼質量。

這裏話很少說，你們看完package.json配置就懂了

一、husky：對 git 進行 hook，能夠在 git 操做以前作一些操做；二、lint-staged：對當前 git 提交的代碼進行一些操做。

直接按照我這樣配置好就能夠了，每次上傳代碼的時候都會走一遍上述所說的eslint、stylelint、prettier等規範。固然也能夠自定義一些操做。

二、merge request

鎖定master分支，其他代碼想合併到master 的時候，須要提交merge request，而後須要進行代碼評審，至少兩我的，經過評審才能夠將代碼合併到master分支。咱們的大型項目都是這種模式，十分嚴謹。你們還能夠相互學習寫法，探討思路，此功能gitlab自帶，配置一下就好，有須要的能夠去了解一波。