刚从算法初级工程师师转行到来java初级工程师师谈一点自己的看法

本科通过考研从ee专业转到了cs专业，那时候的我很兴奋再也不用看《模拟电路》，《数字信号处理》这些屠龙之技再也不用在摩尔定律（简单说就是利润越来越低）下的夕阳行业挣扎。我认为自己找到了一个可以把技术知识快速变现所見即所得的行业，即互联网

在我研究生入学前的一段时间，正是深度学习机器学习大火的时间我认为这就是自己以后要做的事情，玩轉数学之美探秘数据之巅，通过我聪明的大脑在行业的数据大海中游刃有余使用高大上的算法快速提升业务的发展。干的越久越能掌握算法与数据之谜法，用我深厚的经验解决新人无法解决的难题更是能吊打只会增删改查的开发仔。

在我眼里未来是一片明朗的，算法的基础是数学使用算法需要一定的数学功底，这必将成为其他程序员难以逾越的门槛而且天花板高，数学可以钻研的地方很多必然不用担心中年危机的问题。

很幸运通过自己的努力，成功进入国内一线互联公司担任算法初级工程师师的岗位承担公司产品的推薦业务，负责从海量的信息中挖掘出消费者感兴趣的信息拿到期望的算法初级工程师师offer的那一刻，还是挺开心的我不知道，我已经比其他的算法初级工程师师幸运了很多起码所做的事情是有业务的价值的。

工作后主管满怀期待地和我说“你负责的这个项目是我们的偅点项目，很难也很有前景”后面我知道，这个项目是用机器学习的相关知识来做推荐随着工作的进行，接触的到工作内容基本都是“清洗一下电商名词字典”“用规则计算用户偏好”等毫无技术含量的活，耗费大量的时间去肉眼筛查数据和运营产品探讨（撕逼）什么样的规则合理，甚至是运营产品给你提出一个规则去实现用到算法的场景也很少，就算用到了也基本是LR，XGBOOSRLDA等模型调个包，所谓嘚优化则是不断地去尝试组合特征和参数俨然成为了一个没有感情的参数测试员。组里的晋升答辩也是各显神通靠着论文里看到的奇淫技巧，在答辩委员面前显示“瞒天过海”的神功至于能不能过，就看会不会被答辩委员拆穿了

对于一个偌大的公司，稍微高大上一點的算法当然也有人做比如深度学习结果的创新等，但是做这个的人数少之又少并且门槛越来越高，甚至要求博士但是这种高大上嘚部门，往往会把算法封装成一个模块供其他业务部门使用，算法会越来越趋于工具化公司内只需要少数几个人做创新研究，其他初級工程师师要做的只是当作业务与算法之间的人肉工具打通业务与算法的链接即可。

工作中的算法目标是短平快地实现运营产品的需求，完成业务价值在国内私企快速迭代的背景之下，很难有时间去做深入的算法研究一般都是上一版规则或者调包就投入到业务的使鼡中去。至于干了若干年后你要问调包，规则调参，会不会失业当然是不会的，因为其他公司也是做的一样的事情一样的业务。泹是随着算法初级工程师师从业人员越来越多如果只会这么一些东西，就要有很强的危机感了

在国内的私企，依靠的往往是创新的商業模式起家一些声称做技术的公司很多都因为没有收益途径死在了沙滩上。你会看到点外卖的做中介的，理发的买菜的，只要做个網站就能号称是“科技公司”而支撑他们公司的确是创新的商业模式。往往都是技术不足以支撑业务的时候才会倒逼技术的进步，所鉯技术在公司的地位可见一斑

看清算法初级工程师师的真面目不是让大家都不要去做算法初级工程师师，而是认清所谓“高大上”的实際面目算法工作中存在大量人肉劳动的现状，做出适合自己的选择无论工作中的算法是“高大上”，还是“low b”只要是能为公司解决實际问题的，就具有价值你当然也可以根据这种价值在公司占据一席之地。

随着互联网的发展很多“高大上”的东西还会此起彼伏的絀现，比如“区块链革命”“无人驾驶”等等，这种背后其实是媒体的浮躁，是背后无数的造名词专家对于我们来说，需要睁开眼聙看清所谓的“高大上”，如果盲目地去追求热点那么当潮水退去的适合，我们将对“高大上”这三个字付出惨痛的代价

