特別爛的代碼到底是什么樣的？

本人做了十多年軟件開發(fā)，爛代碼和神代碼都見過不少，這里分享一個印象比較深刻的爛代碼的經(jīng)歷。

有一次部門重組，接手了一個由印度團(tuán)隊(duì)開發(fā)的項(xiàng)目。拿到手后，我和我的小伙伴們都驚呆了，心想他們一定是按代碼行數(shù)發(fā)工資的，寫得繁瑣無比，數(shù)據(jù)庫里的存儲過程各個都上千行，質(zhì)量非常低下。

但令人驚訝的是，這一堆在我們眼里看來隨便拎起一個片段都到處是bug代碼，雖然性能極差，但運(yùn)行結(jié)果居然總是對的…這就讓人百撕不得其姐(解)了 。然后我們嘗試仔細(xì)去分析，發(fā)現(xiàn)往往一個地方犯了錯，后面某個地方會有一段代碼把中間結(jié)果強(qiáng)制修正一下，藍(lán)翔挖掘機(jī)般的神技能。?

一段時間后，一個數(shù)據(jù)庫存儲過程突然運(yùn)行時開始報(bào)錯，我不得不一臉厭惡的深入去研究。毫無例外，這個上千行的存儲過程，代碼質(zhì)量也是非常差，讀取多個數(shù)據(jù)表，用循環(huán)的方式一行一行計(jì)算，根據(jù)結(jié)果進(jìn)行增刪改查。一般而言，在存儲過程中，應(yīng)該盡量通過表關(guān)聯(lián)和集合操作來批量處理數(shù)據(jù)，避免CPU密集性的計(jì)算。雖然寫得爛、性能差，但仔細(xì)研究邏輯，貌似也沒錯。一番調(diào)試后，發(fā)現(xiàn)居然兩個循環(huán)塊共用了一個循環(huán)變量，反復(fù)加一之后，循環(huán)變量溢出了?!!! 這種事情通常只發(fā)生在傳說里，居然在有生之年被我碰到了?!

看懂了數(shù)據(jù)處理邏輯后，我把存儲過程的代碼直接全刪掉，一條SQL語句搞定(是的，他們的上千行代碼，價值就等同于一條語句!!!…)，執(zhí)行速度也由半個小時縮短到了幾秒鐘…幾秒鐘…幾秒鐘…， 而這家公司居然是…微軟!微軟!微軟!?(雖然代碼是外包員工寫的)。