如果你問開發(fā)團(tuán)隊(duì)，他們的主要目標(biāo)是什么，三個(gè)最常見的答案可能包括：

• 編寫無錯(cuò)誤的代碼。
• 符合設(shè)計(jì)規(guī)范。
• 規(guī)避安全問題。

那么，團(tuán)隊(duì)如何審查代碼以確保這三個(gè)主要目標(biāo)都得到滿足?

答案很簡(jiǎn)單，是代碼分析。但它應(yīng)該是靜態(tài)代碼分析?還是動(dòng)態(tài)代碼分析?或者兩者結(jié)合?

不妨看看靜態(tài)代碼分析和動(dòng)態(tài)代碼分析如何在開發(fā)中發(fā)揮重要作用，以及它們的差異如何有助于規(guī)范代碼。

靜態(tài)代碼分析和動(dòng)態(tài)代碼分析有何不同?

靜態(tài)代碼分析檢查代碼，以識(shí)別邏輯和技術(shù)中的問題。動(dòng)態(tài)代碼分析則運(yùn)行代碼和檢查結(jié)果，這還需要測(cè)試代碼可能存在的執(zhí)行路徑。

即使采用最基本的方式，當(dāng)開發(fā)團(tuán)隊(duì)測(cè)試代碼時(shí)，他們是在執(zhí)行動(dòng)態(tài)分析。而當(dāng)程序員審查代碼時(shí)，則是在執(zhí)行靜態(tài)分析。無論使用哪種工具，開發(fā)人員和程序員都在執(zhí)行分析，最終有助于創(chuàng)建更好的代碼。

靜態(tài)代碼和動(dòng)態(tài)代碼本身都不是理想的選擇，這意味著團(tuán)隊(duì)?wèi)?yīng)優(yōu)化兩者。開發(fā)團(tuán)隊(duì)不能將靜態(tài)代碼分析和動(dòng)態(tài)代碼分析視為非此即彼的關(guān)系，而是應(yīng)將它們視為互補(bǔ)和共生的關(guān)系。

代碼審查類似靜態(tài)分析

如果由于某種原因，團(tuán)隊(duì)決定略過靜態(tài)代碼分析，那其實(shí)意味著團(tuán)隊(duì)計(jì)劃不審查代碼。代碼審查和靜態(tài)代碼分析好比是相關(guān)的術(shù)語。代碼審查有助于發(fā)現(xiàn)代碼問題，無需進(jìn)行費(fèi)時(shí)又費(fèi)錢的動(dòng)態(tài)測(cè)試。在代碼審查環(huán)境下進(jìn)行的靜態(tài)代碼分析是開發(fā)和維護(hù)優(yōu)秀軟件的第一步，也是最重要的一步。

大多數(shù)靜態(tài)代碼分析是使用旨在評(píng)估代碼，查找錯(cuò)誤或不推薦的技術(shù)和實(shí)踐的工具完成的。將靜態(tài)代碼分析視為代碼審查要素的組織可能會(huì)先進(jìn)行正式的代碼審查，然后運(yùn)用靜態(tài)代碼分析工具，最后借助選擇的代碼審查流程審查結(jié)果。

如果機(jī)構(gòu)決定先與程序員和導(dǎo)師一起審查代碼，它們可能會(huì)考慮先使用靜態(tài)代碼分析。這種方法可能會(huì)揪出至少 85% 的代碼錯(cuò)誤，為專家省下識(shí)別錯(cuò)誤的寶貴時(shí)間。

靜態(tài)代碼分析和審查特別適合快速開發(fā)和 GitOps 環(huán)境：在這種環(huán)境下，常常對(duì)單個(gè)組件進(jìn)行更改。比如說，如果軟件設(shè)計(jì)適當(dāng)?shù)馗綦x了組件行為，靜態(tài)分析可以揪出大部分代碼錯(cuò)誤。

為什么進(jìn)行動(dòng)態(tài)分析呢?

簡(jiǎn)而言之，靜態(tài)分析無法揪出每個(gè)代碼缺陷。

解決復(fù)雜的多組件應(yīng)用程序中的問題時(shí)，靜態(tài)分析尤其受到限制。當(dāng)您想要衡量性能或測(cè)試用于擴(kuò)展及(或)負(fù)載均衡的策略時(shí)，它幾乎失去價(jià)值。面對(duì)這些限制，動(dòng)態(tài)代碼分析就有了用武之地。

協(xié)調(diào)動(dòng)態(tài)分析和靜態(tài)分析

正如開發(fā)團(tuán)隊(duì)已經(jīng)經(jīng)常使用靜態(tài)代碼分析——即使這種分析不是正式規(guī)定或管理的，他們也使用動(dòng)態(tài)代碼分析。常規(guī)軟件測(cè)試和運(yùn)行軟件以驗(yàn)證修正版或驗(yàn)證初始實(shí)現(xiàn)機(jī)制是動(dòng)態(tài)代碼分析的幾種形式。

因此，這不是靜態(tài)代碼分析與動(dòng)態(tài)代碼分析兩者擇其一的問題。團(tuán)隊(duì)可能已經(jīng)使用了兩者。問題變成了如何有效地使用兩者。

靜態(tài)代碼分析最好與代碼審查結(jié)合使用。動(dòng)態(tài)代碼分析適用于某種形式的自動(dòng)化測(cè)試和測(cè)試數(shù)據(jù)生成。

團(tuán)隊(duì)?wèi)?yīng)先將動(dòng)態(tài)代碼分析的重點(diǎn)放在靜態(tài)分析可能無效的方面，比如組件性能、應(yīng)用程序性能、應(yīng)用程序邏輯、安全驗(yàn)證和跨組件邊界。比如說， Redgate SQL Data Generator 和DTM Data Generator (僅舉幾例)等自動(dòng)化測(cè)試數(shù)據(jù)生成工具可模擬應(yīng)用程序在滿負(fù)荷下的操作、驗(yàn)證所有邏輯路徑，并測(cè)試這些點(diǎn)是否存在安全漏洞。一些機(jī)構(gòu)可能已經(jīng)在使用這些工具，但重要的是，它們可以用來測(cè)試靜態(tài)分析極有可能遺漏的特定方面。

使用唾手可得的工具和實(shí)踐很容易實(shí)現(xiàn)性能和負(fù)載測(cè)試的自動(dòng)化。面對(duì)任何形式的生成數(shù)據(jù)自動(dòng)化測(cè)試，設(shè)置邏輯和安全驗(yàn)證比較困難。團(tuán)隊(duì)需要強(qiáng)調(diào)測(cè)試設(shè)計(jì)，并認(rèn)真選擇具有特定字段值約束的數(shù)據(jù)生成工具，以運(yùn)行識(shí)別潛在問題的測(cè)試。在安全驗(yàn)證方面，團(tuán)隊(duì)?wèi)?yīng)將測(cè)試數(shù)據(jù)范圍值擴(kuò)大到正常操作之外，以確保它們不會(huì)帶來潛在的問題。

靜態(tài)代碼分析與動(dòng)態(tài)代碼分析之爭(zhēng)表明了許多注重單個(gè)步驟而不是整個(gè)過程的開發(fā)策略存在缺陷。靜態(tài)代碼分析和動(dòng)態(tài)代碼分析都扮演重要的角色，它們都是整體的開發(fā)和部署流程的一部分。少了任何一方，另一方都不可能獨(dú)立完成。

原文標(biāo)題：Static and dynamic code analysis: Complementary techniques，作者：Tom Nolle