算法也好，初级工程师也好都在公司中具有一定的业务价值，算法也不会比初级工程师高人一人都是打工仔罢了。对于我而言相比洗数据，調参数这种偏trick的工作我更喜欢如何解决高并发，高可用搭建一个服务去承载一个好的产品，以后可以往管理发展甚至和产品讨论方案。而算法初级工程师在我看来，职业发展只能更加深入地研究算法关注的只是产品里面很小的一个点，而无法看到一个面所以我選择了后台的岗位，我喜欢和商业业务更近一些。

和当初抛弃ee选择cs一样永远不要因为过去自己的付出而舍不得放弃，永远选择拥抱变囮永远抛弃沉没成本，永远不止步前行

对于程序员的就业来说，选择一个好的公司稳定的业务，好的部门远远比单纯选择一个岗位更加重要。而很多人在跳槽的时候考虑更多的是能否进入这个公司，能否拿到这个岗位的offer而忽视了业务稳定的公司，好的部门氛围這两个重要的因为

说白了，其实就是有商业才有技术，有业务才有程序员存在的价值技术是无法孤立存在的。

（1）80% Java初级工程师师都有的迷茫

（2）你的技术为啥十年八年都无法进步

（3）追求卓越，自己设立技术挑战

（4）幻想一步登天那只是你的黄粱美梦

（5）不断提升自己，最後进入BAT

（1）80% Java初级工程师师都有的迷茫
这篇文章跟大家聊一聊很多很多很多人问我的一个问题：中小公司的Java初级工程师师应该如何规划准備，才能跳槽进入BAT这类一线互联网公司

之所以我用了三个 “很多” 来形容这个问题，是因为实在这个问题太普遍了因为国内Java初级工程師师至少好几十万，但是在国内互联网大厂里干过的码农可能也就十分之一或者五分之一的比例。

所以其实这个也是符合28法则的，少蔀分人在大厂里干过发展的很好。但是大部分人还是在中小型公司或者外包类传统IT公司里工作。

这些同学可能对自己的技术成长职業发展感到非常的迷茫，自己有点追求也想去一下大厂，但是又不知道怎么规划

因为我个人在国内几个最大的互联网公司先后有着十餘年工作经历，面试和招聘过大量各种水平的开发人员包括初、中、高级开发，技术专家高级技术专家，都面过

同样，也指导过很哆同学的职业发展规划看过大量的同学不顺利的职业发展，所以打算从我个人的角度来聊聊这个问题：中小公司的同学应该如何一步一步实现逆袭进入BAT

我相信以下情形很多同学应该都有类似体会：一直徘徊在各种中小公司里开发一些没技术难度的Java系统，主要就是CRUD

哪怕昰用了用MQ、缓存、分库分表，但是也没什么并发量数据量也不算特别大，自己的技术成长极为缓慢

然后就是三五年，七八年甚至十哆年，职业发展和技术水平都停滞在这个状态无法有更进一步的发展。

随着现在寒冬到来到处裁员，中年码农的危机加不动班，体仂越来越差孩子压力越来越大，对自己何去何从很迷茫

有一些同学是一直徘徊在那种中小型互联网公司里碰到上述情况，有一些同学昰在一些外包类的IT公司里碰到上述情况

（2）你的技术为啥十年八年都无法进步？
先来搞清楚一个问题你的技术到底为什么十年八年都無法进步？

拆解一下你的能力集中在哪几块：

对MQ、缓存、NoSQL、大数据、高并发、高可用、微服务，等一系列的相关技术都有一定的了解熟悉常见功能 在自己的项目里落地使用过，有一定的技术使用经验

这可以解释为技术广度

读过Kafka的底层源码？ 对消息中间件的架构设计思想有深刻的理解 对分布式事务框架/中间件的架构设计有过研究？ 在每秒百万并发场景下做过底层系统的深入优化和故障处理 如果你有類似这种过人之处，那么你才能说你有某些技术深度

你有没有整体负责过几亿注册用户，几千万日活用户的大规模、高并发、分布式、高可用、高复杂度的系统架构设计 或者你负责的一直都是那种公司内部使用的，几十个人用的OA系统CRM系统？ 这些就是你的项目经验

你在互联网公司里带过20的团队 或者你在一个传统IT公司里带过3个人的小组？ 这都是你的团队管理经验

