不知道大家在求職平台的職缺介紹有沒有見過類似這樣的職務內容需求：「優化公司內部專案程式碼」、「改善並清除遺留代碼 (legacy code) 」之類的字句。
筆者手機內就有各家求職網站的 App，平常沒事就當作在看娛樂新聞般的心情在看各家職缺，瞭解一下當前業界需要的技術是什麼，要是有看到什麼新奇的工具是沒看過的，我就會 Google 一下。所以發現到，像這樣的職務內容還蠻常見的。
什麼是 Code Review
Code Review (程式碼檢閱)，是在軟體開發流程中，程式碼在更新至所在開發用的分支 (branch) 之前，需先進行至少一名以上同儕審核，檢查是否有可能的 bug、邏輯上的問題，細心一點的同事還能抓出被忽略的特殊情況 (edge case) 錯誤。
Code Review 會佔用同事的工作時間，但為了保持程式碼品質，這段過程又不能少。為保持團隊整體工作效率，養成細心、上 code 前多想想、多自行測試、寫單元測試來避免錯誤發生，以及程式碼檢閱過程中你來我往，不必要的過多來回。
程式碼品質
- 那麼什麼樣的程式碼還才算品質好？
- 該怎麼做才算改善程式碼？
可能的回答有：
- 好的變數、方法名稱命名。
- 程式碼越短越好。
- 不要有過多的 if、else。
- 等等等..。
不過真的是這樣嗎？
我們盡量避免使用主觀的想法來看待這事，因為主觀總會受到過去經驗影響。建議使用可量化數字、已制定好習慣規則的工具來幫助我們完成這樣的任務。
除了商業邏輯以及 edge case 的情況，程式碼品質可外包給自動化軟體來檢閱並分析程式碼，產生建議報表，節省大量團隊時間以及減少過人意見對於程式碼的意見不一的潛在衝突。
檢測工具：PHPMD
一個已經很成熟的 PHP 工具能快速帶我們入門。這個工具名字叫：「PHP Mess Detector，簡稱：PHPMD」。
PHPMD 主要有六大類規則：
| 規則大類 | 英文 | 簡介 |
|---|---|---|
| 簡潔程式碼規則 | Clean Code Rules | 此規則集強制規定乾淨、整潔的程式碼規則。主要包含了 SOLID 原則及物件體操 (object calisthenics)。 |
| 程式碼大小規則 | Code Size Rules | 此規則集規範了和程式碼大小有關的規則，例如循環複雜度 (cyclomatic complexity)、及路徑複雜度 (NPath complexity) 等等。 |
| 爭議性規則 | Controversial Rules | 社群中比較有意見的規則、例如超全域變數、駝峰式命名法等等。 |
| 設計規則 | Design Rules | 與程式設計習慣有關的規則，例如禁用 goto、類別過多依賴其它類別等等。 |
| 命名規則 | Naming Rules | 變數的名字長短、類別及方法命名的長短等等。與命名相規的規則集。 |
| 無用程式碼規則 | Unused Code Rules | 在程式碼中沒用到的變數、函式、類別及方法等等。 |
雖然只要從官方網站下載 phpmd.phar ，或使用 Composer 安裝：
composer require phpmd/phpmd之後就可以直接在命令列下指令針對專案目錄進行分析，例如：
phpmd /path/to/source html codesize,unusedcode,naming --reportfile phpmd.html命令列說明：
| 格式 | 說明 |
|---|---|
/path/to/source |
要分析的目錄。 |
html |
輸出的格式，可用 xml、text、或 html 這裡使用 html |
codesize,unusedcode,naming |
要採用的規則集。 |
--reportfile phpmd.html |
參數：輸出為 HTML 檔，檔名 phpmd.html |
雖然要輸出報表慢慢看也可以，但是這樣一行一行比對，是要看到民國幾年呀？一定要找更有效率的方法才行。
使用編輯器套件
在 Visual Studio Code 的擴充套件市集中有一款已經內建 phpmd.phar 即裝即用的套件：
安裝之後，基本上不用輸入 phpmd.phar 的路徑，直接可以使用。
在 Rules 設定值那一欄，可填寫要採用的規則代碼，或則填寫一個自訂規則 rules.xml 的路徑
檔案內容看起來像這樣。
實際效果
啟用之後，如果偵測到符合規則集的問題時，則會提示紅色波浪式底線。
建議是不用使用 else，改寫為如下：
因為 else 是不必要的，只是多了一個路徑。在這個例子中增加了 1 點的複雜度。
在整個函式或方法區塊有被偵測到問題，則會提示藍色波浪式底線。滑鼠遊標移過去會出現建議。
自動化程式碼檢閱
Scrutinizer CI
（圖：Scrutinizer CI 官網首頁）
筆者目前用的是 Scrutinizer CI，它對開放原始碼的專案是完全免費的。
註冊方式也很容易，使用 GitHub 帳號登入。
直接使用 GitHub 帳號登入後，在「Add Repository」中輸入自己 GitHub 儲存庫，選擇專案的程式語言為 PHP，然後送出即可。
除了對程式碼打分數以外，還會分析出一些可能的問題。例如使用的類別可能無法呼叫之類。或者變數的型別和宣告不同等等。
範例網址：https://scrutinizer-ci.com/g/terrylinooo/simple-cache/
總結
本篇沒有著墨於怎麼寫才是改善程式碼，什麼才是最好的程式碼。這種主觀的問題，就交給客觀的工具來解決吧。寫 Code 就是要快快樂樂地一起分享新發現，而不是糾結怎麼寫才是好。
而這些工具的使用，如果用的習慣，差不多也稱的上是好的程式碼了。
明天就要發表這次鐵人賽而生的套件作品第一版了。大致內容有想好了，不過還是老話一句，我們明天見囉。
留言