[[397344]]

【51CTO.com快譯】您是否經(jīng)歷過(guò)編寫(xiě)代碼的困惑?您的代碼庫(kù)是否存在著前后不一致的現(xiàn)象?在每次審核代碼時(shí)，您是否會(huì)感到焦慮?如果您對(duì)這些問(wèn)題的任何一項(xiàng)回答為“是”的話，那么靜態(tài)代碼分析應(yīng)該能夠?yàn)槟峁椭?/p>

所謂靜態(tài)代碼分析，是指在執(zhí)行代碼之前，對(duì)其進(jìn)行分析的過(guò)程。通過(guò)集成靜態(tài)代碼分析器，開(kāi)發(fā)人員可以優(yōu)化整個(gè)工作流程。

本文將向您介紹什么是JavaScript靜態(tài)代碼分析，為什么要使用它，以及如何在項(xiàng)目中通過(guò)快速設(shè)置來(lái)實(shí)現(xiàn)它。

什么是靜態(tài)代碼分析?

顧名思義，靜態(tài)代碼分析是對(duì)處于靜態(tài)、或非執(zhí)行狀態(tài)的代碼進(jìn)行分析。它在效果上等同于讓另一名開(kāi)發(fā)人員去閱讀和審查您的代碼。當(dāng)然，其效率可能不及自動(dòng)化工具。

與測(cè)試有何不同?

無(wú)論是單元測(cè)試、功能測(cè)試、集成測(cè)試、視覺(jué)測(cè)試、還是回歸測(cè)試，所有這些類型的測(cè)試都是通過(guò)運(yùn)行代碼，將結(jié)果與已知的預(yù)期輸出狀態(tài)進(jìn)行比較，以檢查是否一切正常。可以說(shuō)，測(cè)試是將您的代碼視為黑盒子，通過(guò)為其提供輸入，來(lái)驗(yàn)證執(zhí)行后的輸出，以確保代碼能夠按照預(yù)期運(yùn)行。

然而，靜態(tài)代碼分析主要是針對(duì)程序代碼的可讀性、一致性、錯(cuò)誤處理、類型檢查、以及縮進(jìn)排版等方面進(jìn)行分析。可以說(shuō)，靜態(tài)分析并非關(guān)注代碼能否提供預(yù)期的輸出，而是關(guān)注代碼本身的編寫(xiě)方式。它是對(duì)源代碼質(zhì)量(而非功能性)的分析。

總而言之，測(cè)試著眼于檢查代碼是否有效，而靜態(tài)分析則會(huì)檢查代碼是否編寫(xiě)正確。在理想情況下，您應(yīng)該在項(xiàng)目中，讓測(cè)試和靜態(tài)分析相輔相成。

為什么要使用靜態(tài)代碼分析?

從程序格式化小工具，到漏洞掃描器，甚至程序?qū)彶槠鳎魏文軌蜃x取源代碼，對(duì)其進(jìn)行解析，并提出改進(jìn)建議的工具，都屬于靜態(tài)代碼分析器。下面，讓我們看看有哪些工作場(chǎng)景會(huì)用到靜態(tài)代碼分析。

全面審查

人是會(huì)犯錯(cuò)的。據(jù)統(tǒng)計(jì)，只有15%的JSHint(一種流行的JavaScript代碼審查工具)代碼庫(kù)的安裝過(guò)程，能夠順利通過(guò)。正所謂“當(dāng)局者迷，旁觀者清”，“第二雙眼睛”往往可以發(fā)現(xiàn)您在自己的代碼中，那些永遠(yuǎn)不會(huì)察覺(jué)到的問(wèn)題。據(jù)此，開(kāi)發(fā)人員不但可以了解項(xiàng)目中的某些內(nèi)置功能，而且能夠提出更好、更便捷的實(shí)現(xiàn)方法。

那么，我們是否能引入更多的“眼睛”、更全面的“掃描”呢?通常，靜態(tài)分析器是由龐大的開(kāi)源社區(qū)提供支持的。這就意味著，所有為該工具做出貢獻(xiàn)的人，都可以間接地檢查了您的代碼，以發(fā)現(xiàn)任何遺漏的錯(cuò)誤。

例子：

如下代碼段展示了一個(gè)讓用戶挑選水果的例子。如果用戶不做選擇，則默認(rèn)為“Mango”。

let fruits = ['Apple', 'Banana', 'Cherry', 'Mango'] 
function getFruit(index) { 
    index = index || 3 // Everybody likes mangoes 
    return fruits[index] 
} 

只要用戶的輸入不為0，那么各種測(cè)試都能順利通過(guò)。

getFruit()  // Mango 
getFruit(2) // Cherry 
getFruit(0) // Mango (expected Apple!) 

而由于0的存在，用戶無(wú)法選擇Apple。因此針對(duì)null和undefined之類的虛假值(falsy value)，您應(yīng)該改用null-coalescing(空值合并)運(yùn)算符--??(請(qǐng)參見(jiàn)如下代碼段)。

