再起航三转行互联网

再起航系列,一枚互联网菜鸟的成长历程

好几个同事来问转行去互联网,需要注意哪些,准备些什么?有哪些不一样!回答的很零碎。借此契机我来回顾一下转行的过程,以及来一年的感受,记录一下

为什么转行

这是首要问题,需要不断地问自己!可以罗列一下自己的所有理由,再慢慢砍出不重要,不关键的选项,看看那最核心的一两条。

这是你前进的动力,因为你当前的状态还没有到没饭吃的境地!人要跨出自己的舒适区是需要勇气和决心的,阻力没有想象中的那么小,当然也没有想象中的那么大

如果不坚决,就会一拖再拖,自己会找借口;诸如:还没有准备好、想再梳理梳理现有知识体系...;当你踏出第一步,出去面试了,被打击是在所难免的,你会更加会失望,自我怀疑,自卑,得过且过吧

我来稍稍罗列一些可能也是你的选项:

做游戏太苦逼,天天加班

岁月不饶人,年龄大了,黑夜已经无法给我灵感,加不动班了

加班就算了,关键是不出成绩,做出的产品都是失败,心凉了

业务就那些,就是换皮,厌倦了重复劳动

大家都在聊一些新型的业务,如秒杀,团购,想去看看怎么实现的

对现在技术已经没有兴趣,想看看学学外面的技术

完全是零成长,我需要成长

行业工资太低了,去风投偏好强的行业

当然你可能还有别的选项,其实这些问题概括起来就是:职业规划,各个阶段的职场与生活的平衡

当然我也知道,你可能对技术的学习看得很重,技术人嘛,就喜欢技术,技术万岁

当时我也请教了一些在互联网的朋友,甚至在面试时向面试官提出一些转行难点,以及职业规划问题

朋友的一些忠告犹在耳边,对你可能也有用:

为什么要转互联网?目的性有多强,千万别是为了去互联网而去互联网

真要去互联网,是否需要重新打理下自己的技术栈

决心去,那是否看看互联网的技术点,不然就是拿现有的经验去面试跨行业

大公司就是逻辑集群+存储集群,分布式基础上的算法+存储;逃不掉的

纠结的一点,大公司人多,部门多,所以你被动接受的知识点并不多

当然就算将来再回来做游戏,也没什么后悔的,你的眼界会更开拓

面试官或者HR都会问的一个问题

为什么要放弃自己积累多年的经验,到一个新行业重新开始?

希望这个问题的答案,你心里很清楚

其中有个面试官,问了很多的游戏构架,最后说他有个下属,之前也是做游戏,但做了一年又回去做游戏,说不适合;所以面试官心里对跨行业尤其这么对口的跨行业很有防备心理,你如何说服他,当然说服面试是外在,内在是说服自己

后面的过程就是游戏公司很多面试机会,但压根不去,中途架不住猎头诱惑,或者说是自己内心动摇,跑一家游戏公司面试,一面即中,好职位,好薪水,超过现在薪资很多很多,可惜当时脑袋被驴踢了,想起现在每个月的损失,就心痛;互联网公司面试寥寥无几,有机会也是面试一团糟

所以这中间的过程,一面诱惑,一面绝望,想起来都是泪!

最后欣慰的是,有两家互联网公司给了机会,并且其中一家公司大度地接受了我!

程序员分类

这儿讲的分类,不是江湖传说的程序员鄙视链;技术人员总是偏爱技术,唯技术论,但其实技术最后还是服务于业务。所以不要有“研究过Linux内核源码牛”,“贡献了开源项目代码的才牛”的错误思维。一个小电商平台的程序员与一个淘宝的程序员,谁牛点,你选谁?谁牛不一定!但淘宝的业务量级,复杂度肯定高得多得多,遇到的场景也多得多。当你还在处在理论化试验阶段时,别人已经踩过N个坑,并进行了更新迭代完善,甚至已经更换了N个方案并从实践中证实了可行性。所以讲技术要能解决具体问题才有价值,问题的复杂度决定技术实力的高度!

回到正题,分类,也是程序员的发展方向:产品型程序员和技术型程序员

从名字,就知道他们的区别,而且也明了,国内大多数公司都是产品型程序员,很少有技术型程序员

现实与理想的差距总是超出想象,哪个程序员不想当一名技术型程序员呢

当初进入游戏行业时,发现游戏中并发是相当多的,寻找一个并发模型是相当重要及关键的。所以当时就想把自己定位在并发领域,辛勤耕作,有一片天地。

然而现实是残酷的,游戏程序开发是面向产品型的,尤其是需要快速生产,公司也是来赚快钱的,视员工为人手,而非人才累积,没有一块适合累积的土壤。

