一、 引言

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

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

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

總結

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

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