2011已經謝幕了，現在都流行總結，要是讓我總結2011，可以用2個詞來概括，辛苦、刺激。
辛苦是因為2011基本上是加了一年班，從過完年開始，到2012年過年前最后一周，這一年來，是我感覺最辛苦的一年，好在最終
項目算是打了個翻身仗，心里總算有了些慰藉。

       2011年游戲經歷從技術封測、內測、公測到整改、重新內測公測，一路走來，遇到無數稀奇古怪的Bug，
有時候壓力大的時候，晚上都睡不著，腦子里回想著現場的一絲絲蛛絲馬跡，希望能找到bug的原因，經歷過無數次絕望到重生的喜悅，也有被猜忌不信任的痛苦，活脫脫就是一部部偵探劇情。
  沒有從事過游戲開發或者游戲沒上線的同學很難理解:bug有這么難找嗎？的確，如果是簡單的空指針宕機，當然是好找的，用我們的話，這類問題是個傻子都能解決(其實不然，很多時候直接原因是空指針，
真正的原因隱藏很深)，但是更多的是隱藏很深的問題，需要反復的分析現場，假設劇情才能得到靈感，然后推演，才可能得到結果，當然，這個和游戲邏輯的復雜度是分不開的。
  具體的bug細節不便在此分析，但是大部分的問題，其實都是因為不正常的設計引起的，所以其實我一直在思考，在軟件開發領域，其實也存在著"道",說通俗點叫客觀規律，不按照道行事，遲早是要受到懲罰的。
但是在游戲后臺開發中，很多時候存在不同技術方案的矛盾，難以讓人取舍，這些矛盾都是真實在很多項目存在的。

動態內存還是靜態內存

      很多開發者由于擔心內存泄露，在項目中禁止使用動態內存(當然這實際上幾乎是做不到的)，使用對象池來避免動態內存，就是預先創建預計最大數量的對象，后續申請和歸還的時候，都是操作對象池，
避免動態new和delete。這樣的項目還不少，我見過的就好幾個。對象池的好處是顯而易見的，基本上可以避免內存泄露。但是實際上，這種方式是把雙刃劍，個人覺得在游戲項目中，這種方式弊大于利。
主要弊端有下面幾點：
1、開發不方便，導致需要添加很多的對象池管理類，即使有模板幫忙，也是非常繁瑣的。實際開發中，幾乎不可能對這些小對象類都搞一個對象池管理類。

2、由于采用預先生成對象，一般會預估一個對象可能存在的最大數量，然后按照最大數量來創建，浪費內存。
  的確，你沒有內存泄露，但是你啟動的時候就需要好幾個G的內存，這個是內存浪費，好在現在server開發基本都是64位，沒有地址空間的困擾了，但是，在大部分情況下浪費好幾個G的內存，
光想想都有點心疼。

3、引入了新的風險，由于采用對象池，申請新對象的時候，只是簡單的pop一個空閑對象就可以了，很容易漏掉對象初始化的工作，在回收對象的時候，大部分開發者也很容易漏掉清理工作，或者初始化和
清理工作過于簡單，這樣容易導致新對象被歷史操作影響。曾經遇到過一個新FB所有傳送點都打不開的問題，就是因為歷史對象回收時數據沒清理導致的。

    回頭來看對象池的優點，很多開發者堅持是為了解決內存碎片和內存泄露。先說內存碎片，暫且不說內存碎片真的是否有這么嚴重，退一步，其實內存碎片已經有很多的成熟解決方案了，自己重載smallObject還是
采用標準的tcmalloc解決，都是非常輕松的。至于內存泄露，個人覺得這個問題其實是很好查的，也是c++程序員的基本要求。

分模塊針對接口編程還是一鍋粥

     這個問題單獨提出來，幾乎所有人都會說，當然是分模塊針對接口開發了。和天下所有的事情一樣，知易行難。由于游戲邏輯項目影響的地方非常多，比如死亡的時候，既需要判斷死亡掉落，又需要處理任務狀態，
如果在戰場和競技場中，還要判斷基數和得分等等，這就導致很多開發者不假思索的把所有的東西都揉在一起，你中有我，我中有你，我改你的代碼你改我的。
一個最簡單的例子，我在項目中開發掉落功能，當把物品添加到玩家背包后，發現客戶端沒有更新背包，一查，居然還需要掉落的開發者自己構造數據包同步客戶端，其實作為其他模塊，根本不關心背包數據同步的細節。
這個其實在現實生活中很常見，我委托背包模塊添加一個物品，具體的細節是被由被委托人來負責的。將過多的細節交給其他模塊處理，會導致復雜度增加，容易出現問題，對其他人來說，也是一個精力浪費，如果是一個復雜
模塊，你會發現需要了解太多的細節，修改太多自己不熟悉的代碼，進而導致風險。還有一種觀點，認為一鍋粥的開發方式有助于了解游戲的各個業務模塊，對這種觀點，我是不以為然的，每天陷入到繁瑣的細節，真的對熟悉業務有好處嗎？或許閑下來玩玩游戲更有幫助，而且，這么亂的代碼，看起來也是非常累的。分模塊開發，具體的辦法，游戲編程精粹5上有篇文章寫得很好，這里不擴展了。

真的需要禁用STL嗎

  不止一次在和其他項目交流的資料里看到對方很威嚴的宣稱在項目里禁止使用STL。說實話，我還真沒覺得STL有什么不好。見過太多這類項目自己重復實現一個個蹩腳的排序算法、容器等等。
大部分人一般都會根據經驗選擇使用自己熟悉的技術，這個無可厚非，但是像這樣明著禁止使用STL，真不知道如何能理直氣壯。其實大部分不用STL的理由，基本上都是不熟悉，完全沒有足夠的理由禁止使用。

游戲開發無技術含量？
 
    曾經多次聽到行業內的兄弟有此感慨，確實，游戲邏輯復雜度非常高，架構上大部分都是類似的。但是這并不說明游戲后臺開發復雜度不高，如何將游戲開發邏輯復雜剝離開來，做到穩定高效開發，其實還是有很多
東西可以探討的，看看那些項目，大部分都是一鍋粥，需要什么功能就蠻干，加上去，這樣確實毫無技術含量，都是蠻干。所以，一件事情是否有技術含量，不光是看事情本身，還要看怎么干，蠻干和苦干，那是最沒有技術
含量的方式了，程序員還是要有強烈的“偷懶”意識。