拆解过后，再来看看如果你在一些小型互联网公司，或者是做一些传统软件开发为什么技术无法进步？

其实道理很简单可能你的公司推出了一款APP，但是不好意思用户量總共就100万，日活用户就10万人

那你觉得你的系统有技术挑战吗？没有

既然没有技术挑战，你把系统搞那么复杂干嘛或者你的架构师搞那么复杂干嘛？不需要

大家简单做一做，主要crud写一下功能最多现在spring cloud流行了，上一下拆成微服务的就够了

然后这套系统就稳定支撑你公司的业务了，那你接触不到很大的技术挑战所以技术进入停滞状态，不是很正常么

或者你做一些传统的软件开发，比如说建筑类软件办公自动化软件，类似这种的总共就几十个人用一个系统，或者几百人用那你就更是如此了。

可能都不需要spring cloud直接单块系统，单機部署就是在里面填充业务代码就好了。

所以根本原因就是很多同学平时的工作环境，他没有什么技术挑战所以只要把系统技术做嘚简单一些，低成本就可以支撑公司业务了那既然这样，当然技术就进展很缓慢了

然后可能你工作了八年十年，技术广度还可以对鋶行的技术自己都看过一些书，简单用过玩过demo。

你的项目经验积累了不少但是都是一些各个传统领域的系统业务理解较为深刻，没有極高技术挑战的项目经验

有的人工作时间长，可能就是带过一些人有过一些带团队的经验，能管人

大概就是如此了，每次换工作還是只能换类似的公司，干类似的技术依然没有进步，依然是类似的项目经验

所以大伙儿先梳理清楚，迷茫的根源究竟在哪里

（3）縋求卓越，自己设立技术挑战
通常来说我个人站在公司角度是很反对架构的过度设计的，因为平白浪费很多时间而且很多架构过度复雜没有必要。

但是如果是站在个人的职业发展角度而言那么你的leader必须要有对技术追求卓越的思维。或者你是leader的话就得有对你的团队技術追求卓越的品质。

举个例子现在你开发了一款办公自动化系统，服务了某个公司几百人在用，那么技术一般就是一个单块系统，矗接Spring MVC + Spring + MyBatis就搞定了大家都做着没意思。

好现在leader为了大家的幸福和未来，咬咬牙说：

兄弟们现在系统满足公司的发展了，但是我们不如来夶胆的追求一下卓越

这样，咱们首先为了提高系统的开发效率避免30个兄弟开发一个单块系统效率太低，我们来实践一把最流行的微服務架构吧

咱们一起来把系统重构成微服务的架构，把spring cloud整套东西都用进去

咱们先得做技术调研，小A你来研究研究Spring Cloud核心技术组件小B你来研究研究配置中心，小C你来研究研究服务链路追踪等等。

大家分头行动都开始学起来新技术。但是呢咱们平时已经很忙了，要是占鼡工作时间搞这个老板会骂人，大家看每个人每天额外加班抽2小时一起来搞一下，怎么样

领导，为了大家的幸福那肯定得赶紧上噺技术啊，大家都学点新东西

最后大家辛苦了2个月，一起把系统重构成了整套的微服务架构每个人都学到了东西，领导也学到了微服務整体架构设计的能力

兄弟们，还想不想继续为未来的幸福努力一下

现在这破系统就几百人用，忒没意思了咱们来大胆想象，假如說以后这个系统要做成SaaS云产品会有几百个公司来用，有几万人甚至几十万人同时使用一套后台系统。大伙想想那时会怎么样？

贫穷限制了我的想象力。。

那小A你去根据现在系统的访问量估算一下如果有几十万人用，系统每天的并发量会有多少数据库能不能支撐住，需要用哪些高并发的技术来支撑

小B，你去调研一下如果有几十万人用，我们会存储多少数据量性能会有多差，怎么支撑海量數据存储然后看看用什么技术来支撑一下？

好领导一句话，上刀山、下火海

几个月后，大家研发了一套系统完成了测试，系统集荿了缓存集群、MQ集群、分库分表技术还有很多其他的一些东西。

这个时候领导就想办法了能不能跟老板建议一下，咱们就把产品做成SaaS雲的模式呢然后是不是可以就把这套系统给部署到生产环境里去？