各个公司都有一套现成的框架,你只要了解,能够清楚数据流的处理过程,那剩下的时间就是堆逻辑,堆功能。堆完了之后,项目换个名字,再来堆一遍。这就是现状,你讨厌的现状!无奈而又不得不随波逐流。

换个角度,就算你有了改造现有框架的机会,不是修改个小bug,简单的优化,你有多少底蕴改造它。不谈你离一名技术型程序员有多远,没有机会经历过大流量游戏的打磨过程,做个优秀的产品型程序员都远远不够

上个月,抽空认真看了下我司亿万级网关项目的源码,就一个限流算法类,一百多行,真心理解了一个月,有种大学时期学习数据结构与算法时的感叹,我TM不适合这个行业,智商真心不够

当然你不是我,但我想说的是,要确定好自己的定位,现在是个产品型程序员,到了大公司,你的计算机底子能不能让你站到技术型程序员的队列中,如果不能,那么你还只能是产品型,还是堆逻辑,如果在核心业务,还能学习到业务知识,如果不是核心业务,可能就是CRUD,不停的CRUD,没有行业积累,你是否甘心,现在你至少整个游戏开发还是了解的,但在大公司,人人都是螺丝钉,你就被钉在那块地方。

这个时候再重新考虑你的规划,是不是又要走回头路了呢?所以得想想如何能转成功,更要想想转成功之后怎么走

当然,不能因为现实的残酷,就放弃理想,还是要努力去当一名技术型程序员,术业有专攻

大公司的技术型程序员是相当多的,比如架构部,分得细些,业务架构和基础架构

业务架构是产品型程序员的好去处,轮流过各个岗位,经历过各种复杂业务,踩过无数坑后,知道在每个阶段的坑在哪儿,有多深,在后面架构方案选型时,就可以扬长避短

当然这是个整体架构,你可以专研某几个业务的架构

基础架构就是技术人心里的梦想,分离业务,专研技术,在一个点上发力,比如对高并发感兴趣,深入研究,像DougLea大师一样,写出concurrent一样的并发包;还有各种各样的中间件,现在云技术很热,专攻集群编排...成为不可多得的业界大牛,管它风吹树欲摇,我自清风自妖娆!

互联网真的很好?

天下乌鸦一般黑,所以得做好坏的准备;相对现在火热的区块链、AI,互联网已是昨日黄花了,各大公司都已经是饱和状态

前几天跟一个中小型互联网公司的测试负责人聊天,他是一肚子苦水啊。

开发的灵感在晚上,所以都是晚上提测,天天晚上坐等开发

白天没事,下班就事多

开发修一个bug,赠送两bug

上线时间固定了,开发延期,挤压测试时间

线上出问题了,测试没覆盖到位

听了是不是很熟悉,跟游戏公司有什么区别

所以这是你选择公司时得有一个考量,我运气好,莫名进了一家top3的电商公司,基础设施都已经建设完成,又是一个核心业务组,一切资源更是很完备,开发业务就很流畅,可以挤出很多时间去思考,学习。

当然如果是一家业务在剧增的公司,我觉得会有更多的收获。去哪里都得选择人流大的。就像游戏,如果款款成功,流量大,流水高,谁想跳呢

如果是一家小公司,那可能你又得是个全能型选手,从前端到后端,都是你,业务功能都来不及做,哪来时间思考,但这会给你一种在进步的假象,毕竟你的术是提高了,但道呢?

有次面试,还是家不小的公司,开发人员也快过千了,面试到索引知识,游戏开发中索引用得不多的,所以结果可想而知,但面试官说了一句“怕我把线上库给拖挂了”,他的担忧不无道理,但不得不思考一下这家公司,dba角色呢?codereview呢?线上监控预警呢?一个整体机制的完善度可以包容个体的脆弱性

所以还是尽量去些完备性高的公司,至少让你亲眼看看那幅蓝图到底是什么样!你需要认知的不就是这些吗?

当然流程完备性高的公司,他的开发流程需要你去适应

以前拿到需求,一个字,干!当然游戏业务逻辑简单些,业务与业务之间的交互性弱些;如果是换皮项目,看不懂以前的代码,可以直接重新来过。总之就是要写得爽

游戏公司时,我们推行过,在拿到策划文档后,自己梳理一下,写个分析文档,画个流程图;但最后总是不能贯彻,时间紧是一方面,程序员内心反感写文档是另一方面,showmethecode才是最重要的

