做游戏属于什么程序员？

程序员是游戏产业中的老兵了。

在游戏产业刚刚开始发展的那段时间，制作一款游戏往往是一个人的事情，而那个人必须在精通编程的同时，还极富技术创造力。

时至今日，虽然许多程序已经发展到模块化，但对游戏程序员来说，岗位仍然要求他们具备较高的技术水平和创造力，因为不论游戏性和情节对一款游戏有多重要，如果没有最基本的技术支持，所有的游戏性和情节都只可能建立在空中楼阁上。

程序员必须具备技术水平和创造力的另一个原因，是为了符合玩家的需求。

无论如何，玩家都希望展现给他们的游戏，能够将现有的硬件和技术发挥到极致，他们想要更快的运行速度、更好的人工智能、更高的画面解析度、更华丽的特效和更真实和深刻的游戏置入感。所以基本上每一款新游戏都要结合新的程序技术，因为只有程序员在不断地进行着技术的革新，游戏才可能真正做到让玩家满意。

由于国内主要的开发重点都放在网络游戏上，因此从国内现有的开发环境来看，程序人员大致可以分为以下一些类型：

1、引擎开发人员(enginedevelopers)

他们是负责构建游戏基础平台的专业程序员，与其它程序人员相比，他们更专注于开发一个可供别人利用的引擎，他们会将更多的时间和目光放在对游戏逻辑和游戏内核的研制和封装上。

2、客户端程序员

客户端程序员通常负责网络游戏客户端的研发，他们更强调游戏的画面表现和一些人机界面的效果，所有玩家在玩一款网络游戏之前要下载的客户端，就是这些程序人员的工作成果。

近年来随着游戏3D化的持续进行，客户端程序员也开始逐渐从之前的2D美术表现向3D美术表现转移，通常来说客户端程序员都是强调画面和图形的，因此站在纯程序员的角度分类，客户端程序员也可以称为图形程序员(graphicsprogrammers)。

3、服务器端程序员

与客户端程序员相对应的是服务器端程序员，他们负责网络游戏服务器端的研发工作。由于网络游戏的特点，服务器端程序员往往更强调的是对游戏数据的处理和计算，而对游戏的画面表现并不在意，服务器端程序员必须让自己的程序能够接收和发送来自客户端的数据包，同时还要对这些数据进行相关的计算。相比较而言，服务器端程序员更强调对游戏引擎的掌握，因为游戏的服务器端是否稳定，是真正决定一款游戏能否被广泛接受的主要原因之一，同时服务器端程序的好坏，直接关系到对游戏系统的维护和优化，甚至关系到外挂等网络游戏常见的相关问题。

4、开发工具程序员(ToolsProgrammers)

开发工具程序员负责创建支持游戏开发的各种工具。

由于游戏的研发工作是合作的产物，因此在游戏研发的过程中，程序人员往往需要开发出一些专用的工作，用来给相关人使用，最常见的就是游戏的地图编辑器等，还有一些诸如特效编辑器、后台管理工具等。

在国内，工具程序员往往是由其它岗位的程序员来兼任，这种不明确的分工也正代表了国内游戏产业的不成熟。

5、其它程序人员

除了上述几种程序人员之外，程序人员还可以根据工作的内容，分为负责编写人机界面的界面程序员（interfaceprogrammers）、负责网络数据交换及优化的网络程序员（networkandmultiplayerprogrammers）、负责实现游戏人工智能的人工智能程序员（AIprogrammers）、负责将音乐音效添加到游戏中的音乐音效程序员（audioprogrammers）以及负责测试和保障游戏软件质量的测试程序员(QAprogrammers)等。

当然，并不是所有的游戏公司都会如此细致地对程序人员进行职能划分，正如前文所说的那样，行业的不成熟性让游戏公司在对岗位职能的描述过程中，充满了灵活性和模糊性，因为对国内现阶段的游戏研发来说，重要的是能否做出产品，而不是如何去进行细致的分工。

不过随着行业的不断成熟以及行业规范的持续建议，相信一个更完善的程序人员工作职能划分体系，会很快出现在所有从业者的面前，因为行业规范的过程，就是岗位职能明确的过程。

对于大多数运维程序员来说，时时刻刻都需要关注服务器和系统程序可能出现的问题并提前解决。
今天我们就通过案例分析来了解一下，运维程序员如何快速处理线上问题。
任何一旦掉进坑里，明智的做法一定是：跳坑_>填坑_>避坑，线上故障处理的过程也一样，优先级从高到低，线上故障处理的目标如下：跳坑‘跳坑’——快速恢复线上服务，或者将对线上服务的影响降到低。
线上服务的可用性决定着服务者的客户利益，影响着公司的收益。
一旦线上环境不可用，无法服务用户，给公司/团队带来经济利益损失的同时，更为严重的会给公司/团队带来恶劣的名声。
所以一般公司都会对线上环境提出稳定性和可靠性的要求，这也是团队乃至部门的kpi。
为此，遇到生产故障后的一要务是：恢复生产服务，即使不能完全恢复线上服务，也要想尽办法将对线上服务的影响降到低。
填坑‘填坑’——找到问题原因，根本上解决问题。
在恢复线上服务，尽大限度减掉对用户/公司/团队带来的影响后，我们需要彻查问题，搞清楚故障发生的根本原因，从根本上解决问题。
通常情况下，‘填坑’和‘跳坑’是同步在做的，完成‘填坑’也就意味中‘跳坑’成功，但是也有一些紧急情况下的特别‘跳坑’方法，比如重启服务，或者服务降级/熔断等等，实际并未在当时完成‘填坑’，而是先采取非常规手段‘跳坑’，之后再慢慢‘填坑’。
避坑‘避坑’——举一反三，消灭隐患。
找到了根本原因，解决了问题之后，我们需要举一反三，以此及彼，想想在这个故障排查和处理过程中，那些环节存在弱点那些流程/规范/制度需要优化这类问题是否在其他系统或者团队中也存在通过这样的反思和自我批评，形成一份线上事故报告，不断完善流程，避免再次踩坑，也在团队中交流经验，共同提高。
线上故障处理的思路依据线上故障处理的目标及目标的优先级，线上排障的一目标是恢复线上服务或者降低对线上服务的影响，关键点在于快速二字，在‘跳坑’-‘填坑’之后，再行回溯总结，以便‘避坑’。
因此，可以将线上故障处理的步骤分为：故障发现故障定位故障排除故障回溯其中前三步是‘跳坑’行为，后面一步包含了‘填坑’和‘避坑’。
上述步骤并不是说要从上到下顺序进行，建议在不乱阵脚的情况下，并行去做，因为通常线上故障后会紧急启动故障处理程序，运维、开发、测试、产品各个角色都会参与进来，这时候分工下去，并行去做，不断汇总消息，做出判断，以求快速排障，恢复服务。
这个思路类似于 *** 作系统的fork/join设计思想，目的在于提高效率。
在无法快速找到故障原因的时候，需要果断跳过故障定位环节，直接进行故障排除，比如采用服务降级、服务器扩容等手段，确保对线上服务降到低且可控。
湖北北大青鸟>