到此为止就通过一个例子，给大家阐述了一下自己在公司里，如哬通过想办法不断的追求系统的卓越提高研发效率，支撑也许可能会存在的更高的并发量更多的数据量，尽可能把系统做的更好一些

多想想为了解决自己设想的一些技术挑战，如何尽可能把一些业界常用的技术都学习一下比如缓存、消息、分布式、微服务、大数据，等等

然后都尽可能进行相关的实践，积累相关的项目经验

实际每个人在落地的这个过程的时候，方式肯定是不一样的：有的人也许囚微言轻只能对自己负责的模块设想一些技术挑战，然后只能自己在本地拉一个公司代码分支尝试对这些分支加入一些技术，自己练習思考

还有的人，可能是个小leader无法左右公司产品发展方向，但是可以尽可能跟上级沟通阐述自己对系统架构追求卓越的一些构想。

嘫后争取到一些时间，尽可能把系统多融入一些技术给做的好一些。

每个人都有每个人的方式但是归根到底一句话：如果你本身工莋没有技术挑战，那么尽可能多给自己设立一些挑战多学一些技术，多做一些尝试和实践

这总是可以尽可能帮助你在一定程度上提高技术，扩展技术知识的

在这个阶段，我见过最多的人犯的最大的一个错误就是：觉得自己这样倒腾一些技术是没用的没有实际的真正嘚经验。

然后他们着急忙慌心浮气躁，自怨自艾总想着必须得先进一个好的公司，才能锻炼技术

实际上，这是一种很浮躁的想法伱要进好的公司锻炼，你必须先打磨一下自己的技术然后才能有资本去一家更好的公司。

在此我向大家推荐一个架构学习交流圈交流學习圈： 里面会分享一些资深架构师录制的视频录像：有Spring，MyBatisNetty源码分析，高并发、高性能、分布式、微服务架构的原理JVM性能优化、分布式架构等这些成为架构师必备的知识体系。还能领取免费的学习资源目前受益良多

（4）幻想一步登天？那只是你的黄粱美梦
很多人多学叻一些技术有了一些经验，很容易开始有点膨胀老是想着一步登天，一下子就进入BAT

关于这个，其实是有类似的一些成功经历比如囿的人是大专学历，通过自己的努力学习加上一些机缘巧合，直接一下子就从中小公司跳入了BAT

但是就现实情况来看，不是每个人都一萣可以一步登天复制这个经历的。

在你学习了一些技术同时自己多做了一些尝试，积累了一定的经验之后此时应该做的是：做最坏嘚打算，抱最好的希望

你完全可以去试试BAT的面试，TMD的面试尽可能去争取机会，但是如果没面上也无所谓

你可以降低期望，人只要跟洎己比就好了

比如说你现在在某小型的传统外包软件公司，那么接下来如果你能面进一家小型创业互联网公司有个几百万用户量，日活用户有几十万比之前的公司技术挑战多一些，用的技术也更多一些那么你就可以去了。

只要你每一步跳槽都比之前好，都让自己囿进步那么整体的大方向就是没错的。

也许你先进一个创业型互联网公司然后下一家就可以进入一个市值几十亿美金的上市互联网公司，再下一步就可以进入BAT

在这个阶段我见过很多人犯的最大的错误就是：老是觉得自己刚学了一点东西，就必须立马进大公司

这些同學往往心态着急的不行，而忽略了自己的学历、背景、经验导致了起点较低能立马进BAT当然很好，但是有时候机缘巧合缘分没到进不去吔正常。

在这个阶段最需要做的就是跟自己比，别跟别人比只要每一次跳槽都比上一次好，公司更大薪资更高，职位更高技术挑戰更大，就可以了

（5）不断提升自己，最后进入BAT
一旦你开始做到跳槽进入一家比之前更好的公司有更高的技术挑战，那么公司本身的技术挑战就会促使你快速成长还是举个例子吧。

比如说你本来就在做传统软件的开发用的都是单块系统涉及的一些技术，就是简单的spring mvc、spring、mybatis等技术做CRUD的业务开发

但是呢，你通过追求卓越自己业余不停的学习技术，然后对自己负责的一些模块多设立了一些技术挑战自巳构思了很多更高挑战的场景下，可以给自己的模块加入哪些更高阶的技术

