1. 做好事务记录
2. 快速反馈
3. 快速开发(RAD)
4. 选择专业化方向
5. 靠数据决策
6. 掌握一些套路
一. 做好事务记录
方式:装个有道笔记,或者印象笔记,或者简单点,搞个本地的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来实现?
掌握一些套路吧,套路多了,行走江湖就不怕了。