聊聊我所知道的 Android 相關的代碼檢測
因為筆者業務開發能力不太夠，所以會經常做一些周邊的雜活，曾經做過在團隊里建立代碼檢測機制的作業，所以我想簡單地說下這部分的內容，
代碼檢測的地位
首先要說的是 軟體開發的檢測 的目的是什么，以及都有那些型別的檢測，
在我看來，檢測的目的就是為了 保證代碼可以滿足某些要求 ，
以筆者淺顯的見識，現在覺得一般的軟體開發檢測包括：
- 代碼檢測
- 業務功能的單元測驗
- 模塊整體（比如一個 aar / 一個 apk）的自動化測驗
- 真人 QA 介入的測驗
其中從上到下，
- 測驗執行成本（設計成本、人工成本等）越來越大；
- 測驗執行所用時間越來越長；
- 測驗執行頻率越來越低；
- 發現問題以后修復的成本越來越高；
今天只討論其中 代碼檢測 這個環節，其余的環節因為筆者了解的并不多，就不在本次獻丑了，
代碼檢測指的是什么？
筆者認為 代碼檢測 指的是開發者從 提出代碼修改 到 初步確認代碼沒有簡單的錯誤 的這個程序的，因為將 業務功能 相關的單元測驗劃分出去了，所以這部分 代碼檢測 是不包含業務功能的檢測的，也就是說，這部分只進行
-
靜態代碼的格式檢測
-
靜態代碼的健壯性的檢測
這樣子說可能比較模糊，我舉幾個現在比較常見的檢測規則：
- 改動是否包含魔數
- 改動里的變數名是否符合專案的要求（比如要求靜態變數使用大寫命名，屬性變數使用駝峰格式命名）
- 改動是否導致檔案過于龐大（比如說單個檔案超過了 1200 行，很難讓人讀懂）
- 改動是否導致類繼承層級過多（比如改完了以后當前類到 Activity 有五層繼承關系）
- 改動是否導致某個方法過于復雜（比如單個方法行數超過了 150 行，某個方法里的 if / for / when 過多等）
- ……
這些檢測，在一些手熟的開發者手中，是很難出現的，因為這些人大都會很注意程式的基本設計，會有意識避免這些會導致代碼可讀性變差的寫法，不過對于一些專案比較著急、或者像筆者這樣不太注意的開發者來說，就很容易寫出這種代碼，
這種代碼其實在 Code Review 環節是很容易發現的，不過如果單純依靠人來做這樣的檢測的話，一是比較慢，二是比較累，所以最好的方法就是增加自動檢測的機制，如果不符合這些條件的話，可以直接提示出來進行改動，這樣，通過檢測的代碼就有了一個最基本的質量底線，這也就是上面提到的 代碼檢測 了，從這個角度說，代碼檢測 其實是用來 1）規范代碼基本寫法 2）幫助 Code Review 的，
Android 上如何進行代碼檢測
對于開發者來說，開發上面這種檢測插件無疑是很簡單的事情，但是對于筆者來說，開發這些東西需要查看大量語法決議的資料，所以還是采用已經有的開源方案了，
對于 Android 上要進行的代碼檢測，有這幾種可選的方案：
- 純靜態檢測文本的方式決議代碼
- 決議代碼關系，檢測代碼
接下來分別介紹
純靜態檢測代碼
這種檢測方式，類似于 python 這類“決議型語言”，特點是只需要輸入一個 java 檔案，不需要它所依賴的類的檔案（比如說父類的類檔案），即可以完成檢測，甚至不需要整個檔案，只輸入其中的一個方法也可以進行檢測！因為其只依賴文本內容的特征，所以筆者稱之為靜態檢測代碼，
這部分已有比較成熟的開源方案，其中對于 java 有大名鼎鼎的 check-style; 對于 kotlin 則有新秀檢測方案 detekt ，兩者的接入方式比較一樣，使用方式也很類似，
限于篇幅，具體的用法就不在此轉發了，以官網的為準，各位朋友可以查看官網的使用說明，
雖然要對付的語言不一樣，但是 check-style 和 detekt 如此相似，讓人不由想看看其內部實作的方式，簡單地查看了各自的原始碼后，會發現其實內部的原理都一樣，只是表現的形式不同罷了，
兩者的思路其實大概流程都是下面這種流程（就不細說了，因為太詳細的話，筆者也不是很明白了；而且這里的描述可能不夠清楚，如果看不明白的話，可能是因為筆者的理解不對或者是表達能力有限，可以先不關注，）
- 基于輸入的檔案內容決議出來一個語法樹，
- 會有多個寫好的檢測規則類，這些檢測規則其實就是 java語法樹遍歷器 / kotlin 語法樹遍歷器，
- 距離：比如說檢查檔案
- 在生成的語法樹上，遍歷每一個元素：
- 對每一個元素，都遍歷每一個規則，
- 上述的遍歷完成后，即相當于每一個規則都遍歷了該語法樹，也即相當于對輸入的檔案進行了一遍遍歷，各個規則也都完成了對檔案的檢測，采集到了檔案不通過檢測的部分，
- 最后將所有不通過檢測的部分全都輸出，也就完成了文本的檢測了，
決議代碼關系，檢測代碼
相比較于上面的類似 “解釋型語言” ，這種檢測方式更像 “編譯型語言” ，這種檢測方式只依靠單一的輸入檔案是無法完成的，需要輸入的是一個可以作為整體進行“鏈接”的專案，比如 Android Studio 自帶的 lint 就是這類檢測方式，
舉個例子說明：
- 假設需要禁止一個類的子類太過龐大（比如繼承深度不能超過 5，每一代的繼承自雷數量不能超過 6），
這類涉及多個檔案的檢測，明顯不是純文本可以完成的，需要將其他的檔案一并讀取分析才可以完成判斷，
這種檢測因為更加復雜，運行一次的用時也會更多，差不多類似于進行一次專案的編譯了，
但是因為筆者沒有實際運用過 lint 進行復雜的代碼檢測，所以在這里不多談了，
總結
代碼檢測是用來規范代碼格式的，對于保證代碼的最低質量還是比較有用的，當然了如果為了寫出更好的代碼，還是需要多多思考，少復制粘貼的，
轉載請註明出處，本文鏈接：https://www.uj5u.com/yidong/374513.html
標籤：其他
下一篇：音頻制作的現狀與發展趨勢