幹掉你程式碼中的壞味道

原文出自【聽雲技術部落格】：http://blog.tingyun.com/web/article/detail/1094

最近團隊開始抓程式碼質量了，總結一下自己的經驗，先看看壞程式碼有哪些特點：

“都一樣,不幸的家庭卻各有不同”，這句話放到程式碼裡也同樣適用。接下來，我們聊一聊如何解決壞程式碼問題。

如果我問你，“你們是如何保證團隊程式碼質量的”，你的回答可能是：“我們每次寫完程式碼，都會花一些時間review一下。”

恩，做的確實不錯，但是，做的還不夠，除非你是門門考試都100的學霸，否則，藉助一些工具還是比較穩妥的辦法。

在這裡簡單介紹一個程式碼分析工具RubyCritic，這是一個專門針對Ruby的一個靜態程式碼分析工具。其它語言的，也有相似功能的工具鏈，我就不做介紹了。

這是一個命令列工具,第一步就是新增到你的gem庫中，當然，還可以使用guard自動化分析。（Ruby的世界，你懂得~） 第二step，在console執行【RubyCritic】命令，就像這樣：

在命令的最後，會生成一個靜態頁面。長這個樣子：

x軸代表改動頻率，Y軸代表程式碼複雜程度

這是分析結果的overview，超過200的複雜度的，基本都是壞程式碼。

再看看code裡的內容：

對不同檔案按照改動頻率、複雜度、重複度和壞味道4個維度進行綜合評定程式碼質量等級（和美國考試的成績打分規則一樣）。

再看看Smell裡的內容 ：

RubyCritic對程式碼分析的原理，其實就是分析一些，被它認為是壞程式碼的點。注意，我這裡使用的措辭是“被它認為，所以，有時候，它不是絕對的正確。” 還可以檢視具體的類檔案中的程式碼質量問題。

更多的介紹，詳見 https://github.com/whitesmith/rubycritic

下面，我們針對RubyCritic給我們的一些壞程式碼的點，有針對性的做些程式碼調整。

這裡使用git diff 比較新舊版本的差異。operator原來是例項方法，程式碼行7，並且裡面還有一個if結構體。started_time_and_node 原來是例項方法，程式碼行4，並且裡面還不止一個if結構體。

筆者review的方式：

1.例項方法修改為類方法（減少混入方法，解耦合，減低負責度）

2.多使用Ruby原生鏈式操作（減少中間變數，更少的程式碼，對於指令碼語言，就是更快的執行效率，而且很多原生方法是C語言實現。）

3.去掉結構體 （現代程式語言的結構體，讓程式碼具有豐富的邏輯性和可讀性，但是缺點就是cpu的額外開銷。）

以上部分，屬於語法層面的奇技淫巧。

第二部分，我們從設計角度分析一下。

它的程式碼行只有141行，方法也只有7個。但是評級卻是C。再看看程式碼分析細節，這裡就展現一小部分，簡直就是慘不忍睹，不好意思全展現給大家看了。

沒有人會一開始就這樣寫程式碼，這種壞程式碼，永遠都是漸漸變餿的。不過筆記仔細想來，當年遇到過比著還餿1000倍的程式碼（1000倍都不算過分）。

這是筆者做的第一版重構結果。

這裡使用了策略模式。Stats_hash不再是充當一個集合的作用，現在變成了一個環境類，將原來依賴if結構資料分裝到不同的行為類中。

第二版的改動計劃是，引入work-job的模式，併發執行4個job。

第三版改動計劃就是利用回撥方式，去掉與該類不相干的程式碼，將邏輯分裝到行為類裡。

好了，寫到這裡，基本的程式碼層面的優化思路就這些了，其它就是開支散葉的過程，這裡就不冗餘了。下一節，我們倆聊一聊效能優化的一些思路。