面向數據編程

最近一陣在做一個自動化的工具，把一些機械化的重複工作，用配置數據的形式固化下來，自動進行，配置數據儘可能簡單明了，最好能讓產品經理也可以操作，這樣就可以大大解放生產力。

由此，我不由得感嘆，數據真是程序員和非程序員之間交流通信的良好媒介——看不懂代碼？數據總能看懂吧？

面向數據編程的第一個好處，就是將程序員從日常瑣碎的工作中解放出來，把身上的負擔分出去，然後去做更有意思的事情。

昨天吃午飯的時候，組裡的一個萌新小伙跟我閑聊起軟體設計，問什麼時候該使用類包裝一下，什麼時候該使用繼承，什麼時候又該使用組合等等問題。遙想當年，我也曾這樣有激情有衝勁，什麼都想問個為什麼。扯遠了，說回這件事。這時，作為一個「老」程序員，為了逼格，當然要祭出大名鼎鼎的「Gang of Four」的設計模式經典書籍，當然，最後還是要補充一句，「看情況」。補充這句的主要原因，其實就是如果陷入GoF的設計模式之中，很容易過度設計，將一個簡單的功能設計的疊床架屋，得不償失。

這時，如果能心中牢記面向數據，以解析數據為依託設計程序架構，以簡化數據為目的演進程序架構，往往很多模式的使用就是很自然而然的事情。

所以這是面向數據編程的第二個好處，有助於程序架構設計向更好的方向演進。

在接手一個新項目，或者閱讀別人的程序時，我經常會發現，通過數據能夠更加方便的理解整體架構，因為數據往往是和業務緊密相關的，數據在說明業務「是什麼」，而代碼是在說明業務「怎麼做」，上來就看執行方案，經常是搞得一頭霧水。數據和代碼往往能互相印證，互為解釋，大大增加程序的可讀性與可維護性。

在做遊戲開發時，這方面可以說做到了極致，數據與邏輯分離又互為解釋。對於一些陳年老系統，找不到當年的開發者時，通過和策劃、QA一起同時研究對應的數據表以及相應代碼，往往就能把相關的結構理解的七七八八。

這裡，就是面向數據編程的第三個好處，有助於增加程序的可讀性與可維護性。

最後一個好處，也是往往對程序員最「有用」的好處，就是甩鍋啦！對於一個完善的面向數據的功能模塊來說，進入運營期後，往往就可以直接交付給策劃/PM/運營，對相關的數據進行維護了。這裡，一方面，技術責任大幅降低；另一方面，出了問題也會優先考慮是數據表沒有填對。再者，線上問題，無需修改代碼邏輯，只需修改數據文件重新載入即可，心理壓力也大大降低。

總結一下，所謂「面向數據編程」，至少可以帶來以下幾個好處：

所以，回顧最近寫的代碼，找出那些可以抽取出數據的部分，面向數據編程走起吧！

喜歡這篇文章嗎？立刻分享出去讓更多人知道吧！