從遊戲開發到應用開發的轉變

從2011年大學畢業到2014年年底，這段時間我的軟體開發生涯是在遊戲圈子裡渡過的，雖然終究並沒有做出什麼名堂來，但是至少也是混到了伺服器主程的位置；遊戲開發的那些日子，大概也是進步最快的日子，回憶起來自己的部落格裡面比較有質量的文章都是那段時間寫的，尤其是面對上線和大併發的時候，對於軟體和程式碼的理解有了不同於剛畢業那會的理解，我想大概也是專案推動成長吧！

       時間來到了2014年年底，隨著自己對於遊戲開發的興趣驟減和於策劃方案衝突的急劇加深，慢慢產生了離開這個行業的想法，於是就在那個契機，自己放下了一切切入到了應用的開發！

       記得第一個應用是一個手機端的應用，大概是一個類似於微博那樣的應用，當然功能要弱化的多；簡單被帶著入門app端之後，發現伺服器端的邏輯完全無法入手；最後也是在網上抄了一個redis的微博的例子；在這個例子的基礎之上開做起來了。那個應用的資料庫沒有使用mysql，而是直接使用的redis，現在無論如何我也不會這樣了吧。沒有用mysql也主要是因為自己對於mysql的不熟悉，做遊戲的時候對於資料庫的使用處於全部nosql或者簡單mysql的狀態。比如我們只會設計一個玩家表，可能很多人要說玩家不是很多屬性嗎？一個表怎麼夠用，其實我們是把很多玩家的資料全部封裝成json，base64轉換，zip壓縮，已text形式儲存到mysql的表中。這樣幾乎mysql中兩三個表就能儲存遊戲中所有的資料；可是到了應用層則就不一樣了，一個微商城都幾乎使用近一百個表，還要處理個個表之間的關係，試圖等等。

       做遊戲伺服器的時候，寫邏輯幾乎不與資料庫打交道，而現在寫應用卻幾乎很難離開資料庫。寫遊戲的時候，比如做一個幫戰系統，進入到幫戰裡面所有的人，都是登入玩家，玩家資料已經全部載入到記憶體中，和他互動或者的其他玩家都是這個場景內的其他的玩家，資料也早已經載入到記憶體中，任何一個打鬥，互動，移動等邏輯處理，都是處理記憶體中資料和邏輯。做應用就不一樣了，應用中使用者之間互動的載體變成了資料庫，而不再是記憶體，如果使用者A想要得到使用者B的行為，那麼使用者B的行為首要要被儲存到資料庫中。這一點是在從遊戲伺服器轉向webapp的過程中最痛苦的也是最難理解的，至少我個人是這個情況。記得自己第一個php小應用，把MySQL的連線做成了全域性變數；以為這樣每個連線都能共享；知道後來發生了mysql連線不夠用的情況。

       對於遊戲來講，資料庫只是一個玩家下線暫存玩家資料的地方；也就是說並不是重中之重；而對於應用來講則不一樣了；資料庫除了儲存著應用所有的資料，還可以用來驅動邏輯，比如觸發器，遊標，等等。比如排行使用order等。所以這造就了遊戲程式設計師看到一個業務或者模組，首先想到使用怎麼樣的資料結構。而對於應用程式設計師看到了一個業務和模組首先想到了是如何設計資料庫；我現在看到了很多應用開發者再處理一個邏輯的時候，首先想到的並不是從資料結構上做文章；而是首先改變資料表設計。

       在做遊戲開發的時候，是把nosql作為主資料庫設計的，在我開發遊戲的前兩年，都是用mongo作為主要的資料庫；但是到了應用上，nosql還是用來作為一些特定模組的解決方案，或者是為了快取一些常用資料。比如商城系統，對於經常遊覽的商品，我們就把它儲存到redis中，對於首頁，我們也直接將首頁的html+css資料儲存到redis中；但是在應用中把nosql作為主資料庫，遇到複雜的邏輯，比如商品銷量統計或者訂單統計之類的需求，用redis就勉為其難了。

       軟體開發是一個行業，可是這個行業內不同應用層之間也似乎像是隔山似的，有著不同的開發原則和準繩；我們從一個應用層到另一個應用層，也應該抱著謙卑的姿態，首先做到融入，再熟悉，然後再想著發揮自己的才能才好！