宕机，回档，亡羊补牢之外我们是不是应该做些什么 .

http://blog.csdn.net/xiaohyy/article/details/4362323

网络游戏在封测，内测，直至公测期间，宕机回档几乎是家常便饭，游戏开发商焦急的在玩家的抱怨声和流失的过程中做着亡羊补牢的事情。我有过这种经历，公测时的火爆和几个月后的冷清形成了鲜明的对比。这对公司的损失是相当大的，前期投入的巨额广告带来的效益也付之东流，再在后期游戏稳定后依靠运营手段把玩家拉回来变得相当困难并且成本不菲，基于这种事实，很多人会把责任推向程序员——没能提供稳定的发布版本。

      在这里我并不想为程序员开脱，作为软件的实现者，程序员有着不可推卸的责任。痛定思痛，作为开发人员我们是否应该反思一下，如何才能开发出稳定的软件。我和公司领导及部分开发人员交流过这个问题，他们大多数认为bug的来源是因为“不够细心”，低级错误太多诸如此类的说法。于是日复一日的解决bug，解决了老bug，又产生新bug，这很容易让人联想到人月神话里面描述的焦油坑。

      我们再分析一下，按照领导的思路，由于是“不够细心”产生的低级bug导致了产品的不稳定，那么我们只要有足够的“细心”就可以避免这个问题，于是可以就工作态度，加薪，bug责任制这些政策出台，直接针对“人”提出最终的解决方案。实际效果如何，我就不多说了，后面谈谈我的看法。

      从历史角度来看，单机游戏早期的开发者都是传说中的“精英”程序员（即使他们在做游戏之前不是），可能是本身游戏规模不大，或者逻辑简单（相对于现在的网络游戏来说），经过几个月的bug修正和稳定完善之后，即可发布一个稳定的游戏版本。因此，游戏精英论自然深入人心，认为做游戏软件的程序员比做其他软件的程序员更牛更强大。从开发团队的组成结构来看（这里不讨论策划和美术），程序团队通常由一个牛B哄哄的主程和几个不那么牛B的程序员构成。从开过过程上来看，通常是由主程制定开发计划，然后设计整个软件架构，根据这些设计划分模块，然后把模块分派到人头上，然后大家开始埋头编码，中途和策划及其他程序不断交流，集成。一切看起来都很自然。

 

让我们从以上几个方面来分析这个问题：
      1：游戏精英论。近几年经常在网上看到某某报告，称国内游戏人才缺口XX万，我是同意这个观点的（仅限于人才缺口，至于是不是XX万只有搞数据分析的人才知道），现在的游戏开发团队门槛其实并不高，就我们公司来说，每年都会招收好几个应届毕业生（没有贬低应届毕业生的意思，优秀的应届生同样是企业很需要的），几乎没有培训马上就投入开发当中。这里举个例子，在闲谈的时候，一个游戏的主程说的，他花了一天时间查找一个宕机bug，结果是某个人设计了一个struct，其内部有std::string成员，然后把这个struct memset为0。这类例子数不甚数，指针乱跳的例子就更不在话下。

      2：开发过程方面，可能我一直就职于中小企业的原因，给我的感觉是软件工程对中国游戏开发很遥远，甚至可以说软件工程对大部分软件企业来说都很遥远。我所了解的游戏圈子内，基本上都是作坊式的开发方式.这方面，我的观点是，如果真的都是传说中的“精英”程序员，那采用这种开发方式也未尝不可，否则还是适当引入一些质量保证机制的好。

      3：资金问题，很多游戏产品都急于出笼，一款MMORPG的开发周期通常是2年，仅仅开发成本1年大概也需要个几百万，在资金紧张，进度压力下，通常会选择某种方式的妥协。

      4：再者，由于见效果的时间较长，如果研发过程未控制好，核心人员离职，同行竞争挖角等，交接过程中也会出现很多问题，最终导致产品质量低下。

 

      个人觉得，最关键的问题还是人的问题，包括能力和态度。对于态度有问题的开发人员，应坚决辞退。技术人员的能力差距是不可避免的，作为主程序，应该知人善任，把每位技术人员分配和适合他们的岗位上，如果有条件，可做通过技术交流等方式提高整体团队的技术能力。(最理想的团队是一个能管理好一群牛B哄哄的程序员的管理者和一群牛B哄哄的程序员:D)

      然后是公司的大环境方面，包括工作环境，企业文化，薪酬福利，晋升制度，这些因素对团队士气会起到很大的正面或负面的作用。但这部分通常由boss决定，希望你能遇到一个好boss。:D

      加强产品质量意识：让团队成员意识到产品质量的重要性，在对进度压力做妥协时，应妥协功能而不是质量，要记住，如果你在质量方面做了妥协，你就欠下了一笔债，欠债是需要偿还的。

      项目管理方面：应加强人员，项目进度和质量的管理，形成一个有凝聚力的团队。

      软件过程方面：如果可能，可以加入代码审查过程，通过交叉方式的代码复查，研究表明，xx%的bug能通过直接查看代码暴露出来，同时交叉代码复查也降低了开发人员流失带来的风险。同时也可考虑做单元测试和日构建，甚至尝试一些自动化构建，比如编写一个自动化脚本每天半夜从代码库中check out源代码，然后自动编译，运行单元测试，第2天到公司看结果。