程序员是游戏产业中的老兵了。
在游戏产业刚刚开始发展的那段时间，制作一款游戏往往是一个人的事情，而那个人必须在精通编程的同时，还极富技术创造力。
时至今日，虽然许多程序已经发展到模块化，但对游戏程序员来说，岗位仍然要求他们具备较高的技术水平和创造力，因为不论游戏性和情节对一款游戏有多重要，如果没有最基本的技术支持，所有的游戏性和情节都只可能建立在空中楼阁上。
程序员必须具备技术水平和创造力的另一个原因，是为了符合玩家的需求。
无论如何，玩家都希望展现给他们的游戏，能够将现有的硬件和技术发挥到极致，他们想要更快的运行速度、更好的人工智能、更高的画面解析度、更华丽的特效和更真实和深刻的游戏置入感。所以基本上每一款新游戏都要结合新的程序技术，因为只有程序员在不断地进行着技术的革新，游戏才可能真正做到让玩家满意。
由于国内主要的开发重点都放在网络游戏上，因此从国内现有的开发环境来看，程序人员大致可以分为以下一些类型：
1、引擎开发人员(enginedevelopers)
他们是负责构建游戏基础平台的专业程序员，与其它程序人员相比，他们更专注于开发一个可供别人利用的引擎，他们会将更多的时间和目光放在对游戏逻辑和游戏内核的研制和封装上。
2、客户端程序员
客户端程序员通常负责网络游戏客户端的研发，他们更强调游戏的画面表现和一些人机界面的效果，所有玩家在玩一款网络游戏之前要下载的客户端，就是这些程序人员的工作成果。
近年来随着游戏3D化的持续进行，客户端程序员也开始逐渐从之前的2D美术表现向3D美术表现转移，通常来说客户端程序员都是强调画面和图形的，因此站在纯程序员的角度分类，客户端程序员也可以称为图形程序员(graphicsprogrammers)。
3、服务器端程序员
与客户端程序员相对应的是服务器端程序员，他们负责网络游戏服务器端的研发工作。由于网络游戏的特点，服务器端程序员往往更强调的是对游戏数据的处理和计算，而对游戏的画面表现并不在意，服务器端程序员必须让自己的程序能够接收和发送来自客户端的数据包，同时还要对这些数据进行相关的计算。相比较而言，服务器端程序员更强调对游戏引擎的掌握，因为游戏的服务器端是否稳定，是真正决定一款游戏能否被广泛接受的主要原因之一，同时服务器端程序的好坏，直接关系到对游戏系统的维护和优化，甚至关系到外挂等网络游戏常见的相关问题。
4、开发工具程序员(ToolsProgrammers)
开发工具程序员负责创建支持游戏开发的各种工具。
由于游戏的研发工作是合作的产物，因此在游戏研发的过程中，程序人员往往需要开发出一些专用的工作，用来给相关人使用，最常见的就是游戏的地图编辑器等，还有一些诸如特效编辑器、后台管理工具等。
在国内，工具程序员往往是由其它岗位的程序员来兼任，这种不明确的分工也正代表了国内游戏产业的不成熟。
5、其它程序人员
除了上述几种程序人员之外，程序人员还可以根据工作的内容，分为负责编写人机界面的界面程序员（interfaceprogrammers）、负责网络数据交换及优化的网络程序员（networkandmultiplayerprogrammers）、负责实现游戏人工智能的人工智能程序员（AIprogrammers）、负责将音乐音效添加到游戏中的音乐音效程序员（audioprogrammers）以及负责测试和保障游戏软件质量的测试程序员(QAprogrammers)等。
当然，并不是所有的游戏公司都会如此细致地对程序人员进行职能划分，正如前文所说的那样，行业的不成熟性让游戏公司在对岗位职能的描述过程中，充满了灵活性和模糊性，因为对国内现阶段的游戏研发来说，重要的是能否做出产品，而不是如何去进行细致的分工。
不过随着行业的不断成熟以及行业规范的持续建议，相信一个更完善的程序人员工作职能划分体系，会很快出现在所有从业者的面前，因为行业规范的过程，就是岗位职能明确的过程。
我刚开始做Web开发的时候，根本没有前端，后端之说。
原因很简单，那个时候服务器端的代码就是一切： 接受浏览器的请求，实现业务逻辑，访问数据库，用JSP生成HTML，然后发送给浏览器。
即使后来Javascript在浏览器中添加了一些AJAX的效果，那也是锦上添花，绝对不敢造次。因为页面的HTML主要还是用所谓“ 套模板 ”的方式生成：美工生成HTML模板，程序员用JSP,Veloctiy,FreeMaker等技术把动态的内容添加上去，仅此而已。
那个时候最流行的图是这个样子：
在最初的J2EE体系中，这个 表示层 可不仅仅是浏览器中运行的页面，还包括Java写的桌面端，只是Java在桌面端太不争气， 没有发展起来。
每个程序员都是所谓 “全栈”工程师 ，不仅要搞定HTML, JavaScript, CSS，还要实现业务逻辑，编写访问数据库的代码。等到部署的时候，就把所有的代码打成一个WAR包，往Tomcat指定的目录一扔，测试一下没问题，收工回家！
不差钱的公司会把程序部署到Weblogic，Websphere这样的应用服务器中，还会用上高大上的EJB。
虽然看起来生活“简单”又“惬意”，但实际上也需要实现那些多变的、不讲逻辑的业务需求，苦逼的本质并没有改变。
随着大家对浏览器页面的 视觉和交互 要求越来越高，“套模板”的方式渐渐无法满足要求，这个所谓的表示层慢慢地迁移到浏览器当中去了，一大批像Angular, ReactJS之类的框架崛起，前后端分离了！
后端的工程师只负责提供接口和数据，专注于业务逻辑的实现，前端取到数据后在浏览器中展示，各司其职。
像Java这样的语言很适合去实现复杂的业务逻辑，尤其是一些MIS系统，行业软件如税务、电力、烟草、金融，通信等等。 所以剥离表示层，只做后端挺合适的。
但是如果仅仅是实现业务逻辑，那后端也不会需要这么多技术了，搞定SSH/SSM就行了。
互联网，尤其是移动互联网开始兴起以后，海量的用户呼啸而来，一个单机部署的小小War包肯定是撑不住了，必须得做分布式。
原来的单个Tomcat得变成Tomcat的 集群 ，前边弄个Web服务器做请求的 负载均衡， 不仅如此，还得考虑状态问题，session的一致性。
（注：参见文章《小白科普：分布式和集群》）
业务越来越复杂，我们不得不把某些业务放到一个机器（或集群）上，把另外一部分业务放到另外一个机器（或集群）上，虽然系统的计算能力，处理能力大大增强，但是这些系统之间的通信就变成了头疼的问题， 消息队列 （MQ)， RPC框架 （如Dubbo）应运而生，为了提高通信效率，各种 序列化的工具 (如Protobuf)也争先空后地问世。
单个数据库也撑不住了，那就做数据库的 读写分离 ，如果还不行，就做 分库和分表 ，把原有的数据库垂直地切一切，或者水平地切一切， 但不管怎么切，都会让应用程序的访问非常麻烦，因为数据要跨库做Join/排序，还需要事务，为了解决这个问题，又有各种各样“ 数据访问中间件 ”的工具和产品诞生。
为了最大程度地提高性能，缓存肯定少不了，可以在本机做缓存(如Ehcache)，也可以做 分布式缓存 (如Redis)，如何搞 数据分片 ，数据迁移，失效转移，这又是一个超级大的主题了。
互联网用户喜欢上传图片和文件，还得搞一个 分布式的文件系统 （如FastDFS），要求高可用，高可靠。
数据量大了，搜索的需求就自然而然地浮出水面，你得弄一个支持全文索引的 搜索引擎 (如Elasticsearch ,Solr)出来。
林子大了，什么鸟都有，必须得考虑 安全 ，数据的加密/解密，签名、证书，防止SQL注入，XSS/CSRF等各种攻击。
前面提到了这么多的系统，还都是分布式的，每次上线，运维的同学说：把这么多系统协调好，把老子都累死了。
得把持续集成做好，能自动化地部署，自动化测试（其实前端也是如此），后来出现了一个革命化的技术 docker ， 能够让开发、测试、生成环境保持一致，系统原来只是在环境（如Ngnix, JVM,Tomcat,MySQL等）上部署代码，现在把代码和环境一并打包， 运维的工作一下子就简化了。
公司自己购买服务器比较贵，维护也很麻烦，又难于d性地增长，那就搞点虚拟的服务器吧，硬盘、内存都可以动态扩展（反正是虚拟的）， 访问量大的时候多用点，没啥访问量了就释放一点，按需分配，很方便，这就是 云计算 的一个场景。
随着时间的推移，各个公司和系统收集的数据越来越多，都堆成一座大山了，难道就放在那里白白地浪费硬盘空间吗？
有人就惊奇地发现，咦，我们利用这些数据搞点事情啊， 比如把数据好好分析一下，预测一下这个用户的购买/阅读/浏览习惯，给他推荐一点东西嘛。
可是这么多数据，用传统的方式计算好几天甚至好几个月才能出个结果，到时候黄花菜都凉了，所以也得利用分布式的技术，想办法把计算分到各个计算机去，然后再把计算结果收回来， 时势造英雄， Hadoop 及其生态系统就应运而生了。
之前听说过一个大前端的概念，把移动端和网页端都归结为“前端”，我这里造个词“大后端”，把那些用户直接接触不到的、发生在服务器端的都归结进来。
现在无论是前端还是后端，技术领域多如牛毛，都严重地细分了，所以 我认为真正的全栈工程师根本不存在，因为一个人精力有限，不可能搞定这么多技术领域，太难了 。
培训机构所说的“全栈”，我认为就是前后端还在拉拉扯扯，藕断丝连，没有彻底分离的时候的“全栈”工程师。
那么问题来了， 后端这么多东西，我该怎么学？
之前写过一篇文章叫做《上天还是入地》，说了学习的广度和深度，在这里也是相通的。
往深度挖掘，可以成为某个技术领域的专家，如搜索方面的专家、安全方面的专家，分布式文件的专家等等，不管是哪个领域，重点都不是学会使用某个工具和框架， 而是保证你可以自己的知识和技术去搞定这个领域的顶尖问题。
往广度发展，各个技术领域都要了解，对于某种需求，能够选取合适的软件和技术架构来实现它，把需求转化成合适的技术组件，让这些组件以合适的方式连接、部署、运行，这也需要持续地学习和不断的经验积累。
最后，以一张漫画来结束吧！
C/C++高级工程师学习路线图：
欢迎分享，转载请注明来源：内存溢出
微信扫一扫
支付宝扫一扫
评论列表（0条）