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

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

为什么转行

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

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

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

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

做游戏太苦逼，天天加班

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

面试官或者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常用开源框架，至少你常使用的是否深入

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