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

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

動態(tài)內(nèi)存還是靜態(tài)內(nèi)存

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

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

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

    回頭來看對象池的優(yōu)點(diǎn)，很多開發(fā)者堅(jiān)持是為了解決內(nèi)存碎片和內(nèi)存泄露。先說內(nèi)存碎片，暫且不說內(nèi)存碎片真的是否有這么嚴(yán)重，退一步，其實(shí)內(nèi)存碎片已經(jīng)有很多的成熟解決方案了，自己重載smallObject還是
采用標(biāo)準(zhǔn)的tcmalloc解決，都是非常輕松的。至于內(nèi)存泄露，個人覺得這個問題其實(shí)是很好查的，也是c++程序員的基本要求。

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

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

真的需要禁用STL嗎

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

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