再起航三转行互联网

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

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

为什么转行

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

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

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

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

1. 做游戏太苦逼，天天加班
2. 岁月不饶人，年龄大了，黑夜已经无法给我灵感，加不动班了
3. 加班就算了，关键是不出成绩，做出的产品都是失败，心凉了
4. 业务就那些，就是换皮，厌倦了重复劳动
5. 大家都在聊一些新型的业务，如秒杀，团购，想去看看怎么实现的
6. 对现在技术已经没有兴趣，想看看学学外面的技术
7. 完全是零成长，我需要成长
8. 行业工资太低了，去风投偏好强的行业

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

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

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

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

1. 为什么要转互联网？ 目的性有多强，千万别是为了去互联网而去互联网
2. 真要去互联网，是否需要重新打理下自己的技术栈
3. 决心去，那是否看看互联网的技术点，不然就是拿现有的经验去面试跨行业
4. 大公司就是逻辑集群 + 存储集群，分布式基础上的算法+存储；逃不掉的
5. 纠结的一点，大公司人多，部门多，所以你被动接受的知识点并不多
6. 当然就算将来再回来做游戏，也没什么后悔的，你的眼界会更开拓

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

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

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

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

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

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

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

程序员分类

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

互联网真的很好？

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

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

1. 开发的灵感在晚上，所以都是晚上提测，天天晚上坐等开发
2. 白天没事，下班就事多
3. 开发修一个bug，赠送两bug
4. 上线时间固定了，开发延期，挤压测试时间
5. 线上出问题了，测试没覆盖到位

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

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

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

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

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

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

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

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

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

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

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

1. 需求目的
2. 系统流程图
3. 涉及到的接口，新增还是修改
4. 涉及到配置变更，db变更
5. 上线过程中是否需要兼容，方案是什么
6. 是否需要降级开关
7. 回滚方案，灰度方案
8. 如果是核心接口，是否需要压测
9. 上线后，是否需要给客服报备，以防出现大量客诉

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

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

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

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

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

游戏改造

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

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

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

1. 互联网都是7*24提供服务的，不可能停机维护，那么一个服务至少需要两台服务器，保证服务的高可用；版本也有了灰度的可能 游戏怎么改造呢？《游戏灰度发布》是个思路
2. 游戏中为了高响应，都尽量少IO操作，比如定时存储db，那如果服务器挂了，数据肯定会丢失，怎么办？ 互联网常用思路是多级缓存，主从存储，拒绝单点，通过存储集群分压
3. 主从是最小一种分布式架构，分布式的基本理论可以了解一下，比如这篇《zookeeper-paxos》，那你可以看出主从的问题
4. 游戏中有些组件也是有的，比如策划文件的热加载，只是做的太粗糙，不够精细，怎么才算好呢？《常识五配置中心》
5. 再有测试，开发提交代码，测试打包，构建，冒烟，回归，一套流程，《常识三持续集成、持续交付、持续部署》
6. 游戏中不管是策划功能，还是开发优化，都是靠感觉，量化工具几乎没有，怎么以数据说话？
7. 那就是统计，监控，告警，《微服务-监控》，不然都得等到玩家投诉，反馈，改进周期就长了，无法快速响应
8. 现在都使用社交帐户，如微信，QQ登陆，这样降低新客成本，游戏中也对接过第三方平台，那背后的理论知识是什么？《常识二Oauth2.0介绍及安全防范》
9. 游戏中安全性，考虑的还是比较少的，毕竟我们是内容提供商，不是平台的，但互联网是不同的，都得有自己的用户。那用户数据安全性如何保证？《常识一用户密码存储策略》
10. 互联网三大利剑，缓存、降级、限流；游戏中很少。《常识四堆外内存》，《微服务-熔断机制》

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

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

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

麻省虽小，但五脏得俱全！

南墙

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

1. 保持心态，不卑不亢
2. 认清现实，就是没有行业经验，面试不浮夸，不懂就是不懂；小公司要干活经验，反而大公司可能接受你
3. 经验少，但基础扎实。肯定离不开java语言环境。那么lang,util,io,net这些基本常用的包，对应着多线程，集合，并发包，nio，网络通信是否深入
4. 深一点，jvm,jmm,gc,lock,classloader
5. spring,netty,ibatis,zk,rpc,redis常用开源框架，至少你常使用的是否深入
6. 互联网不了解，游戏了解啊，对现有项目业务的理解，逻辑的完备性，是否都能阐述清楚