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的理由，基本上都是不熟悉，完全没有足够的理由禁止使用。

游戏开发无技术含量？
 
    曾经多次听到行业内的兄弟有此感慨，确实，游戏逻辑复杂度非常高，架构上大部分都是类似的。但是这并不说明游戏后台开发复杂度不高，如何将游戏开发逻辑复杂剥离开来，做到稳定高效开发，其实还是有很多
东西可以探讨的，看看那些项目，大部分都是一锅粥，需要什么功能就蛮干，加上去，这样确实毫无技术含量，都是蛮干。所以，一件事情是否有技术含量，不光是看事情本身，还要看怎么干，蛮干和苦干，那是最没有技术
含量的方式了，程序员还是要有强烈的“偷懒”意识。