let fruits = ['Apple', 'Banana', 'Cherry', 'Mango'] 
 
function getFruit(index) { 
 
index = index ?? 3 // Everybody likes mangoes 
 
return fruits[index] 
 
} 

風(fēng)格統(tǒng)一

每個(gè)開(kāi)發(fā)人員都可以采用自己的風(fēng)格去編寫(xiě)代碼。但是，在許多開(kāi)發(fā)人員需要協(xié)同工作時(shí)，通過(guò)風(fēng)格指南的一致性來(lái)約束大家的編程，就顯得極為重要了。不過(guò)，我們不可能要求開(kāi)發(fā)人員記住指南中的數(shù)百條規(guī)則，并依靠人工進(jìn)行逐行對(duì)照與檢查。因此，我們需要依靠自動(dòng)化來(lái)完成。

每一種語(yǔ)言都有自己的代碼校驗(yàn)器(lint)，例如：JavaScript有ESLint(https://eslint.org/)、Python有Black(https://black.readthedocs.io/en/stable/)、而Ruby有RuboCop(https://github.com/rubocop-hq/rubocop)。這些校驗(yàn)器可以確保您的代碼遵循相關(guān)的風(fēng)格規(guī)則，進(jìn)而讓代碼更加整潔。例如，RuboCop便可以通過(guò)檢測(cè)和修復(fù)錯(cuò)誤，以確保函數(shù)與變量名具有更好的原子一致性。

例子：

如下JavaScript代碼段，旨在從列表中打印水果的名稱。同時(shí)，該列表在整個(gè)程序中應(yīng)保持不變。

var fruits = ['Apple', 'Banana', 'Cherry', 'Mango'] 
console.log(fruits[0]) 

通過(guò)配置，ESLint可以確保盡可能地使用常量，以避免對(duì)代碼產(chǎn)生副作用。

const fruits = ['Apple', 'Banana', 'Cherry', 'Mango'] 
console.log(fruits[0]) 

如上述代碼所示，倘若我們用let和const兩個(gè)關(guān)鍵字來(lái)替換var，則會(huì)讓代碼更加易于調(diào)試。

立即發(fā)現(xiàn)問(wèn)題

以測(cè)試為驅(qū)動(dòng)的開(kāi)發(fā)實(shí)踐，往往強(qiáng)調(diào)編寫(xiě)各種用于測(cè)試的用例。但是，為了盡可能地覆蓋所有輸入，開(kāi)發(fā)人員需要花費(fèi)時(shí)間和精力去編寫(xiě)測(cè)試用例。最終，測(cè)試用例不但十分臃腫，而且需要花費(fèi)數(shù)小時(shí)，才能完成大型代碼庫(kù)的構(gòu)建。

而靜態(tài)代碼分析器則不會(huì)遇到此類問(wèn)題。您不需要編寫(xiě)測(cè)試用例，即可導(dǎo)入整個(gè)預(yù)設(shè)的代碼庫(kù)。同時(shí)，由于無(wú)需執(zhí)行代碼，因此靜態(tài)分析器的運(yùn)行速度會(huì)更快。實(shí)際上，許多代碼校驗(yàn)器都能夠與代碼編輯器相集成，并在您輸入代碼時(shí)，實(shí)時(shí)地突顯代碼中的問(wèn)題。

例子： 

大多數(shù)靜態(tài)分析器，尤其是linters和formatter，不僅會(huì)指出代碼問(wèn)題，而且可以解決問(wèn)題。同時(shí)，諸如Python的Black和JavaScript的ESLint還能夠與IDE相集成。在用戶保存代碼時(shí)，它們便可以自動(dòng)修復(fù)當(dāng)前已編輯的文件。這種實(shí)時(shí)提高代碼質(zhì)量的方式，已廣受開(kāi)發(fā)者的歡迎。

例子：

ESLint帶有一個(gè)可用來(lái)修復(fù)常見(jiàn)問(wèn)題的參數(shù)—fix，可用來(lái)修復(fù)：不必要的分號(hào)、尾部空格、以及多余的逗號(hào)。在如下代碼段中，一個(gè)·代表著一個(gè)空格。

var fruits = [ 
    'Apple', 
  'Banana', 
  'Cherry',·· 
    'Mango' 
]; 

而在運(yùn)行了帶有—fix的ESLint后，代碼會(huì)變成：

const fruits = [ 
    'Apple', 
    'Banana', 
    'Cherry', 
    'Mango', 
] 

修復(fù)依賴項(xiàng)

在構(gòu)建應(yīng)用程序時(shí)，您不可避免地會(huì)用到由其他開(kāi)發(fā)人員所構(gòu)建的框架和工具。當(dāng)然，其他開(kāi)發(fā)人員也可能會(huì)用到更多第三方的框架。如此下去，就算是一個(gè)簡(jiǎn)單的Vue.js應(yīng)用，也可能在其node_modules/的目錄中，被放置了成千上萬(wàn)個(gè)軟件包。

然而，在這種“疊羅漢”式的依賴鏈中，您的應(yīng)用程序會(huì)受到最薄弱的依賴性的制約。而作為另一種靜態(tài)分析器的漏洞掃描程序，正好可以通過(guò)強(qiáng)大的漏洞簽名數(shù)據(jù)庫(kù)的優(yōu)勢(shì)，對(duì)依賴關(guān)系樹(shù)中的每個(gè)依賴項(xiàng)進(jìn)行檢查。而所有被發(fā)現(xiàn)的漏洞，都能夠被掃描程序通過(guò)一條命令，來(lái)予以更新和修復(fù)。

例子：

GitHub會(huì)使用Dependabot來(lái)掃描依賴項(xiàng)。而npm會(huì)使用npm audit命令來(lái)掃描漏洞。Dependabot和npm audit在它們的新版本中，都提供了帶有自動(dòng)化漏洞修復(fù)功能的更新包。

自動(dòng)化重復(fù)性事務(wù)

相對(duì)于繁瑣地手動(dòng)遍歷與審查代碼，各種linter、formatters、以及拼寫(xiě)檢查器(spell checkers)能夠大幅簡(jiǎn)化整個(gè)過(guò)程。那么它們又是怎么實(shí)現(xiàn)的呢?首先，預(yù)提交的鉤子(pre-commit hook)將確保在檢入VCS(版本控制系統(tǒng))之前，對(duì)代碼已進(jìn)行校驗(yàn)和格式化。其次，構(gòu)建管道或GitHub工作流形式的項(xiàng)目級(jí)自動(dòng)化，會(huì)在每次提交時(shí)檢測(cè)代碼的質(zhì)量，并突顯代碼自身的問(wèn)題。最后，由于代碼的各種小問(wèn)題已經(jīng)被處理了，因此審查人員可以去關(guān)注代碼邏輯等其他問(wèn)題。可見(jiàn)，軟件自動(dòng)化不但可以減少人工的工作量，還能夠提高審查的速度，以及遍歷的覆蓋率。

項(xiàng)目示例

下面，讓我們來(lái)逐步創(chuàng)建一個(gè)項(xiàng)目示例。首先，我們?yōu)轫?xiàng)目創(chuàng)建一個(gè)新的目錄。在該目錄中，我們通過(guò)npm init向?qū)?如下圖所示)，逐步完成Node.js包的初始化。

