每个优秀程序员必须具备的技术技能_程序员需要具备哪些技能
2018-07-10 13:53:56  By: dwtedx

一、做好事务记录

方式:装个有道笔记,或者印象笔记,或者简单点,搞个本地的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的留言板)

感谢你的访问,祝你生活愉快,工作顺心,欢迎常来逛逛。


快速评论


博文评论

  • 该博文还没有评论、赶快抢沙发吧...
DD记账
top
+