在字节跳动干了 2 年后端开发，太真实…

先简单交代一下背景吧，某不知名 985 的本硕，17 年毕业加入滴滴，之后跳槽到了头条，一直从事后端研发相关的工作。之前没有实习经历，算是两年半的工作经验吧。

这两年半之间完成了一次晋升，换了一家公司，有过开心满足的时光，也有过迷茫挣扎的日子，不过还算顺利地从一只职场小菜鸟转变为了一名资深划水员。

在这个过程中，总结出了一些还算实用的划水经验，有些是自己领悟到的，有些是跟别人交流学到的，在这里跟大家分享一下。

学会深入思考，总结沉淀

我想说的第一条就是要学会深入思考，总结沉淀，这是我觉得最重要也是最有意义的一件事。

先来说深入思考。在程序员这个圈子里，常能听到一些言论：我这个工作一点技术含量都没有，每天就 CRUD，再写写 if-else，这 TM 能让我学到什么东西？抛开一部分调侃和戏谑的论调不谈，这可能确实是一部分同学的真实想法，至少曾经的我，就这么认为过。后来随着工作经验的积累，加上和一些高 level 的同学交流探讨之后，我发现这个想法其实是非常错误的。

之所以出现没什么可学的这样的看法，基本上是思维懒惰的结果。任何一件看起来很不起眼的小事，只要进行深入思考，稍微纵向挖深或者横向拓宽一下，都是足以让人沉溺的知识海洋。

举一个例子。

某次有个同学跟我说，这周有个服务 OOM 了，查了一周发现有个地方 defer 写的有问题，改了几行代码上线修复了，周报都没法写。可能大家也遇到过这样的场景，还算是有一定的代表性。

其实就查 bug 这件事来说，是一个发现问题，排查问题，解决问题的过程，包含了触发、定位、复现、根因、修复、复盘等诸多步骤，花了一周来做这件事，一定有不断尝试与纠错的过程，这里面其实就有很多思考的空间。比如说定位，如何缩小范围的？走了哪些弯路？用了哪些分析工具？

比如说根因，可以研究的点起码有 linux 的 OOM，k8s 的 OOM，go 的内存管理，defer 机制，函数闭包的原理等等。如果这些真的都不涉及，仍然花了一周时间做这件事，那复盘应该会有很多思考，提出来几十个 WHY 没问题吧...

再来说下总结沉淀。这个我觉得也是大多数程序员比较欠缺的地方，只顾埋头干活，可以把一件事做的很好。但是几乎从来不做抽象总结，以至于工作好几年了，所掌握的知识还是零星的几点，不成体系，不仅容易遗忘，而且造成自己视野比较窄，看问题比较局限。

适时地做一些总结沉淀是很重要的，这是一个从术到道的过程，会让自己看问题的角度更广，层次更高。遇到同类型的问题，可以按照总结好的方法论，系统化、层次化地推进和解决。

还是举一个例子。做后台服务，今天优化了 1G 内存，明天优化了 50%的读写耗时，是不是可以做一下性能优化的总结？

比如说在应用层，可以管理服务对接的应用方，梳理他们访问的合理性；在架构层，可以做缓存、预处理、读写分离、异步、并行等等；在代码层，可以做的事情更多了，资源池化、对象复用、无锁化设计、大 key 拆分、延迟处理、编码压缩、gc 调优还有各种语言相关的高性能实践...等下次再遇到需要性能优化的场景，一整套思路立马就能套用过来了，剩下的就是工具和实操的事儿了。

还有的同学说了，我就每天跟 PM 撕撕逼，做做需求，也不做性能优化啊。先不讨论是否可以搞性能优化，单就做业务需求来讲，也有可以总结的地方。比如说，如何做系统建设？系统核心能力，系统边界，系统瓶颈，服务分层拆分，服务治理这些问题有思考过吗？每天跟 PM 讨论需求，那作为技术同学该如何培养产品思维，引导产品走向，如何做到架构先行于业务，这些问题也是可以思考和总结的吧

就想一下，连接手维护别人烂代码这种蛋疼的事情，都能让 Martin Fowler 整出来一套重构理论，还显得那么高大上，我们确实也没啥必要对自己的工作妄自菲薄...

所以说学习和成长是一个自驱的过程，如果觉得没什么可学的，大概率并不是真的没什么可学的，而是因为自己太懒了，不仅是行动上太懒了，思维上也太懒了。
可以多写技术文章，多分享，强迫自己去思考和总结，毕竟如果文章深度不够，大家也不好意思公开分享。   

积极学习，保持技术热情

最近两年在互联网圈里广泛传播的一种焦虑论叫做 35 岁程序员现象，大意是说程序员这个行业干到 35 岁就基本等着被裁员了.

不可否认，互联网行业在这一点上确实不如公务员等体制内职业。但是这个问题里 35 岁程序员并不是绝对生理意义上的 35 岁，应该是指那些工作十几年和工作两三年没什么太大区别的程序员。后面的工作基本是在吃老本，没有主动学习与充电，35 岁和 25 岁差不多，而且没有了 25 岁时对学习成长的渴望，反而添了家庭生活的诸多琐事，薪资要求往往也较高，在企业看