系統的壞味道！沒有 Review 有多嚴重？你絕對不會想要看到的情況！(DBSchema篇)
小弟以前在看 XP 流程 時，得知原來程式碼有重構這件事。( 當時都認為 改寫 = 重寫 )
其中有一個非常重要的觀念就是 Review
因為沒有 Review 就不會知道 系統有沒有壞味道 ( 意指不好的程式碼 )
而這個習慣養成後，對其他人的影響力是非常強的。
每次問 DB Schema 重不重要！
相信很多人都會點頭再點頭。
但，一問到 DB Schema 有沒有人負責 Review 就……
沒有 FK 有多嚴重？
你絕對不會想要看到，上線後某些訂單資料中 的 Master 的部分居然不見了。
出現這種垃圾資料時，就算想要救也救不回來！ ( 去那裡生？)
沒有 Review 有多嚴重？
你絕對不會想要看到，在很多不同的 Table 中都有相同的 會員名稱相關欄位 或是 商品金額相關欄位 出現
到底那一個存的才是對的？那些是有被程式碼呼叫的？
明明都是關聯到同一筆資料，為什麼在不同的 Table 中會有相同的欄位名稱，而且更可惡的是 值 還不一樣
當問題每況愈下時，要進行資料庫重構的話。那程式改寫的成本會出乎你想像的大。
這裡 舉兩個例子就好~~ ( 還有很多更可惡的案例 )
若你是管理者的話，想想是否有遇到類似的問題？
不管有沒有 DBA ！不管有沒有走異動申請流程！
還是會出現怪怪的 DB Schema 架構
因為有隱私問題，所以圖就這麼大了！
可以看得出來，DB Schema 在規劃到中期後，就沒有人進行 Review 了
想要什麼功能就先加上去，即使有錯也是將錯就錯。
根本沒有人敢刪任何東西，因為根本不知道那一段程式會用到。
什麼？有畫 ER ？有更新 DB Schema 文件？
若真的有認真更新的話！為什麼還是無視這些問題？
再說…
這些文件真的有「同步」更新嗎？？
是否能知道每一次改版時，到底改了那些 Table 和 欄位呢？？
你們的 DB Owner 有參與需求異動嗎？？
若沒有，而且只是靠變更申請單來就更新，再加上不了解程式或是商業流程的話
根本沒辦法判斷新增加的 Table 或是 欄位是否是合理的
也許會說，我們都有做整合測試呀！
若只靠這個就能解決的話，那一切就太滿好了。 但這卻是難以達成的。
只要是做軟體開發，身為管理者就絕對不能忽視這個問題。
這跟你的公司是不是專門的軟體公司沒關係
這跟你的團隊人數多不多也沒有關係
因為殘酷的現實是 「事情不會因此變少的」
個人建議…
從即日起，就從自已開始養成這個習慣吧！免得以後更慘~~~
