你們的開發團隊有引入findbugs等代碼檢測工具嗎？老代碼改不改嗎？

題主所在的團隊也開發維護著一個千萬級日活的app吧，跑了好幾年了都沒引入過代碼檢測工具。。。。居然也很順溜的跑了好幾年，想想也是很神奇的事情。

為什麼這個時候引入除了要提高代碼質量還有一個重要的原因是提高review代碼效率。個人覺得，很多問題不該在review代碼的階段再來指出很浪費時間（畢竟哥的時間很貴的，留著干更有價值的事），而且會有很多簡單的，重複的問題。

問題來了，跑了n年的穩定的老代碼該不該改？特別是圈複雜度的改動會涉及大量代碼的修改？

如果說不改，怕這個東西過一陣子後會很難推行，不了了之。因為你是 要讓團隊成員意識到，團隊對代碼質量的追求和重視。

所以，想聽聽各位的意見～

• 在什麼文件裡面改代碼，就遵守那個文件當年的編碼規範。
• 新文件總使用最新的編碼規範。
• 每年總會有那麼一段時間是沒什麼事的，蛋疼的話可以去翻新舊文件。

1. findbugs報出來的警告應當解決掉，畢竟有潛在bug；解決findbugs應該對項目結構影響不大吧；
2. 圈複雜度的要求，針對新增代碼會比較好，直接寫入團隊DoD，持續推行應該無壓力；
3. 針對老代碼的重構，一般從多個維度賦予不同權重計算一下收益比會比較合理。

一點愚見，歡迎討論。

發表點個人的理解 :
使用Findbugs有段時間了, 這裡主要作為工具側加入daily-build日常檢查中, 開啟的規則主要有類型轉換, 引用比較, 空指針類規則等; 在這個基礎上,寫了一些自定義的檢測器(代碼規範類, 空指針特殊場景, 特定類型使用等); 而實際應用情況怎麼樣呢?

這裡肯定會有個過程的吧, 老代碼(線上跑了一段時間的) 換位思考我也不會多想改.. 所以怎麼辦呢. 盡量先推動開發修改新代碼里出現的問題唄.. (登門檻效應吧) .. 如果新代碼都不願意改..(其實也正常, 你告訴別人錯了, 那最好告訴別人為啥錯了, 以及如何正確修改吧? 如果這些基礎支持沒有 想推動開發團隊修改 且尤其團隊較大時 難度應該很大.. 再者 因為靜態分析本身的局限性, 它畢竟不是不是動態分析, 一些場景註定會誤報或者發生問題概率不大 這麼看 作為開發者本身不願意改也情理之中吧 靠嘴是很難說服的.. 這裡還是需要上級地推動了吧... 畢竟它並不是非黑即白的問題 比如NP_NULL_ON_SOME_PATH(這裡可參考 譯言網搜索關鍵字: 靜態分析)

好吧 假設領導在支持, 基礎側(錯誤提示, 修改指引)都做到位了 可能的話 還可以針對這些規則問題 團隊review等... 短時間大家還是願意修改的...可時間流逝.. 很多時候被動接受的 到後面開發還是會懶惰起來的 所以拋開靜態分析本身, 再看。人懶惰了原因往往還是沒有意識到處境的危險性？

如果你可以把歷史crash的case收集起來, 表明工具可以檢測這點 以及目前檢測出的問題對應哪個case? 這時候掃出來的問題自然有自我的說服性了？ (這個可參考Coverity SCAN

PS1:
用戶不買賬 是因為他認為不值當( 或者它不知道有這個東西 或者有其它替代方式) 一一排除後 找到工具能解決的用戶痛點 那時候 呵呵(這裡扯遠了)

PS2:
其實二次開發挺有用的 簡單又強大
(開發同學一個比較好的主動參與方式: 提煉缺陷模式)

先說到這裡了 希望對你有啟發