本文是对个人职场的一个简单总结，主要探讨三个话题：

• 我眼里的程序猿金字塔
• 个人学习新知识的方法演进与分享
• 分享知识深度和广度的途径

一、我眼里的程序猿金字塔

首先发图镇楼：

这是我眼里的程序猿能力金字塔。

首先是金字塔的第一层，处在这个层次的大多是0-3年们，他们能够干活儿，并且有进步自己的欲望（因为只有有进步自己的欲望，才可能爬到更高的位置嘛；

工作3-5年的阶段，应当有独立思考问题的能力，并且能够掌握属于自己的学习方法。这个学习方法有很多，比如看书、看视频、看博客、看公众号等等，但不管怎样，你肯定要有结合自身情况，高效学习的方法。个人感觉这个阶段至关重要，事实上，我个人成长速度最快的阶段就在这一时期。

经过5-8年的职场磨炼，你应当有比较丰富的工具链，知道用什么工具快速解决问题，比如：画架构图、做建模，你会第一时间想到EDraw、Draw.io、Processon等工具；又比如你的团队正在面临着巨大的技术债务，你会想到建立代码规范，并去使用诸如阿里编码规约、SonarQube等工具去约束团队，并尝试建立code review的机制。在这个阶段，一般都不会是纯编码的程序猿了，开始会思考一些技术以外的事情。不过，技术人的饭碗绝对不能丢，你应当沉淀在你业务领域比较完备的知识体系，并且能够快速解决项目中遇到的问题，从而成为团队的中坚力量（就是传说中活好的，人人爱的程序猿）

再之后，由于技术已经成长到一定程度，你具备了架构复杂业务系统的能力。然而，从纯粹技术的角度来看，你很可能会遇到一定瓶颈。这个时候，可以考虑扎根在某一业务领域。不管你是什么类型的程序猿，使用什么样的编程语言，但本质上，我们 都在解决各种各样特定业务领域的问题。而技术，某种程度上来讲，只是实现业务的工具。细心的你可以搜索一下51job或者其他招聘网站，你会发现，最值钱的JD，往往并不是要求你技术深度或者广度有多牛逼，而往往需要在某一领域深耕多年，知道这个领域的痛点，并能迅速解决。所以，不妨考虑成为某一领域的专家，也就是上面所谓的最值钱的人。这种人的市场竞争力也是很强的，因为只要你扎根的业务领域不垮，你就能够活得很好，并且你还可以在一定程度上拜托技术两年不追就完全落伍的尴尬境地——技术的迭代实在是太快了！

二、个人学习新知识的方法演进与分享

挺多童鞋问我是怎么学习新知识的，干脆写篇文章总结一下，希望对大家有所帮助。对照书、技术博客、极客时间等学习的方式我就不说了。

早期（0-3年经验）

在15年及更早，由于知识储备少，基础偏弱，大致采取了如下的步骤：

入门：找教学视频

了解xx是什么，能解决什么问题。例如个人学习Spring、Struts、Hibernate时（暴露年龄的尴尬），就是找了 马士兵 老师的视频。

值得一提的是，记笔记非常重要，一是可以形成相对完整的知识体系，二来也能应对面试——面试之前花点时间看看笔记就能很快记忆唤醒。个人原创学习笔记可关注公众号“IT牧场”，点击 资源领取 即可获得。

实战：模拟项目

俗话说，学以致用，为学而学是没有意义的——即使有意义，过段时间也会遗忘。所以个人在掌握基础知识点以及常见用法后，一般都会做个简单的项目。作用主要有几点：

• 巩固知识点
• 总结最佳实践
• 锻炼自己的产品思维

这个简单的项目可能只有三五张表，十来个接口，只要达到锻炼自己的目的就OK了。

从15年起，个人每年都会定"做一个 Side Project "的KPI——这个项目能承载如上三点作用即可。

• 15年：基于当时的主流框架捣鼓的快速开发脚手架 Platform（选型较老，已被时代抛弃） ；
• 16年：基于Spring Boot的半成品 CMS （起因是来了个私活儿，于是开工，后来合作崩了，就废弃了）；
• 17年：基于Spring Cloud的快速开发脚手架与最佳实践总结 Spring Cloud YES ，现已升级到Spring Cloud Greenwich SR1版本；
• 18年：微信小程序 IT牧场 ，在公众号导航栏点击"资源领取"即可进入，近期开源。
• 19年：在慕课上线了《Spring Cloud Alibaba从入门到进阶》，这应该是目前全网仅有的系统学习Spring Cloud Alibaba的视频教程了。

顺便说下，这些项目的内核基本一样，但每次又有优化——每次拷贝老代码前，都再思考一下，看有没有改进的空间——这不是正是"重构"？既是对自己过去代码的重构，也是对自己技术的重新审视。

