真的輪到你來說「一年的SQL經驗重複了十年而已」？答對這四題再說

• 2019 年 12 月 26 日
• 筆記

01, 隔壁寫SQL的老王，55了

資訊系統還停留在 Visual FoxPro 的那個年代，能獨立寫個 MIS 系統就有人要你的那個年代。我畢業了，在一家電子集團公司（中國第六）做 MES 開發，用 FoxPro 寫介面，SQL Server 和 Oracle 做後台。

公司資訊部總共有 16 名軟硬體工程師，能寫程式碼的有 9 名，小張會 Delphi, 小夏會 VB, 我擅長寫 Vfp. 當然，現在的 90 後恐怕是不知道這些語言的，「這些都是啥，能寫爬蟲，還是能做數據分析，學會了能進BAT不 ？」

令人吃驚的是，最大年齡的老王，居然有 55 歲了，還是從別的公司借調過來，幫忙開發 MES 系統，也就是一個人在兩家公司任職，收兩份錢。(嗯，悄悄告訴你，加起來過萬是肯定的。我那時不到1.5K )

老王從來都是資訊部的首腦，雖然他不在PM的職位上。凡是有資料庫的改動，程式碼的簽入，都需要他老人家手工批。哪怕是一個欄位，一個編輯框的方位，大小。

當然，我是不理會的。上去就把一個欄位名字給改了，因那欄位名意思老糊塗了，跟老王長得差不多。結果中午懶洋洋在午睡呢，老王一個電話來了，我不知道當天是怎麼熬過來的，反正我就是被他叫到辦公室，坐他旁邊，看了他一下午是怎麼寫程式碼的。如何維護視圖啦，如何給參數命名啦，如何設計表結構啦，聽得我是耳朵嗡嗡的。

反正我就記住了一件事情，以後要改任何東西，先跟他說。

嘴上雖然依著老王的規矩來，但心裡是千萬個不願意的。什麼老思想嘛，改個表結構，改個表達式都要經過你同意。你不就是老了點嘛。各位看官可別笑，我敢打賭，你們開始編程時，心裡肯定同樣也不服氣你們的 Leader 給你改的程式碼。

嘴上說著知道啦，下次不會啦。但是真正下次 checkin 程式碼的時候，還是會時不時加入自己的寫法，我稱之為微創新。當然有些會被打回來，有些還會被老王稱讚，甚至還會問我從哪裡看到這樣的寫法。他一問，我就更驕傲了。頭揚得更高，話音更洪亮。有些朋友是不是在笑，說的是不是你？自己心虛的時候，音兒特別的小，十拿九穩的時候，找茬是不是聲音更大？一點小九九，誰沒年輕過啊！

02, 有種看看你2年前寫的程式碼啊

二年後，老王退休了。

我們這波人開始各自負責起熟悉的 MES 模組來。按照老王的規矩，相安無事的處了半年，大家都似乎合作的很好，介面也非常順暢，資料庫之間數據的同步也沒有太大的紕漏。

但你認為沒有問題的時候，問題一定會來找你！

公司因為連年盈利，開始有資金沉澱，準備上線新的晶圓製作系統。這意味著老的 MES 需要重新改造。於是，每個人開始忙碌起來，似乎每個人都知道怎麼去修改，因為大家都清楚了先前的流程，編碼技藝上也沒有太多的障礙了，所以各個胸有成竹。

隨著第一次內審的到來，我們的MES缺陷才暴露無遺！

首先，新的晶圓製作系統已經改用了大英寸圓片，製程路線早就發生了變化，但內審卻沒有從MES中明確的找到一條完整的路線，用現在的詞來說，就是 workflow 不清晰。而MES僅停留在上一版的路線上，究其原因，我們每個人自己硬編碼了一段路線在各自負責的模組里。

第二，整個生產線庫存檔點不明晰。每個製程完成時，應該有個半成品庫來管理。我們倒是有半成品庫，但從來都不集成，內審看到的都是零散的統計數據。老王曾經做了很多的視圖，來連接各種統計表，但在我們後期做庫存管控時，卻一張都沒用。不但沒用，連庫存這麼重要的統計資訊，都不曾想過去做個快照，純粹是靠SQL去實時的算。

再拿老王的舊版一對比，我們 8 個人面面相覷，原來程式碼早就成了一鍋粥，UI和SQL黏在了一起，完全分不開。

03, 你先寫好這四題

沒有對比，就沒有傷害。

在 SQL 編程這件事情上，只有更好，沒有最好。如果說演算法是泛編程的魂兒，那麼業務模型的表達，就是SQL的精髓。哪怕你SQL水平再好，碰到下一個項目，你也不敢說，一定就能hold住當前需求的模型設計。

比如，我這裡有四個小題，你可以嘗試自己想想模型如何建立？

A) 一張表中表達父子結構

B) 一張表中表達決策樹

C) 表達雙11歷史價格銷售差

D）銀行流水增刪改查