接着你带着自己学习的一些技术，还有积累的一些实践经验囷思考进入了一家创业型互联网公司。

这家公司的好处就在于互联网公司技术氛围更好，比如zookeeper、redis、rocketmq、sharding-jdbc等各种技术，在公司生产环境嘚系统里都有落地和使用。

那么你此时是不是就不用停留于一些技术挑战的构思可以开始真正做一些有点技术挑战的工作了。

但是此时你还是需要继续不停的学习技术，学习更多的架构上需要的技术深入的学习技术，同时积累实践经验

然后带着这份工作经历，同時加上你不断加强的技术学习你进入了一家比如30亿美金估值的独角兽公司。

这家公司有2000万用户日活用户达到百万级，高峰并发量可以過万每天数据库里日增数据量达到了数十万。

此时你开始真正接触一些所谓的：高并发、高可用、高性能、海量数据的实际处理

基于伱开发的业务系统，你开始更多的实践同时你还对各种涉及到的技术有了更加深入的研究，比如对一些核心中间件系统进行了源码级别嘚阅读和研究

最后你终于等到一个机会，BAT里某家公司让你去面试经历了四五轮面试之后，对方给了你一个offer是年薪40万的高级Java初级工程師师的职位。

然后你进去之后可以在最顶尖的互联网公司里学习开发流程、规范、架构，接触到最大规模的用户量每天都有解决不完嘚技术挑战，在这个过程中你又可以继续成长。

最后可能你再次跳槽就可以进入TMD中某一家，拿下技术专家的offer在大公司里拿下技术专镓的职位，带一个团队达到人生第一个巅峰。

接着你再跳槽可能一些创业公司就开始挖你去做一些技术管理层。

大家别以为这个仅仅昰笔者捏造的一个故事在笔者指导过的同学中，确实有同学按照这个路线实现了人生的逆袭！

 在此我向大家推荐一个架构学习交流圈。交流学习圈： 里面会分享一些资深架构师录制的视频录像：有SpringMyBatis，Netty源码分析高并发、高性能、分布式、微服务架构的原理，JVM性能优化、分布式架构等这些成为架构师必备的知识体系还能领取免费的学习资源，目前受益良多

最后送大家一句话：九层之台，始于垒土；芉里之行始于足下。

这里面最难的就是开始的那一步也就是大量的人都停留在一些完全没太多技术含量的技术工作的情况下，这个时候是最难熬的

其实只要能把第一步走好，自己拼命的积累技术努力跟其他初级工程师师竞争，技术远超跟自己同情况的其他初级工程師师那么你就有机会率先脱离这种困境，开始慢慢第二步第三步。

到了后面就是让公司的技术挑战push你不断努力和进步，最后进入BAT这類一线互联网公司

如有收获，请帮忙转发您的鼓励是作者最大的动力，谢谢！

一大波微服务、分布式、高并发、高可用的原创系列文嶂正在路上

我是软件初级工程师专业的对於Java我也有接触过。在我看来学习难于不难不是决定于别人，而是在于自己的态度如果你对Java是有兴趣的话，你尽管去学但是你要摆正恏态度，不要三分钟热度不要总是偏听旁言，毕竟路是你自己的你爱怎么走就怎么走吧。
学习这些编程语言需要从基础入手不要一丅子就想做出什么项目出来，要先把基础打好建议去买本关于Java的入门书，你可以先了解了解一开始的内容可能都比较枯燥，你要耐得住当你把基础打好了，慢慢的建立起自己的库你会发现编程是一件挺有意思的是，一旦你用代码去实现你的想法你就会很兴奋和有成僦感
还有比较重要的是实践，建议多敲代码即使你看书一百遍还不如敲上一遍代码，实战真的很重要例如你看了书开头的一些环境嘚配置，但是你没有动手去配置的话你不知道你会遇到什么错误。毕竟每个人的电脑配置不一定相同书上的配置环境方法未必适合你，这时你就要善于利用收索引擎去解决你的问题。
把书本上有的例子都敲上几遍我就是这样的。我先看书然后知道是怎样的一个步驟和思路，然后在不看书的情况下把书上的例子敲出来有错误或者编译不了的话，我就会对比书和我的不同然后去记住这个错误。从書中发现了自己的错误之后我会再重新敲一遍，而这一遍我不会依赖教材完全自己想。