靜態分析的概念已經提出多年，而在過去的幾年裏利用該工具評估和診斷代碼的技術已日趨成熟。幾乎每種語言都存在相應的軟件審查工具。這些審查可以在多個領域，如數組，循環，編碼風格，設計，複製代碼，命名風格，性能等領域中隔離出不良代碼。而在每一個層級中又存在另一套完整的審查可供程序員使用。
這裏要提醒大家，程序員可能會因審查報告過多漏洞而感到厭煩。筆者曾經看到過一個有20萬行的應用程序，用現在的標準來衡量，這當然不算多，此外還運行了200+審查。該報告列出了35萬個需要修復的違規之處，這樣以來的確是有些麻煩。
要想成功使用審查，關鍵是要限定審查套組的量。這個量視情況而定，程序員應該把握好這個量，才能事半功倍。
我們通常會推薦程序員和其團隊從小的有限審查開始，先修復各種常見問題。
審查最令人激動的一點是它可以爲我們提供代碼信息以及代碼的構成。僅因爲報告指出某一行出現異常，這並不意味着它就是真正的問題所在。一個好的工具應該能夠將所報告的問題做上已驗證的標記;可以在註釋中標明，這樣審查工具就明白該區域已經被查看過了。
那麼什麼時候可以使用審查呢?建議每晚或進行整合構建的時候都可以運行審查以便保證程序的運行，尤其是當代碼的編寫不夠嚴格或剛剛編寫完不久的情況下。運行已有代碼中的Software Archeology時至少應該運行一次代碼，而重構進程的時候則要一直運行審查。
本文介紹的五個審查工具分別是Numerical Literal in Code，String Literal，God Method，Shotgun Surgery和Duplicate Code。
Numerical Literal in Code
這是最簡單的重構方法之一。我們已經寫出這樣的代碼：
| double salaryCalc(double salary){
return salary*1.34564333721 } C++ |
兩個月後，我們要更新salaryCalc方法，而客戶查看代碼的時候則遇到了困難。很可能他們不記得方法最開始的寫法了，所以不明白1.34564333721代表着什麼。最好是用字符常量來代替數字。這樣就賦予了數字有意義的名稱，如下所示：
| double salaryCalc(double salary){
Return salary* BONUS } Static final double BONUS = 1.34564333721 C++ |
String Literal
我們都知道，時間緊迫的時候，我們可能要改變代碼，並使其能儘快投入運營。String Literal就派上用場了。該審查特別適用於要將軟件國際化的任務。需要經常運行該審查。單元測試不應發生改變，結果也要保持一致。
這個不正確：
public const helloWorldMessage: String = ‘Hello World!’;
Delphi
這個才正確：
Public const helloWorld Message: String =
resourceManager.GetString(‘msg.helloworld’);
Delphi
這個方法將會對應用程序外能夠被改變的資源包中的helloWorldMessage字符串進行檢索，並在不重新編譯的情況下進行更正。
God Method
God ‘X’審查，‘X’相當於Method，Class。該審查不僅僅是查看代碼，然後指出不足。
對這一類審查的概括可總結爲god Method;簡而言之，我們擁有一個類，這個類包含了50個方法，但是隻有一個方法恰好能完成所有工作。那麼這個方法就要被標記爲god Method。
順便說一下，大多數god ‘X’情況都不是這樣開始的。在god Methods的情況中，它們通常會以常規的簡單方法開始，但是隨着時間的推移，功能越來越多，方法要負責的方面也越來越多，因此慢慢成爲了功能齊全的God Method。
那麼什麼樣的計算用於指明哪一種方法比其他方法的功能更多呢?通常計算所涉及三種主要審查和一套代碼都是用於確定其狀態。這三種審查包括Long Methods，Long Parameters和Switch語句。四種基本代碼包括：程序編碼行，參數量，本地變量數以及分支指令的最大數。
把這些數放在一起就可以看到計算是如何運行的。Long Methods通常意味着執行一個以上的操作，Long Parameters較難理解，Switch語句代表代碼中的不同路徑。通過在程序編碼行加入要與其他方法進行對比的方法，然後驗證參數量，本地變量數以及分支指令的最大數，它就可以計算出到底哪個纔是Gog Method。
當我們分離出God Method後，又該怎麼辦呢?這時候會產生許多重構器，如Extract Method，Introduce Parameter Object等。目的是要確定該方法按照預計的方式在執行。
Shotgun Surgery
該審查是筆者最喜歡的審查之一，不僅是因爲它的名字很酷，還因爲它可以幫助程序員節約大量時間。和god ‘X’審查一樣，該方法也使用代碼來計算其結果。
大家有沒有嘗試過用需要修改的一行代碼來隔離一個方法呢?如果使用shotgun surgery審查，將節約很多時間。因爲該審查會查看代碼中依賴某方法的位置。這意味着你將知道某一行的更改將改變整個代碼基礎，你最好是在更改代碼行之前仔細考慮清楚。
要用來幫助shotgun surgery方法進行計算的另外兩個方法分別是Changing Methods和Changing Classes。Changing 方法審查是緊密相關的方法數，Changing 類是更改方法的時候受到影響的類。因此可以將shotgun surgery審查視爲依賴於小型方法的檢查。
所以，如果你所擁有的方法中包含了shotgun surgery，該怎麼辦?很簡單，看清楚代碼，找到下屬的小型方法，然後查看預定的更改要對系統做些什麼操作。
Duplicate Code
曾幾何時，筆者認爲 複製/粘貼 功能應該從編輯器中清楚。我們使用這一功能的頻率令人吃驚。這種方法導致我們複製了大量不良代碼。
而複製不良代碼所帶來的最嚴重問題就是維護了。使用這個審查我們要能夠尋找到那些只做過稍微修改的代碼。很多工具在審查返回信息前會說明有十行，或更多行代碼需要被複制。推薦大家將複製數量的設置降到三或四行。
一旦程序員隔離出複製代碼，那麼一組標準的重構方法就可以發揮其作用，通常Extract Method或Pull Up Field可以做到這一點。
如下所示，一個這樣的If語句：
| if (int x=0; x< 100; x++{
//other statements someValue = 10; } else { //other statements someValue = 10; } Java |
| if (int x=0; x < 100; x++{
//other statements } else { //other statements } someValue = 10; Java |
現在有很多的審查可供選擇。記住當你要開始審查的時候，先選擇小一點的和那些能快速給出反饋信息的。
審查是程序員容易忽視的工具。花些時間找到一些適合自己的審查，將會節省很多開發時間。