程式人該關注的程式碼品質

當我們在談軟體開發或程式設計時，時常會提到「軟體品質」或是「程式碼品質」，但是究竟我們所討論的「軟體品質」或是「程式碼品質」指的是什麼呢？有人可能會認為它代表的是程式碼不會出錯、沒有臭蟲、行為符合軟體規格。但是，當我們在談一些設計方法，像是「設計模式」或是「重構」的時候，我們則會把程式碼容不容易維護、或是容不容易被讀者所理解，也視為是品質的一部分。人們似乎對品質存在著截然不同的看法，而若是單講「品質」，可能在討論上也會引起誤解。

一個沒有臭蟲的軟體，可能不易維護；而一個容易維護的軟體，也可能暗藏不少臭蟲。總的來說，大家都希望可以「提升品質」，但是，當我們所談的「品質」是不同的意義時，提升的方式也不盡相同。因此，在這一回裡，先讓我們來區分這二者的差別。

軟體品質的區分

一般來說，軟體的品質可以區分為兩種相關卻又不同的類型，第一種是「功能性品質（functional quality）」，另一種則是「結構性品質（structural quality）」。所謂「功能性品質」其實就是符合功能性需求或是規格的程度，越符合當然品質越好。通常，除了實作不符合規格之外，一些預期之外的行為，也就是臭蟲，都是我們在處理功能性品質時最常遭遇到的問題。

功能性品質代表的是軟體對外而言的樣貌，因為人們會用需求或規格來描述軟體所該具備的行為，倘若實際的行為和預期的不同，那麼就是品質有了問題。

而所謂「結構性品質」，則著重在非功能性的特質，也就是軟體內部的結構，透過在不同的程式，包括程式碼層次、模組層次、系統層次、技術層次來分析，可以評估軟體結構性的品質。

「功能性」的品質代表的是對不對、正不正確，而「結構性品質」則是著重在其他的層面，甚至有許多特質是比較內隱、光是觀察程式碼的行為也看不出來的。

好比你寫了一個超長的函式，對於重構的方法來說，這是一個程式碼品質不佳的象?。但是，這個函式可能運作得完美無瑕，因為它裡頭沒有任何邏輯的錯誤、也都符合需求及規格，還可以通過所有的測試案例。這是一個功能性品質好，但結構性品質不夠好的程式碼。然而我們無法從外在的觀察行為，例如測試手段，來檢驗這個品質。在這個例子裡，測試手段只能檢驗到它的功能性品質夠好，但卻無法驗證它具有超長函式的結構性品質問題。

有些增進功能性品質的方法和增進結構性品質的方法相同，但也不完全一樣。大多數的程式設計新手，若是對品質有概念的話，多半會從功能性品質著手。所以，他們或許可以寫出通過一定數量測試案例的程式碼，但是，他們的程式碼卻不見得具備良好的結構性品質。在本文裡，想先探討結構性品質的特性究竟有哪些、與其相關的因素、以及要透過哪些途徑來加以提升或確保品質。

影響軟體結構性品質的因素

CISQ（Consortium for IT Software Quality，IT軟體品質協會）針對軟體的結構性品質有相當明確的定義，有五個主要的軟體特質影響著軟體的品質：「可靠度」、「效率」、「安全性」、「可維護性」，以及「大小」。

那麼這幾個特質又分別受到哪些因素所影響呢？一般來說，可以分為以下幾種：

（1）架構設計；

（2）程式設計的實踐；

（3）應用程式的複雜度；

（4）說明文件；

（5）可攜性；

（6）技術和功能的量；

以上每種因素都或多或少影響了一個以上的品質特質，例如程式設計的實踐可能同時影響到可靠度、效率、安全性、還有可維護性。

架構的設計對品質的影響當然很大，一個架構設計不良的系統、甚至是不具架構可言的系統，都容易讓程式設計者在開發此架構時犯下錯誤，而且也不容易測試，使得它的可靠度降低。同時，架構也會影響到系統運行時的效率，一個設計不好的架構，也會造成運行效率不彰、或是系統資源使用過量等問題。一個有問題的架構，也有可能引發安全性問題，因為程式設計者得處理更多安全性的細節。當然，一個不好的架構，也會讓日後的維護工作更加困難，

這就是為什麼我們之前那麼重視架構的設計議題。你可以發現架構設計所探討的議題，也多半圍繞在如何讓這些品質上的特質朝正向發展。好的架構設計可以提升軟體的可靠度，因為透過一些設計手法，可以避免程式設計者不小心犯錯。而重複運用現成的元件，也可以基於一個更可靠的現有程式碼，而降低出錯的機會，因為現有、重覆使用而來的程式元件，多半已經歷一定程度的測試及實戰的運用。

架構也影響到運行效率，就像是利用Pooling的設計方式，可以提升資源的利用率以及實際運行時的使用資源效率。當然，好的架構令人容易理解，也容易擴充及修改，自然有利於日後的維護。在好的架構下，各軟體模組間的耦合程度低，彼此之間交互影響的力道小，降低了日後修改的困難，也減少了程式設計者犯錯的機會。

是否有遵行程式設計時的實踐準則也是我們時常提到的。就像我們常提到「重構」，重構方法中列出了諸多程式碼的「壞味道」，提醒我們看到此類的程式碼時，需要如何修改程式碼以做因應。這就是程式設計的實踐準則。

又好比大家所熟知的「物件導向設計五大原則」：單一責任原則、開放封閉原則、Liskov的取代原則、介面分離原則、以及相依性倒轉原則。在設計軟體時遵守這些原則的精神，都可以對諸多軟體品質產生正面的影響。

程式設計原則的實踐，影響品質的層面十分廣泛，這也是過去我們為何持續不斷地討論在這兩個範圍內的觀念和方法。

需求和規格只是基本要求，致力於更多面向的軟體品質才能提高程式碼格局

如果你只以程式行為符不符合需求和規格做為撰寫程式碼的準則，那麼你只看到了功能性的品質。但是軟體品質是多面向的，滿足需求和規格是第一步，其他的品質特質也很重要。我看到大多數程式設計新手開始著手寫程式時，都只把重心放在滿足需求和規格，而不太在意軟體品質的其他特質，甚至不明白需求與規格之外的特質其實相當重要。當然，滿足需求和規格是最基本的溫飽。但是，隨著時間的過去，應該要明白還有更多品質的面向需要兼顧，並且致力於其他品質的提升。如果只是繼續停留在實作出規格的程度，那麼便很難讓自己的程式碼邁向高品質之路。

程式設計者需要投注心力在各種架構設計的議題以及程式設計的實踐準則，明白它們的原理以及如何落實在實務中，觀察它們對實務工作所帶來的品質改善，才能不斷地讓自己在程式設計的領域裡持續進化。