柏林版如何進化程式碼

Metric和Audits這2個功能早已經存在Delphi很多年了, Metric和Audits可以讓我們檢查和保證程式碼的撰寫品質, 但就我個人所知經常使用Metric和Audits的開發人員卻很少, 我也不知道為什麼.

在我於各地進行Delphi相關的活動中,也認識了一些朋友, 他們可能是專案/產品經理, 因為他們通常都會詢問一些類似的問題, 例如:

  1. Delphi有沒有工具確保外包程式碼的品質?
  2. Delphi有沒有工具確定外包廠商有遵守我們的制定的程式碼規範?
  3. 如何尋找程式碼中的漏洞和弱點?
  4. 等等…

等問題. 事實上Metric和Audits就可以幫助開發人員確保程式碼的品質, 在柏林版中又加入了Toxicity功能可以幫助開發人員制定和搜尋程式碼規範. 例如我看過許多公司都規定一個函式長度不能超過多少行, 一個if敘述不能超過多少層, 以及函式的參數不能超過多少個等.

這些程式碼規範有的和日後維護的難易有關, 有的和執行效率有關, 都是非常實用的規範, 但在數萬或是數十萬行的程式碼中要如何驗證巨量的程式碼呢?

在柏林版中開發人員可以在IDE中點選Tools|Options|Toxicity Metrics啟動Toxicity的設定對話盒:

Snap1

在Toxicity Metrics設定對話盒你可以看到我們可設定驗證函式長度, 函式參數數目, if敘述層, 以及函式需要測試的獨立執行路徑數目等重要的程式碼品質數據.

接著你可以開啟Delphi專案, 在IDE右上方的搜尋欄中輸入Toxicity, 就可以看到Toxicity命令:

Snap4

執行它, 它就可以開始對你的Delphi專案進行驗證, 並顯示結果:

Snap2

不合驗證規範的函式就會以紅色標誌, 使用滑鼠雙擊紅色標誌項目IDE就會開啟對應的程式碼. 例如上面的函式DeductAmount是一個非常複雜的函式, 它使用的if敘述層有6個, Toxicity功能可以即時又精確的在數萬行的程式碼中幫助我們定位到這個函式:

Snap3

接著我們就可以再次檢驗DeductAmount函式是否真的需要如此複雜, 可不可以藉由重構簡化它呢?

善加使用Audits/Metrics和Toxicity功能可以不斷的完善和提昇程式碼品質, 當然也可以幫你驗證他人或是外包的程式碼. Have Fun!

 

 

 

 

 

廣告
  1. #1 by Wyatt Wong on 2017 年 09 月 03 日 - 10:46:48

    請問李維大師你什麼時候會再去深圳舉行發佈會?
    我的電郵

發表迴響

在下方填入你的資料或按右方圖示以社群網站登入:

WordPress.com Logo

您的留言將使用 WordPress.com 帳號。 登出 / 變更 )

Twitter picture

您的留言將使用 Twitter 帳號。 登出 / 變更 )

Facebook照片

您的留言將使用 Facebook 帳號。 登出 / 變更 )

Google+ photo

您的留言將使用 Google+ 帳號。 登出 / 變更 )

連結到 %s

%d 位部落客按了讚: