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

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

[[258710]]

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

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

1 理解業務：

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

理解了業務你就成了整個應用生態中不可缺少的一環。信息化的目的不是寫代碼，最終目的就是為了利潤。看二爺(邱岳)就知道這話沒錯。

2 快速實現：

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

但現實無數次打了我的臉!

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

你是不是也有類似的經歷?不孤獨

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

3 重構與測試：

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

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

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

4 保存代碼：

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

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