面對下不去手的程式碼怎麼辦

    不知道各位有沒有這種經歷，看到一個SQL寫的特別複雜，十幾個表關聯（如今的我已經見怪不怪了，深知這是為什麼。在一開始就沒有重視的情況下，這是必然的）。很多學員或者朋友發我的SQL開啟一看，真想直接關閉。面對這些下不去手的，我通常也只能閉上眼了。

    別說複雜的SQL，有的時候遇到極端問題即使簡單的SQL出問題也要檢查半天。資料庫是太複雜了。但是絕大多數企業的資訊化工作中不太重視這塊，一般是重研發輕運維、而資料庫排在運維之後，算是輕之又輕的。甚至把Redis、elasticsearch這些NoSQL資料庫都歸到中介軟體部分去，也沒有專職的資料庫專業人員。讓一般的運維人員來維護資料庫。其結果就是會出現上述問題。

   10多年前，我做資料庫維護，我覺得DBA（始終強調一下這個A不僅僅是administrator，還是analyzer和architect），應該是指導開發怎麼實現。後來我發現這個其實晚了，應該是指導開發設計、甚至是自己來設計，然後告訴開發如何實現。現在我發現其實這個也是晚了，要和業務說你不要這樣提需求，而應該這樣提需求。Oracle18C開始都開始自治資料庫了（現在不少資料庫也在向Oracle對標）。那麼DBA做什麼？其實就是做我剛才說的，和業務的拉扯以及主導設計，告知開發怎麼去做。否則就是出現這種下不去手的程式碼。

    每次我給求助的人的解決方案，都是要改動一些東西，有些是傷筋動骨的，也有的是重構建議。但是即使是小的改動，在開發看來代價也很大。這種問題上升到領導層面也很難抉擇。

    不過我這幾天看到一句話： 發現錯誤馬上改進，再大的代價都是最小的代價。頓時治癒了，說的太對了。因為現在不改，在錯誤的繼續做下去，將來代價還要大。

    收尾講個故事：以前就有開發找我說：“我們實在沒有辦法了，決定採用你的方案”。其實也就是說代價大不大其實不重要，只是沒被逼到那個非改不可的地步。當計算資源已經無法承受爛SQL而且無法補充了，那麼這個時候代價大不大就不重要了。