一、 引言

谷歌發布的代碼規范中指出，80% 的缺失是由 20% 的代碼所引起的。規范的代碼可以消除過于強烈的個人風格，有助于代碼在項目間高效的流轉；提升代碼的正確性，降低低級問題產生的可能性；同時也降低了項目的維護成本。良好的編碼習慣，可以促進團隊的合作，可以減少莫名的bug，可以降低代碼維護的成本，可以降低代碼審查的難度，可以提升代碼的健壯性，助力整個團隊代碼品質的提升。
　　但相當多團隊的代碼規范只是一份文檔，原因在哪里呢？通過一些研發人員的調研，得到圖1的數據。圖1 代碼規范落地難原因調查1、不想改占比69.77%，主要原因為：
● 人工review代碼太浪費時間，項目太趕，沒時間。
● 我也知道這么寫不好，可既有代碼就是這么寫的，只改一處也沒用。
● 有些規范也很差，還不如我寫的規范。
● 不能全盤進行代碼規范的落地，都是暫時性工作，沒啥效果。
2、不愿改占比18.60%，主要原因為：
● 代碼規范就是浪費時間，沒用。
3、不會改占比11.63%，主要原因為：
● 實現不太好，缺乏指引。
　　縱觀以上數據發現代碼規范的落地的確是一個復雜的問題，既有組織層面上對代碼規范重要性、必要性、一致性認知的缺失，也有缺乏高效可落地的檢測工具，另外對新人組織宣貫的缺失也是問題。那就需要從組織層面、工具層面、培訓層面抽絲剝繭的來逐層將問題個個擊破，確保規范的有效，準確落地執行。二、 代碼規范落地實踐2.1. 組織建設為保證規范落地的準確性和有效性，建議以圖2 組織形式組織角色。圖2組織角色及職責● 技術委員會，建議系統架構師，技術帶頭人，技術經理參與，負責規范、規則梳理、評審、引入已經新增規范的代碼編寫。是規則的制定者、是仲裁。
● 執行小組，建議QA、PMO、QC人員參與，負責項目數據的整理，問題的跟蹤、改進效果展示，反饋問題的收集。階段性對引進的新規范，有爭議規范以及爭議問題的評審。階段性更新代碼編碼規范，是此項活動的裁判員。
● 項目接口人，項目接入，項目構建，掃描結果分析、修正，以及爭議問題反饋。項目成員是此項活動的主體即運動員。
　　因為專業的事必須交給專業的人來做，代碼規范的制定應該由在一線摸爬滾打很多年的程序員主導，由多人參與共同制定，技術委員會可以是一個虛擬的組織，由一線的開發經理組成，盡量貼近業務。2.2. 運營思路在運營過程中我們大致規劃了三個階段：
● 規范做成：吸收既有規范，如阿里的JAVA代碼規范、規范插件等從嚴重等級，影響范圍維度梳理，將核心的、易識別、爭議少的代碼規范留存至規則共享平臺。但每條規范的通過需由技術委員會評審通過，在組織內部達成一致。此過程是吸收內化的過程，可保障每條規范的有效性。對規范的制定要公開透明，規范內容要細致深入，針對代碼規范每一條的詳細解釋，說清楚為什么要這么制定代碼規范，它背后有哪些技術上和工程過程中的故事，說得人心服口服，用技術說服。
● 規范發布：由規則共享平臺導出代碼規范文檔1.0版本，內部宣貫。并通過工具化，服務化的手段將將發布的代碼規范可自動化的檢測，反饋。通過IDE插件或能力集成的方式將檢測的能力集成至pipline當中，形成研發的質量門檻，保障其質量規范的切實執行。此期間可通過質量評分、質量排名等曝光手段推動規范的落地。
● 規范運維：持續運維，納入質量體系。通過開發反饋，QA統計匯總反饋，技術委員會評審和裁定，落地代碼規范，持續監督，定期更新。此階段在代碼規范已經較穩定運行后，依據規則共享平臺的反饋對代碼規范進行增刪，以此保障代碼規范的更新迭代。技術更新很快，工程過程中遇到的問題也是層出不窮，因此，代碼規范也不會是一招定論的，需要不斷地更新、補充、完善，這樣才能與時俱進，保持生命力。
　　通過全員參與形成完備的閉環回路，通過專家評審形成統一認識，通過規范標準的建立達成質量標準的認識。周期性的反饋，不斷完善規范的版本，達到代碼規范的落地實施。2.3. 工具平臺僅僅有組織支撐，規范指導是不夠的，必須有簡單易用的賦能工具，向開發人員提供檢測工具或者插件，自動化實現對于代碼規范是否執行到位的檢測，而不是依靠人工。2.3.1. SonarQube以入門簡單的SonarQube示例，其實有眾多的代碼檢測工具可供選擇如：Flawfinder、Checkstyle或者商業的Coverity作為掃描的引擎，將掃描引擎集成至開發的pipline當中，無感知的提供服務進行代碼的分析、度量、反饋。通過不同的對掃描結果進行加工處理，以量化的方式度量代碼質量的變化，從而可以方便地對不同規模和種類的工程進行代碼質量管理。圖3 示例流程設計圖通過對代碼倉庫、掃描引擎、集成工具和規則共享平臺進行集成，我們很簡單的搭建出面向多角色的一體化框架，從而滿足各類需求。
　　(1)開發者將代碼提交到svn工具；
　　(2)持續集成工具Jenkins自動觸發檢查代碼執行源碼掃描、分析；
　　(3)分析報告傳遞給SonarQube server進行加工處理；
　　(4)SonarQube進行處理分析、將數據保存到數據庫中；
　　(5)SonarQube服務將分析結果推送至規則共享平臺進行UI展現；
　　(6)規則共享平臺也能夠將新的代碼掃描規范配置到SonarQube服務；
　　(7)平臺可將掃描結果反饋至相關項目組，提醒及時修改；
　　(8)項目經理、開發經理、運維經理、測試經理等通過共享平臺進行代碼相關報表的查看和管理，技術專家可通過平臺定制相關規則。2.3.2. 規則共享平臺通過規則共享平臺產出代碼規范以及落地實施，規則的產出和準實時監控則是核心。代碼規范的評審，監督，統計全部通過規則共享平臺完成。
　　平臺實現三個功能：
　　1、規則評審，對規則錄入，審核，實施，廢棄。
　　2、每次代碼變更實施后進行規則掃描，并統計起結果，對存量、新增問題進行統計分析。為后續的規范增刪打下元數據基礎。
　　3、對項目在時間段內的違規統計。
　　實現規則的生成，評審，生效，監督，廢棄完整生命周期的管理，為全員規則的生成、審核打下基礎。
　　此平臺受眾為三種角色，開發者，開發經理、技術委員會，他們的所想所得用以下表格梳理：表1 規則共享平臺角色定位1、面向開發者：每次提交代碼后10min內得到代碼規范郵件反饋結果。圖4 示例項目代碼規范郵件反饋結果注：BUG即規范沖突點，漏洞為安全規范。鏈接直接提供修改方案，解決“怎么改”的問題。圖5 檢測摘要圖5為單次的檢測摘要，可將全量以及增量問題落地。進入詳情頁后，展示問題的級別(阻斷，嚴重，主要，次要，提示 五級)，以及問題的分布。并展示問題位址(文件名以及行數)如圖6，以及問題原因，錯誤示范以及修改方案如圖7。圖6 問題定位圖7 規范示例2、面向項目管理者：周期性統計本組內各開發人員質量數據。圖8 項目維度開發質量統計3、面向技術委員會：可實現對規范的評審以及管理，以及有效性數據的收集。圖9 代碼規范管理通過以上組織建設、切實運營以及工具平臺的建設搭建了代碼規范的運營平臺，通過全員參與，自動化檢測，量化反饋，周期性迭代更新，對規范的產生、落地、更新有一個閉環的管理。徹底解決了傳統代碼規范不好落地的問題，通過系統解決不愿改，不想改，不會改的問題，如圖10。在代碼提交階段，通過代碼規范的服務化度量，為代碼規范落地實施提供了一種可控手段。并可集成至CI過程中，提供了自動化的服務，在整個CI工具鏈上豐富了自動化組件，提升測試服務化能力和質量反饋維度。圖10 代碼規范落地實踐總結三、 總結實行良好的代碼規范，從長遠看最大的受益人往往是團隊本身。可能因為繁瑣的規范付出了很多額外的工作，但是這些得失，看似無用的東西往往會通過慢慢的積累由量變而到質變，才能感受到其價值所在。
　　但代碼規范的制定、落地是一個辛苦、瑣碎、緩慢見效的過程，但也是一個程序員走向成熟的必經之路，唯有你定義的東西能夠服眾，才能被長久傳承下去。
　　愿我們能在最美好的年華做最有價值事，獻給在路上的程序員們。
　　PS：調研的檢測工具檢測規范重點，讀者可以從各自項目實際情況選擇切入點。Checkstyle：
　　● Javadoc 注釋：檢查類及方法的 Javadoc 注釋
　　● 命名約定：檢查命名是否符合命名規范
　　● 標題：檢查文件是否以某些行開頭
　　● Import 語句：檢查 Import 語句是否符合定義規范
　　● 代碼塊大小，即檢查類、方法等代碼塊的行數
　　● 空白：檢查空白符，如 tab，回車符等
　　● 修飾符：修飾符號的檢查，如修飾符的定義順序
　　● 塊：檢查是否有空塊或無效塊
　　● 代碼問題：檢查重復代碼，條件判斷，魔數等問題
　　● 類設計：檢查類的定義是否符合規范，如構造函數的定義等問題FindBugs：
　　● Bad practice 壞的實踐：常見代碼錯誤，用于靜態代碼檢查時進行缺陷模式匹配
　　● Correctness 可能導致錯誤的代碼，如空指針引用等
　　● 國際化相關問題：如錯誤的字符串轉換
　　● 可能受到的惡意攻擊，如訪問權限修飾符的定義等
　　● 多線程的正確性：如多線程編程時常見的同步，線程調度問題
　　● 運行時性能問題：如由變量定義，方法調用導致的代碼低效問題PMD：
　　● 可能的 Bugs：檢查潛在代碼錯誤，如空 try/catch/finally/switch 語句
　　● 未使用代碼(Dead code)：檢查未使用的變量，參數，方法
　　● 復雜的表達式：檢查不必要的 if 語句，可被 while 替代的 for 循環
　　● 重復的代碼：檢查重復的代碼
　　● 循環體創建新對象：檢查在循環體內實例化新對象
　　● 資源關閉：檢查 Connect，Result，Statement 等資源使用之后是否被關閉掉

參考文獻

[1]Sonar?https://blog.sonarsource.com/[2]Findbugs?http://findbugs.sourceforge.net/[3]Checkstylehttp://checkstyle.sourceforge.net/[4]PMD?https://pmd.github.io/

作者：李旭 高美鈴 /興業證券股份有限公司

(來自：上交所技術服務)

總結

以上是生活随笔為你收集整理的coverity代码检测工具介绍_兴业证券：静态代码检测最佳实践的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。