如何規畫軟體品質提升的作法？

要提升軟體品質，可從系統及人文兩個層面來要求：系統面以透過完整的檢測及掃描來確保測試的完整性，而人文面則是透過系統化文件的產出，以及良好的程式碼撰寫風格來讓可讀性提高。

前兩回文章所提到的建構及測試自動化，若都能落實在作業程序中，則軟體開發80％的自動化需求大致底定。一般而言，只要能先確保軟體功能正確無誤，行有餘力才會再來求品質的提升。就實務而言，由於時程及人力資源條件的限制，僅著重於功能驗證無誤，即安排版本發布及上線程序，品質強化的部分反倒甚少被重視，然而許多問題在未來系統正式上線後，在使用度及資料量的日益成長之下逐漸浮現──很多都是由這些潛在的品質因素所引發出來的。

然而開發的系統時間一久，功能範圍日益擴增，加上開發人員的職務異動，程式碼本身所包含的資訊，是否足夠讓維護接手的人員不中斷地持續開發作業，在文件及程式碼的可讀性即為關鍵性因素。

未雨綢繆、及早預防──程式碼靜態掃描

所謂靜態程式碼掃描，主要用意在於透過問題模式比對的方式，對於已撰寫好的程式碼進行錯誤的先期預防，以及早避免曝露可能的系統弱點，或是隱含的系統錯誤及效能問題，而降低系統上線後才發現問題的風險。多數軟體品質的問題，可以從程式碼的撰寫方式來推出潛在可能引發的問題，而且有許多工具累積了不少問題模式及類型（bug patterns），在執行掃描的過程中便能逐一列出問題的所在。

像是常見Null Pointer Exception的發生可能性、無謂變數的宣告使用、過於複雜的邏輯判別式、重複多餘的程式碼內容、關於密碼變數值的管理方式，或是程式碼可能造成SQL Injection被入侵，及跨站腳本攻擊（XSS）的疑慮等。

這樣的掃描作業，當然也能整合到建構自動化的設定中，在每次建構完畢即產出靜態掃描的結果報表供管理者參考。所發現的問題，會依你所採用的工具，而有詳細程度上的差異，這些問題也會依重要性來分類。而管理者則視其必要性，決定是否列入修復的必要項目。

較常被採用的免費開發源碼工具，像是Findbugs、PMD等，商業套件像是Parasoft、Fortify等，其所著重的掃描問題重點及類別，都有所差異，原則上都可支援與既有的開發環境，並提供與建構工具（像Ant、Maven）密切整合的功能，方便併入建構自動化程序中。像Fortify甚至提供專家知識庫，針對不同問題提出建議做法，協助開發人員進行改善作業，提升不少工作效率。

撰寫程式即撰寫文件

實務上，通常都是開發完畢後，才挪出時間後補文件的撰寫，做為專案驗收的依據，而且，日後文件持續維護的工作並沒有落實，長時間下來，文件的價值也就被忽視。程式即文件的觀念，早在倡導敏捷製程時，就已經被強調，期望開發人員在撰寫程式時，一併將應註記的內容填入，保持內容的可讀性。

自己撰寫的程式若未附上良好的註記說明，一段時間再回頭來修改，常需要花上較長時間了解程式原意，更何況是轉交由其他非原開發者維護，這樣的問題會更加嚴重。若你用Java程式語言開發，透過Javadoc工具，即可自動化產出可供技術開發人員參考使用的文件，應用簡單的撰寫原則，可在開發過程中同步註解程式碼提高可讀性，降低未來維護時重新修改所需投入的成本。

而除了Javadoc產出的API類型文件之後，亦有其他圖形化文件產生工具，讓文件內容的可讀性更高。像是Doxygen、UMLGraph，可依程式原始碼反向產出UML圖表，提供基本的Class Diagram及Collaboration Diagram，來表示其物件階層及相依性，讓開發人員在未經手程式碼之前，透過閱讀圖形化文件先掌握系統全貌，不致於發生直接閱讀程式碼，有見樹不見林的問題。

