|
|
英文原文：Measuring Code
（編者注：原文譯者將Measure譯為“評估”，這里改為了“測量”）
你的代碼寫得怎么樣？如果你不屬于平庸的80%，我敢打賭你的代碼一定寫得很棒。也許你正在維護遺產(chǎn)代碼（不再被廣泛支持的系統(tǒng)相關(guān)的源代碼），這些代碼究竟能有多糟糕？情況會有所好轉(zhuǎn)嗎？雖然有一套方法可以幫助測量你的代碼，然而并非每個人都對此表示認可。
優(yōu)點
我個人認為測量數(shù)據(jù)非常有用。通過類似Emma這樣代碼覆蓋率計算工具，能夠讓你徹底了解你的代碼中究竟哪些已經(jīng)被測試覆蓋，還有哪些沒有被測試到。在開始著手某個包進行大規(guī)模代碼重構(gòu)之前，目標代碼的覆蓋率究竟如何？這些信息會告訴我，也許應(yīng)該在改動代碼前先提高一下這部分的代碼覆蓋率。
代碼行數(shù)是另一個種有意思的數(shù)據(jù)。當你在遺產(chǎn)代碼上工作的時候（誰不是在這樣的代碼上工作呢），如果你既能夠保持開發(fā)速度（你肯定還在開發(fā)新的功能），又能保持與過去相同甚至更少的代碼，那么你不但能夠在交付價值而且同時還能讓代碼變得不那么糟糕。任何一個傻瓜都能夠?qū)懗龀啥训男麓a以完成新功能，但是真正的高手能夠在交付新功能的同時減少原有的代碼。
缺點
任何數(shù)據(jù)都會面臨一個問題，那就是利用這些數(shù)據(jù)的人。你最不想看到的恐怕就是過度渴望監(jiān)控這些數(shù)據(jù)的經(jīng)理了。
不能度量就無法控制(You can’t control what you can’t measure)。
– Tom DeMarco
在你得到數(shù)據(jù)之前，報告缺陷數(shù)量就已經(jīng)和獎金掛鉤了。還有可能大家都希望代碼覆蓋率能夠達到某個“期望值”。
只要管理層用數(shù)據(jù)作為目標，聰明人就會利用系統(tǒng)作弊。我已經(jīng)數(shù)不清有多少次看到人們對代碼覆蓋率造假了。雖然初衷很好，但經(jīng)理們受到錯誤思想的誤導(dǎo)。為了討經(jīng)理開心，開發(fā)者會不斷編寫沒有斷言的測試。當然，代碼依然能夠運行而且不會出什么大問題。但這種行為有意義嗎？天知道！當你的代碼引入了新bug，那些測試能夠檢測到嗎？見鬼，當然不會！因此，這種代碼覆蓋率毫無用處。
盡管達到了指標，但是潛在的目標即改進軟件質(zhì)量卻被忽視了，而且未來也不會達到。
丑陋之處
任何測量的目標都是評測代碼并從中得出有意義的數(shù)據(jù)。以代碼覆蓋率為例，我們真正感興趣的是缺陷覆蓋率。也就是代碼中的所有可能的缺陷，有多少缺陷能夠在測試中被發(fā)現(xiàn)？我們想知道，能夠在怎樣的程度上避免重寫代碼。
問題在于，我怎樣才能衡量一個系統(tǒng)中“所有可能的缺陷”？基本上這是不可能知道的。為此，我們使用代碼覆蓋率作為近似。考慮到測試能夠保證代碼運行得到正確的結(jié)果，因此“被執(zhí)行代碼率”是對能夠捕捉到bug數(shù)量的一個很好的預(yù)測。如果我的測試執(zhí)行了50%的代碼，最好的情況下我們能夠捕捉到50%的bug。如果bug出現(xiàn)在另外50%的代碼中，那么通過我的測試捕捉到這些bug的幾率為0。代碼覆蓋率是測試覆蓋率的一個上限。但假如你的測試代碼很差，那么相應(yīng)的測試覆蓋率也會降低。至于沒有斷言的測試代碼，它們基本上毫無用處。
這就是測量數(shù)據(jù)困難之處：測量那些真正管用的數(shù)據(jù)即我們的軟件的質(zhì)量，即便有可能，也是非常困難的。因此，我們要盡可能地進行測量，但并不總是能夠清晰地知道哪些內(nèi)容與我們真正的目標相關(guān)。
這些數(shù)據(jù)意味著什么？
有很多類似Sonar這樣的優(yōu)秀工具能為你的代碼進行各種常用的數(shù)據(jù)評測。通常的問題在于，開發(fā)者并不了解（或者在意）這些數(shù)據(jù)的含義。類的復(fù)雜度是17.0是好還是壞？我的代碼關(guān)聯(lián)系數(shù)是5.6%，但是也許有更好的理由這么做。怎樣的數(shù)據(jù)對這段代碼而言才算是合理的？LCOM4（缺乏內(nèi)聚性的方法指標）是好事還是壞事？坦率的說，這聽起來更像是治療癌癥。
當然，如果我足夠積極主動的話，我應(yīng)該能夠深入并且了解每種數(shù)據(jù)的含義，并且試著達成合理的目標，等等等等。拜托，我正忙著給客戶交付有價值的工作，沒有時間扯淡。這些數(shù)據(jù)是在讓人難以捉摸，索性忽略掉好了。當然，領(lǐng)導(dǎo)們不這么認為。
一種更好的辦法
一定有一種更好的辦法來測量“代碼質(zhì)量”。
1. 達成一致
無論你測量的是什么，測量的內(nèi)容一定要得到團隊成員的贊同和理解。如果團隊中有一半的人表示反對，那么測量的結(jié)果一定不會很好。一些人努力想要改進，而其余的人則會讓事情變得糟糕。實際效果一定會讓人大失所望。
2. 測量最重要的部分
不必測量“標準”的內(nèi)容，像是代碼覆蓋率或者圈復(fù)雜度(cyclomatic complexity, 一種代碼復(fù)雜度的衡量標準)。只要團隊成員一致認為這是一項有用的數(shù)據(jù)，每個人都認為需要在這個方面改進并且做出承諾，那么測量它就是有用的。
我在youDevise的一個同事，花了10%的工作時間構(gòu)建了一個可以跟蹤測量數(shù)據(jù)并能夠以圖形的方式展示結(jié)果的工具。然而，非常特別的是，這個工具并沒有計算很多大型靜態(tài)分析工具給出的那些常見測量數(shù)據(jù)，而更多地統(tǒng)計了更加常見和具體的問題。那么，哪些是更貼近自己且更容易測量的呢？
• 如果你有一個上帝類，那么可以統(tǒng)計文件的代碼行數(shù)，行數(shù)越少越好；
• 如果你有一個想要避免使用的第三方函數(shù)庫，那么可以統(tǒng)計使用它的次數(shù)；
• 如果你有一個想要移除的類，那么可以統(tǒng)計引入這個類的次數(shù)。
這些簡單的測量代表了我們真正想要擺脫的技術(shù)債務(wù)，通過減少技術(shù)債務(wù)我們能夠改進自己代碼的質(zhì)量。與此同時，測量的方法也會異常的簡單，最直接的方式只需要執(zhí)行g(shù)rep和wc命令就可以。
測量什么并不重要，只要團隊相信你測量這些內(nèi)容會得到改進。通過測量你們關(guān)心的內(nèi)容，你會真正了解到你的代碼質(zhì)量。
3. 讓結(jié)果更直觀
最后，請把測量結(jié)果貼到顯示器上，與實際構(gòu)建狀態(tài)越接近越好。這樣每個人都能夠看到你正在做什么，并且能夠不斷提醒人們質(zhì)量的重要性。反饋是非常重要的，你能夠看到事情正在朝著更好的方向發(fā)展；同樣重要的是，當質(zhì)量開始滑坡時，數(shù)據(jù)圖能夠把問題上升的趨勢展示出來。
簡單，明了
代碼質(zhì)量是一個非常抽象的概念，因而很難測量。因此，你應(yīng)當轉(zhuǎn)而關(guān)注那些容易測量的東西。測量內(nèi)容越簡單、越容易理解，改進起來也越容易。如果你需要花時間解釋這些測量的意義，那么這里肯定有問題。嘗試一次只關(guān)注一部分內(nèi)容，如果你同時關(guān)注100項不同的數(shù)據(jù)，讓這些方面都能夠得到改進幾乎是不可能的。如果我們只關(guān)注其中的幾項，我就能記住他們，至少不會讓它們變得更差。我有可能把它們清晰的記下來，這樣才能夠改進它們。
你在測量自己的代碼嗎？如果是的，你測量的內(nèi)容是什么？如果不是，你認為可以測量哪些方面呢？
英文原文：David Green
it知識庫：測量你的代碼 - Measuring Code，轉(zhuǎn)載需保留來源！
鄭重聲明：本文版權(quán)歸原作者所有，轉(zhuǎn)載文章僅為傳播更多信息之目的，如作者信息標記有誤，請第一時間聯(lián)系我們修改或刪除，多謝。
