概要
你想在提高代碼質量方面走多遠？
你想在哪里止��？
FindBugs
PMD/CPD
Checkstyle
Jalopy/Jacobe
JDepend
JUnit
Eclipse
項目集成
故障解決
概要
幾年前每個人都被Quality 軟件的問題所困擾。Quality 中的Q 之所以大寫就是為了強調單詞的重要性。引入了消耗幾個小時的程序和檢查過程、以及大量的文書工作，就是為了設法減少軟件的故障率。就是前不久，這種趨勢已經演變為更為輕便的處理過程，該過程使用了輕便的軟件和極端編程。這仍然是一個積極的轉變因為保證軟件品質仍然是重要的。有些分析家估計：有60%的軟件故障可自動檢測出來。那么我們能做的就是在昨天的質量裝置恐龍和今天的困惑之間建一座橋梁，以便讓問題解決的又快又代價低？作者Joe Walker 測試了不同類型的故障和七種工具以幫助你揭示他們的真面目。
有許多免費工具可以輕而易舉的報告你的代碼有什么故障，然后幫助你改進代碼的質量。而且因為故障常常是主觀方面的，大部分工具可以配置以適合你的本地代碼類型。
但是一開始你就有減少故障的義務。這聽起來好像是一個簡單的問題——肯定對于每個人來說軟件質量必須擺在第一位。但是，花費最少時間來修改代碼往往看起來更加合理一些。任何保存壽命短的軟件應該編輯的盡可能少，而且編寫沒有人閱讀的單行文檔也是毫無意義的。我在想有多少塊文檔花費在編寫和檢查方面的時間比某人閱讀他們節省的時間多呢？因此，我們的目的就是把值得我們提高作品質量的工作和浪費資源的工作區別開來。
你想在提高代碼質量方面走多遠？
存在以下幾種故障種類。我給出的工具在它們攻擊的故障類型方面有區別。我根據他們的嚴重性確定了四種不同的故障類，從困擾用戶的普通故障到阻止代碼重新使用的有組織的故障都有：
·Current bugs: 當前故障阻止軟件的正確運行。它們困擾用戶并且可（或者應該）通過你的軟件測試顯示出來。當前故障與潛在故障截然不同。
·Latent bugs: 這些故障當前不產生問題。但是它們潛伏著，在以后才出現。阿里安5號火箭的失敗就是由于一個浮點到整數轉換錯誤引起的，當前面的火箭速度較慢時處于睡眠期；但是速度較快的阿里安 5卻觸發了這個問題。千年病毒也是一個潛伏故障的例子，只有當環境改變時它才浮出水面。使用傳統的測試方法測試潛伏病毒要困難得多，并且找到他們就需要具有遠見的人詢問：“什么改變才能讓故障從黑暗中走出來？
·Accident-waiting-to-happen bugs: 代碼可以既簡單又安全，或者他也可以是一團糟，等著絆倒那些對他們的編輯結果想得不多的可憐的程序員。一般而言，代碼越老，就越有可能出現明顯生銹的刀口；并且某些工業證據也表明：長時間沒有重構的代碼一般七年之后也就不再需要重新編寫了。
·Poorly organized bugs: 組織不好的代碼不容易重新使用并且常常包含對代碼的過多依賴，其實有些是不必要的。因此它更有可能受其他代碼位中的故障影響。編碼標準致力于解決這種類型的問題，但是編碼標準不能完全解決問題。他們不能停止問題如循環的依賴性，它使得你毫無機會來維持可重新使用的代碼。
這些問題根據他們的嚴重性組織的比較粗糙。當前故障一般比潛伏故障更難以解決，而潛伏故障依次的比等待發生的故障或者組織故障更加令人擔心。
下列代碼包含了上述四種故障案例。認出它們后獎勵一下你自己:
1: public static void main(String[] args)
2: {
3: System.out.println(toUpperCase('q'));
4: }
5:
6: private static char toUpperCase(char main)
7: {
8: return (char) (main - 31);
9: }
這里有一個當前故障因為行8應該讀�。�
8: return (char) (main - 32);
這種簡單問題不解決，程序也不會運轉。與其辛苦計算出q的大寫字母為Q，還不如設法勸說我們相信答案就是R。
這里有一個潛伏故障因為遲早有人會設法得到ß 或者某數的大寫版本，而不是任何明智的東西。
一個小小的等待發生事故的故障是由于行6中的某些傻變量名引起的。main 并沒有真正的描述什么正在進行，而且還用方法名來迷惑我們。更好的代碼如下：
6: private static char toUpperCase(char lower)
如果該代碼描述了為什么她要從小寫字母盤上的字符減去32，那么它會安全的多。
最后如果你將toUpperCase()方法變為公用的，并為方便其他類的使用將它變為實際類——甚至你可以使用下面的標準Sun微系統提供的方法，那么代碼就組織得更好一些：
3: System.out.println(Character.toUpperCase('q'));
你想在哪里止��？
你什么時候停止調整和提高你的代碼呢?這個問題沒有一個真正的答案；這取決于你和你的項目。商業項目常常只關注于ROI (投資回報)，因此它主要解決當前故障，并且通過實現編碼標準解決這個問題很容易。
我們常�？吹缴虡I項目無意中采取了某些步驟來阻止潛伏故障的解決，它們實現了一個嚴格的變化控制程序，該程序將代碼修改與產生的故障聯系在一起來幫助測試。要開發隊伍足夠忠誠于軟件品質，以致于關心某人的軟件而且不設置障礙，這實在是太難了。
在更具有啟迪性的開發環境里，大家都承認重構是創造高品質軟件的至關重要的組成部分。重構就是逐步穩固你代碼的組織以避免等待發生事故的過程。
文章來源于領測軟件測試網 http://www.kjueaiud.com/