15年后

15年后，由于工作好几年了，知识面、知识深度都达到一定程度——特别是15年初自学Hadoop以及Spark后。

一点趣闻

学习Hadoop和Spark的契机：当时大数据很火，工资很高，于是面向工资编程，想转型大数据。当时正好所在公司高层变动非常频繁，大佬们都忙着政治斗争——倒是爽了我这种小技术经理以及开发兄弟，整整一个半月，没有任何需求。于是投入全日制投入学习，偶尔改改bug。

后来发现，学习Hadoop和Spark是个笑话——因为学完发现在南京找不到大数据岗位——

• 面试中兴，技术通过了，开17K，部长面也过了，结果卡在学习，说民办本二算本三，不符合他们的学历要求，我也是醉了。
• 面试鸿信：对方说自己有1T数据，规模在南京排前三。我嘴上不说心里想1T算个毛的大数据……

后来又继续搞Web了。但学习还是有好处的——

• 大数据知识点杂，有时候还涉及不同语言……这锻炼了自己的知识整合能力；
• Hadoop、Spark本身普遍是分布式应用，这为后来玩微服务打下很好的基础；
• 很多时候，知识点是相通的，如果能探索到本质，会发现很多所谓高大上的东西其实也就是那么回事。

此时，我觉得看视频入门效率相对比较的低，投入产出比不高，所以调整了下节奏：

入门：GitHub Demo

看教学视频固然是个很好的方法——因为学习曲线足够低，而且会有导师告诉你怎么用，甚至给你总结好最佳实践。但多数情况下，视频教程对于这个阶段的我，效率已经偏低了。很多视频几十分钟才讲一两个知识点…即使倍速，依然感觉在浪费时间。

于是我采取了Demo驱动的方式学习。以学习 Spring Boot 为例，Spring Boot官方提供了 Spring Boot Samples ，把代码clone下来玩一遍，就能相对系统得了解Spring Boot提供的能力。

TIPS

这里说明一下，个人并没有完全放弃教学视频，学习途径的选择是多样的，有时候是二选一，有时是两者配合。

只是进入这个阶段后，个人GitHub Demo驱动相对用得相对更多一些。建议大家做个简单的评估，怎么快怎么来。

系统学习：官方文档

Demo驱动入门后，我一般会对照官方文档撸一遍，例如学习Spring Cloud时，我把官方文档中的用例都过了一遍。

官方文档带来的好处如下：

• 一手文档——官方文档永远是最好的文档，书、视频等等本质也是别人通过学习官方文档进行二次创作的；
• 能体会官方的意图
• 感知该软件的发展趋势(例如阅读Release Log)
• 系统、详尽。

很多人可能觉得自己英文水平欠缺，不敢阅读英文文档，这点我只能说硬着头皮上吧，其实坚持一段时间后，你会发现也就那么回事。大部分英文文档还是比较通俗易懂的——再者，现在谷歌翻译质量非常高，进一步降低了阅读英文文档的难度。

我的 Kubernetes开源书 ，本质就是官方文档翻译(一般看一边翻译) + 个人理解 + 批注。

总的来说，IT行业人才分布也是符合二八定律的——80%的普通人，20%的高手；20%高手里面，80%的普通高手，20%的大佬。我觉得英文不好不是借口，主要还是看你想成为哪个20%——付出和回报是成一定比例的。

另外还有10000小时理论，也可以给大家共勉——要想成为某一领域的精英，必须在这一领域深耕10000小时——如果连英文文档都不敢去碰，怎么可能成为精英？

大道理大家都懂，不再废话了。

闲话

13年个人定了一个原则，就是不找客观借口。因为客观借口只要想找，永远可以找100个。失败是客观事实，但很多失败都是由于主观因素导致的。失败就是失败，首先要有勇气直面。如果连尝试都不敢，就失败了，那真的是可耻到极致的失败。

进入BAT后，我的思想再次发生变化。以前有时候我会觉得由于我没有xx资源，所以我做不了xx事；但现在，我的思想变成因为我要做xx事，所以我需要xx资源，如果没有，那我就去争取；如果没有那我就想办法抢。我离成功还很远，但我会继续努力。技术上成功的难度，对我来说相对低一些，所以我坚持技术路线。

实战：模拟项目

和之前一样，还是做个简单的项目玩玩，项目能起到练手的目的即可。

写博客：让别人也能懂

16年，因为一些契机，从开发转型成为架构师。角色的转变，带来的是思考视角的转变。之前做技术经理时，名下只有四五个人，多数问题口头交流就OK了；但成为架构师后，负责的面变大了，有时得和几十个人沟通，而很多沟通是重复的。

