特別爛的代碼到底是什么樣的?
本人做了十多年軟件開發,爛代碼和神代碼都見過不少,這里分享一個印象比較深刻的爛代碼的經歷。
有一次部門重組,接手了一個由印度團隊開發的項目。拿到手后,我和我的小伙伴們都驚呆了,心想他們一定是按代碼行數發工資的,寫得繁瑣無比,數據庫里的存儲過程各個都上千行,質量非常低下。
但令人驚訝的是,這一堆在我們眼里看來隨便拎起一個片段都到處是bug代碼,雖然性能極差,但運行結果居然總是對的…這就讓人百撕不得其姐(解)了 。然后我們嘗試仔細去分析,發現往往一個地方犯了錯,后面某個地方會有一段代碼把中間結果強制修正一下,藍翔挖掘機般的神技能。?
一段時間后,一個數據庫存儲過程突然運行時開始報錯,我不得不一臉厭惡的深入去研究。毫無例外,這個上千行的存儲過程,代碼質量也是非常差,讀取多個數據表,用循環的方式一行一行計算,根據結果進行增刪改查。一般而言,在存儲過程中,應該盡量通過表關聯和集合操作來批量處理數據,避免CPU密集性的計算。雖然寫得爛、性能差,但仔細研究邏輯,貌似也沒錯。一番調試后,發現居然兩個循環塊共用了一個循環變量,反復加一之后,循環變量溢出了?!!! 這種事情通常只發生在傳說里,居然在有生之年被我碰到了?!
看懂了數據處理邏輯后,我把存儲過程的代碼直接全刪掉,一條SQL語句搞定(是的,他們的上千行代碼,價值就等同于一條語句!!!…),執行速度也由半個小時縮短到了幾秒鐘…幾秒鐘…幾秒鐘…, 而這家公司居然是…微軟!微軟!微軟!?(雖然代碼是外包員工寫的)。