$ mkdir wuphf.com 
$ cd wuphf.com 
$ npm init 

我們使用如下簡(jiǎn)單的命令來(lái)安裝ESLint。

$ npm install eslint 

我們運(yùn)行如下命令，來(lái)激活ESLint向?qū)А?/p>

$ ./node_modules/.bin/eslint --init 

該向?qū)?huì)通過(guò)與您的互動(dòng)，完成在項(xiàng)目中如何使用ESLint的相關(guān)問(wèn)題。此本例中，請(qǐng)選擇Airbnb的規(guī)則集。在完成設(shè)置后，該目錄中將出現(xiàn)一個(gè).eslintrc.js的文件。

下面的代碼段展示了一個(gè)控制臺(tái)應(yīng)用。在此，我們可以自定義規(guī)則，并關(guān)閉針對(duì)它的各種警告。

module.exports = { 
  env: { 
    es2021: true, 
    node: true, 
  }, 
  extends: [ 
    'airbnb-base', 
  ], 
  parserOptions: { 
    ecmaVersion: 12, 
  }, 
  overrides: [ 
        { 
      files: ['*.js'], 
      rules: { 
        'no-console': 'off', 
      }, 
    }, 
    ], 
}; 

最后，我們將此文件提交到版本控制系統(tǒng)中，以便ESLint持續(xù)掃描項(xiàng)目中的所有JS文件。此外，我建議您通過(guò)安裝Husky(https://typicode.github.io/husky/#/)，以實(shí)現(xiàn)在每次提交之前，運(yùn)行一次代碼校驗(yàn)的作業(yè)，以保證不會(huì)有不良的代碼被檢入VCS中。

使用DeepSource來(lái)實(shí)現(xiàn)自動(dòng)化

作為一個(gè)靜態(tài)代碼分析器，DeepSource(https://deepsource.io/)可以在代碼庫(kù)中查找問(wèn)題，并自動(dòng)修復(fù)它們。目前，它可以支持大多數(shù)主流編程語(yǔ)言，并能夠集成到GitHub、GitLab和Bitbucket中。為了在項(xiàng)目中設(shè)置DeepSource，您可以將名為.deepsource.toml的文件放置在存儲(chǔ)庫(kù)的根目錄中，以便對(duì)項(xiàng)目進(jìn)行持續(xù)掃描。

原文標(biāo)題：Beginner's Guide to JavaScript Static Code Analysis，作者：Dhruv Bhanushali

【51CTO譯稿，合作站點(diǎn)轉(zhuǎn)載請(qǐng)注明原文譯者和出處為51CTO.com】