上千行的 SQL 代碼常見，且永不過時!

經(jīng)歷了大大小小的 MIS 系統(tǒng)，小到幾人用的協(xié)作系統(tǒng)，幾十人用的 OA 系統(tǒng)，到上千人用的 MES/ERP 系統(tǒng)，再到百萬人用的電商系統(tǒng)，存儲過程的影子在半個世紀以來從未淡出它的戰(zhàn)場。我們幾個 SQL 老玩家經(jīng)常自吹， SQL 是半衰期最長的編程語言。玩會它不用擔心失業(yè)。

[[258710]]

上回我們說到如何去拆一個上千行的 SQL 存儲過程，提到了四大步驟：理解代碼，分拆代碼，改寫代碼和保存代碼。拆過無數(shù)的代碼，從上千行縮減到 2 成，也組裝過無數(shù)的代碼，從上百行塞成了上千行，業(yè)務(wù)所需。見過最長的 SQL 代碼超 5000 行，已簡無所簡，那就實事求是了。人有分分合合，有生命力的代碼也一樣。

但裝和拆并不是一個逆反的過程!

1 理解業(yè)務(wù)：

你不可能寫出一個沒有業(yè)務(wù)邏輯的代碼。充分理解業(yè)務(wù)邏輯對你有兩個好處：一)寫出可執(zhí)行的并且可擴展的代碼;二)主動了解業(yè)務(wù)將有利于職業(yè)生涯升級。***個好處肯定不言而喻，寫代碼寫出頸椎病的程序員，不會意識不到代碼的擴展性可以讓你少跑多少趟醫(yī)院，讓你霸屏更多次王者。第二個好處可不是人人都意識到了。雖然 SQL 是最長職業(yè)生涯的編程語言，與其一起出現(xiàn)的 VFP 大概 90 后聞所未聞，但顯然沒人一輩子愿意鼓搗 CRUD 吧。玩吃雞的同學(xué)把你的 iPhone X 放下，家里有礦沒說你。

理解了業(yè)務(wù)你就成了整個應(yīng)用生態(tài)中不可缺少的一環(huán)。信息化的目的不是寫代碼，最終目的就是為了利潤?？炊?邱岳)就知道這話沒錯。

2 快速實現(xiàn)：

很多朋友(包括我)有時候碰到需求，苦思冥想，想的是一口氣把 SQL 從頭到尾完整的，暢快淋漓的寫出來。“Wow” 和漂亮的回車，就是憋著這口氣的期待。

但現(xiàn)實無數(shù)次打了我的臉!

越是有這種想法，越是憋得時間很長才寫那么一點。總覺得這里不好，那里不行，這里的變量名稱寫得不夠爽朗，那邊的 Pivot 寫得不夠優(yōu)化。結(jié)果往往是一個上午就在那里糾結(jié)，什么都沒完成。

你是不是也有類似的經(jīng)歷?不孤獨

再說一次《巴黎評論》。村上春樹、海明威、博爾赫斯，書里翻翻都是***遍爽快的寫下去了，一旦寫得卡殼了怎么辦，束之高閣，明兒繼續(xù)。所以我后來明白的事情，大家都可以猜得到了。先把業(yè)務(wù)實現(xiàn)了再說，命名規(guī)則，變量申明，事務(wù)控制以及性能優(yōu)化，統(tǒng)統(tǒng)先放起來。寫好 CRUD 交上***稿，存檔，Over!

3 重構(gòu)與測試：

如果僅僅到了第二步，就認為高枕無憂，那會死的很慘。你會成為別人口中的“豬一樣的隊友，坑貨……”

《巴黎評論》中，村上春樹提到他的小說經(jīng)常修改 4 - 5 遍才交稿，而且編輯還需要修改。我們一遍過的 SQL 就免檢了?這個時候再檢查命名規(guī)則，變量申明，事務(wù)控制以及性能優(yōu)化。直到滿足 ACID 的最小單元的 代碼塊完整的歸整到一個存儲過程或拆解成多個可重復(fù)使用的存儲過程中結(jié)束。

將所有的測試分支跑完測試，提交!

4 保存代碼：

如果你的團隊沒有 git, SVN, TFS 這些 Source Code Version Control, 趕緊上一個。沒有自動化部署工具，自己想辦法整一個。到 9102 年了，別偷懶吧。

摸著你的良心，看看這個圖，你都掌握了?