此时，我意识到，不如把大家常见问题总结总结，写成手把手的文档——

• 手把手上手系列
• 手把手解决问题系列
• 血的教训系列……

再后来，发现写Spring Cloud开源书、博客、实体书……

写作本身也是总结的过程，而且不仅要自己懂，还要想办法让别人也能看懂。

可能是写手把手系列多了，所以我的文章一直也是手把手、附具体步骤、配详细代码，原理、源码分析写得相对少一些，这点也被一些人诟病。个人对博客的定位，主要是引导新手，其次是个人心得总结。如果人家已经入门了，还需要到处找文章吗？自己研究研究就OK了。

那些喜欢看源码解读的"高手"，有多少是真高手，有多少是伪高手？我相信真正有源码阅读经验的同学，都不会觉得阅读源码是一件高大上的事情——多数情况下，看懂开源软件源码真的比看懂你所在项目的遗留代码简单多了！

趣闻

18年在华为面试 ，和面试官聊到Zuul相关源码。大致问题是：聊聊Zuul ErrorFilter存在的Bug。这个Bug其实在Camden已经修复了，但是我好说歹说面试官都不信。结果再一打听，原来面试官看到《Spring Cloud微服务实战》是这么写的——这本著作是基于Spring Cloud Brixton撰写的，该版本确实有Bug，所以作者非常贴心地给出了解决方案，却被这位面试官拿来做考察一个人对Spring Cloud是否深入的尺子。

三、分享知识深度和广度的途径

深入：带着问题分析源码

起源于在 焦点科技 的一场面试——焦点科技面试官是对我职业生涯中造成影响的面试官，虽然只有一面之缘，甚至连对方的名字也不知道。

与其说是面试，倒不如说是"切磋"——一般面试，往往是你问我答，OK，NEXT。回答对不对，到不到位，往往不会揭晓答案。

这位面试官很有意思，他会从一个简单的问题逐步深入，并且如果回答不上来，对方会给你很多提示，就像武侠片里师父给徒弟喂招一样——这样面试下来会有所收获，也会了解自己欠缺的地方；更好玩的是，如果你聊到对方不了解的地方，也会问到他懂为止——这其实是考察候选人的沟通能力的常见手法之一，但目前业界又有多少面试官能做到呢？

这次面试给我的启发是：如果广度已经很好，是不是应该深挖呢？

深入，最好的方式就是阅读代码。而为了看代码而看代码，在我看来是浪费生命、浪费时间。所以，我选择在遇到问题时，带着问题分析源码——这里的遇到问题，并不是代码运行报错，或者是项目出异常；而是指对xxx感到好奇，想要了解原理，于是带着问题阅读代码。

广度：跟进业界动态

OSC

个人比较喜欢看科技新闻，大学开始，常年在煎蛋、CNBeta、36氪等科技站上潜水。然而，从15年开始，就一直在995/996，跳到哪儿哪儿加班……时间不够用，必须做出取舍。

经过分析，发现开源动态对自己更有价值。于是坚持每天花10-15分钟刷开源中国的"软件更新咨询"栏目——软件更新栏目相信很多人有所了解，其实就是某某开源软件又发布了新版本的新闻列表。

然而，长期关注至少能获得如下几点信息：

• 咦？xx软件发布了，这个是啥？解决什么问题的？
• 咦？xx软件又发布了，这玩意儿挺活跃啊！
• 咦？xx评论挺多的，看来很快会流行起来。

长期关注的收益：

• 了解行业动态
• 增进知识广度
• 培养行业敏感性

我在15年玩Spring Cloud、16年玩Docker、17年玩Kubernetes，时间基本都在业界流行之前。之所以有这种行业敏感性，和长期刷开源中国是分不开的。

技术雷达

我个人提升广度的第二个途径是《 技术雷达（https://www.thoughtworks.com/cn/radar） 》。技术雷达是ThoughtWorks公司推出的电子杂志，每半年一期，它会罗列出当前市面上热度较高的技术类话题，并对其分级。

关注技术雷达的收益：

• 了解世界范围内流行的技术动向
• 现成的技术选型参考

技术类公众号

个人算是玩公众号比较早的。人生中的第一个公众号建于13年（一个音乐类公众号，当然当初没有看到商机…积累了几千粉之后，白菜价卖掉了。），虽然自己没有运营下去，不过还是养成了订阅一些公众号的习惯。

目前我订阅了差不多近100的技术类公众号，这些公众号都非常的不错。通过公众号，至少可以获得如下收益：

• 了解国内的技术动向
• 由于公众号的垂直性，往往能够深入挖掘某一类知识。成为个人提升技术深度的一个主要途径之一。

也欢迎大家关注我的技术公众号 IT牧场

好，以上是我的分享，谢谢大家。