[心得]打造可維護軟體03-撰寫簡單的程式碼單元

  • 627
  • 0
  • 2017-08-30

打造可維護軟體第三章-撰寫簡單的程式碼單元

撰寫簡單的程式碼單元的指導方針為:

限制每個程式碼單元(method)不超過4個邏輯分支點

複雜度經常是備受爭議的品質特性,因為不同的人對「複雜」的感受是不一樣的。那要如何客觀的評估複雜度?有許多的研究文獻各自由不同的角度定義出計算複雜度的公式。

常用的方式就是計算一段程式碼當中的可能路徑數量,基本的想法是,路徑越多表示程式碼越複雜,我們可以透過計算邏輯分支點的數量來判斷路徑數量。在計算分支時,有所謂的分支覆蓋(Branch Converage),還需要考慮分支的組合效果,也就是執行路徑(execution paths)。看起來就很複雜,也不知道辛苦地計算出來這些數值後,對我們的可維護性是否有幫助。

所以書中就採用的一個簡單又有效的計算方式:循環複雜度(cyclomatic complexity),亦稱McCabe複雜度。計算方式就是將分支點數量加 1。也可參考這篇文章:David Ko的學習之旅-Cyclomatic Complexity

所以將指導方針說白一點,就是在一個method中,邏輯分支(if, while, switch ...)的數量不要超過4個。

動機

高複雜度的程式碼單元(method)通常很難理解,因此很難修改。

如何遵守此指導方針

在C#中,下面陳述式與運算子都算分支點:

  • if
  • case
  • ? , ??
  • &&, ||
  • while
  • for, foreach
  • catch

辨識出method中是否有過多的分支點,如果有的話,一個方式是將其拆分成多個method。不過,還是需要注意到不要因為需要拆分method出去,反而影響到邏輯合理性程式可讀性。還有一個處理的方向,就是想辦法減少McCabe複雜度。例如有一個Switch述句,可以試著使用物件導向的多型的方式,取代條件判斷。也就是重構方法中的Replace Conditional with Polymorphism。參考:REFACTORING GURU-Replace Conditional with Polymorphism

不過,這種做法的缺點是:導致更多程式碼散佈在更多類別中。開發者必須在擴展性與簡潔性之間做取捨。

試著以讓程式碼更容易理解、更容易測試為目標,進行降低程式碼複雜度的依據。至於要怎麼做,書中並沒有特定的方法,還需要靠開發者自己的經驗,以及對需求的掌握度。

常見的反對意見

試著反向思考這個問題

高複雜度無可避免

「我們的知識領域非常複雜,所以程式碼的複雜度必定很高」

作者反對這樣的解讀,複雜的知識領域未必需要複雜的技術性時做。事實上,身為開發者,你的責任就是簡化問題,並且撰寫單純的程式碼。

不可否認,領域越複雜,開發人員就必須花費更多精力來建構簡單的技術方案。作者認為,解決及妥善控制複雜業務問題的唯一途徑,就是透過簡單的程式碼。

拆分方法不會降低複雜度

「將1個McCabe 15的方法替換成3個McCabe 5的方法,意味著整體的McCabe還是 15,所以根本沒有甚麼好處」

當然,僅將一個方法拆分為幾個新方法,並不會降低整體McCabe複雜度。但它會變得更容易測試、更容易理解,這是McCabe複雜度無法衡量的。