而SchemaSpy，則是針對資料庫端所提供的文件自動化產出工具，依照目前資料庫中已經建立的物件結構，進行反向工程文件產出，依table、view、relationship、constraint等常見的內容，予以系統化列出，並以E-R Diagram方式，表現資料表之間的關連性──只要在建立這些物件時，一併撰寫備註文字，像是資料表及資料欄位的說明文件，在這裡的文件都能被清楚呈現出來。由於此工具是利用JDBC方式與資料庫連接，它可支援目前業界大多數的資料庫產品，相較於知名商業軟體像是CA的Erwin Data Modeler、Sybase的PowerDesigner和Toad Data Modeler等，不需付出高額成本，即可產出專業化的資料庫規格文件。

這些圖形化文件的優點在於，方便將Diagram與程式碼內容的瀏覽，合而為一，讓閱讀者在追溯物件關係並檢視到原始程式碼的行為上，更為流暢。所提供的文件格式，亦以HTML格式為主，支援全文檢索功能，閱讀者不需額外安裝特殊軟體即可瀏覽。

不過，上述工具雖然能協助快速產出圖形化的專業技術文件，但內容的充實與否，仍須落實平日開發人員的作業上──對於程式碼的註記方式，必須確實養成習慣及規範，否則產出的文件內容參考價值就有待商榷。

另外值得強調的是，這些使文件自動化產生的工具，只是單純輔助事後撰寫文件的效率提升，但針對像是需求規畫分析設計過程所產出的文件，並不會因此而省略掉。這些文件則是配合思考的過程而產出的規畫內容，切勿混淆。

一致化的程式碼撰寫規範

程式碼的撰寫風格一直是被討論的課題，許多原則早在昇陽電腦所定義的程式碼撰寫風格規範（Sun Code Convention）中提到，不外乎是希望每個開發人員能配合一致性的撰寫方式，讓後續維護工作的人員能快速接續處理而降低維護成本。

常見的規範，像是空白字元的數量及出現位置、變數的命名規則、Javadoc中所要求的註解內容必須填寫、程式檔頭的標準說明內容等。不過這樣的要求在實務上，的確不容易，開發人員習慣的程式碼排列方式，與其開發生產力有著直接的關係。此時就會考慮導入程式碼規範工具，來強制將代碼內容規格化。

常見的格式化工具，像是CheckStyle、Jalopy等，可以安裝在你的在開發環境中（像Eclipse），在撰寫程式碼時，編輯器便會在不符規範的程式碼的該行首位置，顯示警訊，即時提醒開發人員遵循規範來寫作，而規範的內容亦可由開發團隊自己定義，調整出適合既有專案開發團隊都可以接受的方式。

在每次建構時，即可將程式碼依指定的規範格式進行內容檢查，或是在CI Server上進行建構自動化程序時，將整個專案的程式碼一併處理，並可強制設定當不符合規範時，即中斷建構作業。規範的嚴重程度，亦可以自行定義。

規範的定義在實務上，也不要太過強硬，導致妨礙整個建構作業的流暢度。畢竟撰寫規範的落實並非必要條件，建議可以先以Jalopy，將程式碼自動調整成期望的格式，再以CheckStyle進一步確認，會更為可行。

實務上，開發團隊常因方便行事，而一般客戶在需求規格中亦甚少提及針對品質部分進行要求，或是將此課題視為非必要性的。軟體品質的提升非一蹴可幾，自動化工具僅能輔助，更重要的需管理者的重視，以及全體開發團隊的配合施行，才能達到應有的水準。

作者簡介：

陳宏一

交通大學資訊管理研究所碩士

目前任職於某數位行銷公司技術經理，曾任職於南亞科技資訊部工程師、資迅人網路研發副理、艾群科技產品研發部經理，專精於OOAD、 J2EE 相關技術、Open Source、資料庫設計、軟體開發流程及專案管理等；取得SCJP、SCWCD、SCJD、SCEA、ITIL等認證。曾經歷大型社群及電子商務網站、 WAP/3G行動加值服務、CTI/CRM客服系統架構規畫設計等。