但,其实那真的不是一个程序员只干的事;就像看开源项目一样,很多人上来就是直接撸代码,其实精髓都在文档中,他的思想,结构,实现策略;这些都了解之后,其实你自己都应该有能力实现一套,至少心里已经有了大体实现框架,再通过阅读源码去印证他的策略,实现手法,有没有比你想的巧妙

我们现在的做法,需求来了,需要花费一天左右的时间去写详细设计

需求目的

系统流程图

涉及到的接口,新增还是修改

涉及到配置变更,db变更

上线过程中是否需要兼容,方案是什么

是否需要降级开关

回滚方案,灰度方案

如果是核心接口,是否需要压测

上线后,是否需要给客服报备,以防出现大量客诉

可能还有别的,但你看看,这些里面写代码只占了多少比例;我现在还不是订单那样的核心业务,订单上一次线,考虑的还要多,上线过程更复杂。现在都是微服务了,一个功能涉及到很多服务

如果业务复杂度很高,还需要需求多次评审,架构评审,安全评审;当然有时其实代码层面只需要修改一两行而已,但真的不仅仅是修改代码。

过去只写代码,甚至单元测试用例都没有,离专业二字,真的差很多,可以看看之前的《thecleancoder读书笔记》

这也是相对过去游戏开发的不同点,游戏还停机维护,但互联网不行,必须时时online,上线过程必然考虑各个兼容

还有一些别的软技能方面:如沟通,公司文化,是否与你匹配

游戏改造

游戏算不算互联网行业?这个问题有点蒙。反正互联网行业的可能不承认。

如何更快的转行,可以拿游戏来升级一下,改造成一个互联网项目,这样更形象些

其实这也是游戏架构中的一些缺陷,有些是产品接受的,有些是行业传承的,所以身在其中都觉得理所当然了

互联网都是7*24提供服务的,不可能停机维护,那么一个服务至少需要两台服务器,保证服务的高可用;版本也有了灰度的可能游戏怎么改造呢?《游戏灰度发布》是个思路

游戏中为了高响应,都尽量少IO操作,比如定时存储db,那如果服务器挂了,数据肯定会丢失,怎么办?互联网常用思路是多级缓存,主从存储,拒绝单点,通过存储集群分压

主从是最小一种分布式架构,分布式的基本理论可以了解一下,比如这篇《zookeeper-paxos》,那你可以看出主从的问题

游戏中有些组件也是有的,比如策划文件的热加载,只是做的太粗糙,不够精细,怎么才算好呢?《常识五配置中心》

再有测试,开发提交代码,测试打包,构建,冒烟,回归,一套流程,《常识三持续集成、持续交付、持续部署》

游戏中不管是策划功能,还是开发优化,都是靠感觉,量化工具几乎没有,怎么以数据说话?

那就是统计,监控,告警,《微服务-监控》,不然都得等到玩家投诉,反馈,改进周期就长了,无法快速响应

现在都使用社交帐户,如微信,QQ登陆,这样降低新客成本,游戏中也对接过第三方平台,那背后的理论知识是什么?《常识二Oauth2.0介绍及安全防范》

游戏中安全性,考虑的还是比较少的,毕竟我们是内容提供商,不是平台的,但互联网是不同的,都得有自己的用户。那用户数据安全性如何保证?《常识一用户密码存储策略》

互联网三大利剑,缓存、降级、限流;游戏中很少。《常识四堆外内存》,《微服务-熔断机制》

还有很多,记得以前游戏有次充值服务器启不起来,一启就挂。最后说是机房网络出了问题。但开发查了一个通宵的代码,这是多么的狭隘,出了问题,整个链路都可能有问题,不能只盯着代码,这是个系统工程

如果一个服务出现波动,开发,dba,运维,网络,机房,底层框架都是排查范围内

其实上面说的这些,初创公司真是没有那么精力去完善,但我们还是需要一个完整的体系,知道需要这些系统支撑。

麻省虽小,但五脏得俱全!

南墙

未来属于勇敢而有智慧的骑士,出去撞撞又如何,年青就是资本

保持心态,不卑不亢

认清现实,就是没有行业经验,面试不浮夸,不懂就是不懂;小公司要干活经验,反而大公司可能接受你

经验少,但基础扎实。肯定离不开java语言环境。那么lang,util,io,net这些基本常用的包,对应着多线程,集合,并发包,nio,网络通信是否深入

深一点,jvm,jmm,gc,lock,classloader

spring,netty,ibatis,zk,rpc,redis常用开源框架,至少你常使用的是否深入

互联网不了解,游戏了解啊,对现有项目业务的理解,逻辑的完备性,是否都能阐述清楚

发表评论
留言与评论(共有 0 条评论)
   
验证码:

相关文章

推荐文章

'); })();