每个优秀程序员必须具备的技术技能_程序员需要具备哪些技能
一、做好事务记录
方式：装个有道笔记，或者印象笔记，或者简单点，搞个本地的txt文件都可以。
1)、记录好TodoList，避免遗忘。
经常遇到这种情况：针对正在开发中的功能，策划口头跟你提了一些要求，过了几天来问你，‘做完了没有？’，‘哎呀忘记了’，版本计划延误。
2)、记录好每天做了哪些事，周末进行review，再制定下周计划。
一方面督促自己完成周计划；另一方面对自己一周的生产力有个大概的掌握。
3)、有什么思维闪光点，马上记录下来。
整一个专门记录奇思妙想、头脑风暴点子的文档。
二、快速反馈
这应该成为开发人员的基本素养。
现象：在项目组群里，经常遇到QA喊：‘服务器初始化失败，帮忙看一下’、‘客户端崩溃，谁帮忙看一下’、‘xx功能不正常，谁帮忙看一下’，然后，过了许久都没人回应，如果是小问题，最后可能不了了之。
心理学家早就知道，人在群体情况下，会有两种现象：责任缺失、冒进。上述例子就属于‘责任缺失’的情况，要求一个群体负责，最终可能无人负责。
我的解决方法，分三步走：
1)、开发人员看到自己相关的问题，快速认领，在群里打1。
哪怕你知道了、已经在处理了，也要给予反馈，程序员往往懒的回复，这是不合适的。
这样做有两个好处：
告诉大家已经有人接手处理了，其他人不需要重复处理。
形成一种团队形象，给外界的印象是，这个团队响应是很快的，处理问题是靠谱的。
2)、3分钟内无人认领，QA按照事先定好的顺序表，找到对应的开发人员处理。
要做到‘责任落实到人’，持续跟踪处理情况。
3)、如果问题处理好了，再回复一条：‘xx已处理’。
让直属上级和其他团队成员都知道，问题已经处理好了，不需要再跟踪了，忘记它吧。
如果没法处理，需要外部帮助，也要给予及时沟通和反馈。
三、快速开发
大部分开发人员都是‘业务开发人员’，属于‘开发组’、而非‘研发组’，首要任务就是‘业务开发’，那么生产效率就是一件很重要的事。
1)、开发各种工具和编辑器
以此提高整个项目组的生产效率，不光是程序的
比如Excel导出工具、技能编辑器、任务编辑器、过场动画编辑器等；有了编辑器，原本非得程序员完成的工作，可以交个策划美术了。
2)、利用脚本（推荐Python）完成日常机械化的操作
比如打包发布脚本（如果谁还在纯手工做版本，我也是醉了，我们10多年前有个项目就是这样的）
3)、利用脚本进行自动化测试
比如机器人压力测试，日常回归测试等。
能够减轻测试人员压力，提升幸福指数。
4)、利用好各种工具
作为一名侠客，在江湖上混，怎能没有一件称手的兵器？
如果你是做UI的，那么TexturePacker是一个很好的东西。
如果你用vs开发，那么应该要看一看《快速编码 高效使用Microsoft Visual Studio》
如果你的工作跟图形引擎有关，那么应该掌握PIX、Intel GPA、GPUView
如果你经常烦恼在硬盘上找文件，那么推荐安装Everything
如果你为编译大型C 项目而烦恼，一定要安装Incredibuild
如果你想知道进程访问了哪些文件，Procmon是个好帮手
四、选择专业化方向
如同我们进了大学，要选择专业一样。
现实情况是：
绝大部分程序员没有专业性；绝大部分程序员是以语言划分专业的。我是做C 的，你是做java的。。。
这就会产生一个问题，年纪大了，性价比较低，竞争不过小年轻；要价高，精力差，你能做的应届毕业生也能做，你有什么优势？如果35岁之前不转管理岗位，或者手下没有一支亲信部队，很容易找不着好工作；工作是肯定能找到的，但你不太可能成为核心成员。我们经常收到一些40~44岁左右的人的简历，一看到这样的简历，我们第一感觉总是：这人还能不能加班？跟我们之间会不会有代沟？面试官产生这样的疑问很正常，等你到了这样的年纪，你是否也会面临这种尴尬？
为什么会这样？作为一名技术人员，最常见的原因就是：没有专业性。通俗的讲，‘没有哪方面做的特别好，各方面都很平庸，遇到难题解决不了’。你可能确实有一些经验，但是这些经验写下来估计还不到两页纸；这些‘经验’很简单，没什么技术壁垒，新人很快就能掌握甚至超越你。
解决方法是：
选择若干方向，钻研下去，要有深度，让别人不能轻易替代你。由于人的精力是有限的，你不可能什么都会，至少选择一个方向吧，哪怕偏门的也可以。这个过程确实很痛苦，没办法，竞争太激烈了。
五. 靠数据决策
现实情况是：
经常面临这样一些问题：
平台反应创角转化率偏低，是什么原因？
导量阶段，玩家反映服务器延迟很高，快点看下。
客户端今天怎么这么卡？
为什么这个月收入跌了这么多？
我们找不到是什么原因，或者回答不出比较准确的数字，往往是“我不知道”、“我觉得大概是这样”、“可能是这里有问题”，无法定位问题，也无法决策。
为什么我们经常束手无策，一脸懵逼？因为我们缺乏数据。有了数据，小学生都能决策。
解决方法是：
建立数据反馈、收集、统计的机制。
我觉得，应该主要掌握两种数据：
1)、用于统计分析的数据，便于下一步决策。
2)、系统实时运行的数据，便于定位和解决问题。
想想：
游戏项目上线前夕，为啥要做后台？
大型电商搞活动期间，如何掌握系统运行情况？
交通部门如果对全市道路没有任何监控措施，会面临什么样的窘境？
飞机上没有任何仪表，飞行员如何了解飞机飞行状况？
军舰上没有雷达，会变成什么样？
六、掌握一些套路
现实情况是：
1、面对复杂的系统，往往不知所措，不知道如何切入。
2、或者面对一些新技术，学起来很费劲，不能快速掌握。
拿起一本书，从头看到尾，低头死命的啃，啃完也就这样，脑子里一团浆糊，知识点难以形成体系。
解决方法是：
对于第一类问题，其实很多系统、或者功能模块，都有‘常见的组成架构’，并且都有‘常用的分析方法’，
通俗的讲，都有一些套路在里面；掌握这些套路，分析起来就容易了，你会觉得豁然开朗。
比如客户端帧数低的问题，通常就从3个方面去考察：CPU、GPU、总线带宽。
比如客户端防Hack的问题，也有一些常用的打法：加壳、通信协议加密、花指令、内存混淆、关键数据放到服务器验证、不定期更换通信协议等。
比如客户端渲染效果该如何分级，得先知道有哪些渲染步骤：折射反射、场景、角色、UI、后期。场景里面又有哪些组成部分：天空盒、地形、植被、水、场景物件。掌握了这些，才能决定哪些效果开、哪些效果关、哪些效果降低品质。
怎么搭建一个游戏客户端：App框架完成以后，先搞定核心战斗框架、再合入UI库、主界面、主角属性界面、聊天好友公会组队、包裹商店拍卖行。。。
对于第二类问题，掌握这门技术的构成、框架，掌握起来就容易了
比如侯杰先生写的《STL源码分析》中，把STL分为六大组件：容器、迭代器、Allocator、算法、仿函数、配接器。
按这个思路再去学习STL就更清晰了，而不是一直搞不懂，为什么容器参数里还要带个Allocator参数？stack怎么会用dqueue来实现？
掌握一些套路吧，套路多了，行走江湖就不怕了。
若资源对你有帮助，浏览后有很大收获，不妨小额打赏我一下，你的鼓励是维持我不断写博客最大动力。
想获取DD博客最新资讯，你可以扫描下方的二维码，关注DD博客微信公众号（ddblogs）。
或者你也可以关注我的新浪微博，了解DD博客的最新动态：DD博客官方微博（dwtedx的微博）。
如对资源有任何疑问或觉得仍然有很大的改善空间，可以对该博文进行评论，希望不吝赐教。
为保证及时回复，可以使用博客留言板给我留言: DD博客留言板（dwtedx的留言板）。
感谢你的访问，祝你生活愉快，工作顺心，欢迎常来逛逛。