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

      從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等。因此這造就了遊戲程序員看到一個業務或者模塊，首先想到使用怎麼樣的數據結構。而對於應用程序員看到了一個業務和模塊首先想到了是如何設計數據庫；我如今看到了不少應用開發者再處理一個邏輯的時候，首先想到的並非從數據結構上作文章；而是首先改變數據表設計。對於遊戲程序員來說，彷佛天生的拒絕多哪怕一次的sql操做，能在內存中解決的，不在數據庫中作。

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

      軟件開發是一個行業，但是這個行業內不一樣應用層之間也彷佛像是隔山似的，有着不一樣的開發原則和準繩；咱們從一個應用層到另外一個應用層，也應該抱着謙卑的姿態，首先作到融入，再熟悉，而後再想着發揮本身的才能纔好！