阿里妹注：作者长居在美国，故学习渠道有些许不同。我们可以举一反三，领会即可～

为何要持续学习，靠经验积累不行吗？

很多人都说程序员的薪资水平不错，可以媲美医生和律师。而程序员和医生、律师的不同点在于持续学习上。不是说医生和律师不需要学习，医生、律师能够凭之前的case积累非常多的经验（这也是大家看病喜欢找年纪大的医生的原因之一），而且这些经验很大程度上可以被复用（很多病因和判罚案例带有相似性）。

程序员这个职业则不同，主要是因为行业更新得太快，积累的经验很快就不适用了。

举几个例子：

如果你是Java程序员，且非常擅长Struts + JSP开发，解决了很多Struts框架的问题。但今天，这部分知识已经过时，需要重新学习。如果仍坚持使用之前的技术，会给同事和公司带来很大的技术负担。大家回顾一下自己从毕业到现在有多少技术都已经看不到踪影了。就阿里巴巴内部来说，很多技术也都已经被淘汰不用了。

就编程来说，有很多编程语言和门第之争。你在这个语言积累的经验到另外一个语言就未必行得通。我很少听说Java组招一个.Net的资深工程师，即便有，那也是给产品做.Net SDK client的。

软件的经验积累还会体现在一个架构设计上。很多同学会说经验积累得多，架构就设计得好，这在今天来说也未必。大家都在云上啦，云上提供的服务基本都是类似的，架构思路和使用的云上服务基本一致。

Amazon的售前人员个个都是行业架构师，给你很好的架构和解决方案，包括迁移方案，所以你就知道架构的门槛了。非资深程序员可以花半天时间看一下 Learn how to design large-scale systems （ https://github.com/donnemartin/system-design-primer ），虽然说是primer，但是还是非常实用的，配合一下 Awesome list ( https://github.com/topics/awesome ) 架构思路和模式都有了。框架和开发包的具体特性和对比了解了，一天就能够成为架构师。

有个笑话：一个产品经理找一个有个性的设计师去设计原型和交互稿。该设计师头都没有抬说道：“你抄的是哪个网站或App? 告诉我，我下午给你做。”如果你看了system design primer，当有架构师找你，你就可以说你参考的是哪个网站的架构。我们回头理解一下然后按照这个设计编写代码就可以了。在云上，架构设计基本都是pattern的，再花很多时间讨论架构设计，就有点想不通了。但对云上的产品做彻底的理解，这个还是需要的。 行业发展得太快，你必须学习，纯靠经验积累行不通，技术淘汰的速度远大于你经验积累的速度。

非鸡汤：不要和程序员谈自己的编程历史，很多的经验在今天已经不适用了。只要2-3年不关注技术，就基本快和程序员和编程绝缘啦，不是绝对，但是通常不会错。

工具要非常熟练

有人跟我说：“不要吹啦，你就是IDEA使用得再熟练，也没有必要将学习和使用工具挂上钩吧。” 说句实在话，看到一些硅谷工程师的培训教程中他们对工具的熟练使用程度，我只能说我还是小白。

有一次和几个google的工程师吃饭聊天，问了一下他们遇到的哪些人比较牛？ 一个工程师说他的leader太牛了，在帮助他找bug的时候，工具和debug使用的熟练程度让人眼花缭乱。很多工具都是他听都没有听过的，而且Python脚本编写几乎如行云流水般。究其原因并非是这个leader一眼就能看出问题所在，有些问题他也是第一次遇到，但他在单位时间内尝试的次数特别多，就很快把问题给逼出来了。

非鸡汤：在排查问题和写代码上，如果你1个小时只能尝试一种方法，别人却能够尝试10次，那么别人就是比你牛。天下武功唯快不破，你后续写demo、查问题、工具的熟练程度都会决定你学习和尝试新事物的速度。

读书 & 看文档

学习还需要系统化。并非单靠看一篇文章就能明白原理。

个人强烈推荐：

https://www.safaribooksonline.com/

Safari应该是出版社联盟，IT类图书基本都能找到。两个小问题是：需要收费，一年大概400刀；图书都是英文的。 Safari Books Online的图书非常全，几乎涵盖绝大多数出版社，我们熟知oreilly, apress, manning, packtpub，addison wiley，而且更新速度非常快。另外Sarafi提供的Learn path也非常有用，能帮助你系统地了解一些技术，如blockchain，ai，machine learnging等等。现在视频资料也非常多，包括专家知识培训和一些技术大会的视频。

除了图书，我们还需要关注文档(reference)。现在很多框架和技术的参考文档已经非常好了。首先是文档的质量越来越高，现在技术都是协作的。Java程序员可以看看Spring Framework，Hibernate，Kotlin，Groovy的文档，质量都非常高。

如果你还停留在文档就是几页介绍和demo，那你的观点可能要改一下了。你看CNCF上的项目，几乎每个项目的文档质量都是非常高的。现在很多项目不是一两个程序员单打独斗，而是一个团队加上像github那种协作非常好的平台，所以文档和代码、新特性不匹配已经非常少了，很多issue都是关于文档的。

另外一些新的技术，刚开始只有文档，在图书还没有来得及出版的情况下，你只能阅读文档。个人在做Service Mesh的时候，对应的图书比较少，只能阅读Envoy + Istio的官方文档，但这没有关系，会稍微难阅读点，但多读两遍就可以啦，毕竟我们不是天才，也不是这个领域的专家。

非鸡汤： 如果money允许的话，Safari Books Online的服务还是值得个人或者团队订阅的。另外时不时重新阅读一下官方文档，毕竟官方文档还是最权威的，也是最新的。

视频学习

之前个人是看书比较多，视频学习方面最多是在youtube上看一下大会的视频。 近一年比较关注视频教学。

视频和图书有什么区别？

首先图书编写比较费时（packtpub的快餐书除外），图书作者要有一定的写作水平，这点对技术牛但写作不在行的人或者没有充裕时间的人就比较麻烦了。Java程序员可能比较了解Josh Long这个人，他的《Cloud Native Java》花了一年多的时间才出版，而期间他已经发了非常多的视频。

视频还有一些文字表达不了的功能：图书中只会贴一段代码，而视频中这些代码是需要输入的，这时你会发现作者很多的黑科技或者黑技巧，你也能学习到。如React入门书籍中，一般只会说明或者引用Redux，而教学视频中，会打开对应的网站，给你列举一些重点特性。另外图书中一些比较容易忽略的东西，在视频中可能会被很好地补充。而且很多的视频制作者，本身是来自框架和技术的开发团队，而不是第三方的图书作者，所以新鲜度和技巧性都非常明显。

不少人对大段文字，尤其是理论和学术很强的图书比较过敏。比如很多人问如何学习domain driven design，但是能将DDD图书看完2-3章不犯困的就很难得。主要是因为文字太多，没有什么代码，又不像小说有情节，不犯困反而很难的。反之，DDD培训视频就不一样，PPT制作得非常好，而且有动画，相关的说明贴切，更容易学习。

这里列举一下比较有名气的视频培训网站，有Pluralsight, Lynda 和 Udemy等。

Udemy的视频是需要单个购买的，一个3-4个小时的视频需要10刀。如果你的阅读量比较大，花费会比较多，而且Udemy不是只关注IT，专业度方面会不够。 Lynda和Pluralsign都是会员制的，你交会费后，可以看所有的视频教学。 Lynda内容非常多，很多人反映内容过时，我个人没有订阅过，搜索一下确实有这个感觉。

个人推荐Pluralsight，这个也是我订阅的服务。内容非常多也比较新，而且有一些是系列的，对跨界学习帮助特别大。 如在做Service Mesh的时候，可能涉及到SDN，让我在Safari上阅读一本SDN的图书，我只能说臣妾做不到，尤其跨界学习的同学，难读啊。但是Pluralsight上一个2个小时的视频教学，我马上就看懂啦。 Java程序员要学ES 6 + React开发，如果找JavaScript图书先看，然后再React图书，周期太长，而Pluralsight上一个ES 6 + React Learning Path视频教学，马上让你快速入门、投入开发。回头把图书和文档补充一下，知识也一起巩固了。

非鸡汤： 还是money问题。条件允许的话，购买一个pluralsight会员，每月29刀，绝对非常值得。Pluralsight的视频基本都有英文字幕，配合作者的ppt，英语不好的同学学习也没有问题。下班没事的时候，找个会议室，几个志同道合的同学，搞点饮料，播放一个跨界或者新技术的视频，看完20分钟，大家讨论一下。英文好的、有技术功底的同学多发表一些观点，其他的同学都也都能了解。

技术新闻，twitter上技术大牛 & 参加技术大会

前面介绍的图书、文档和视频教学，让我们可以了解和深入某一项技术，对付工作应该没有问题。但如果要紧跟潮流，获取灵感，可能还需要关注一些技术新闻，follow twitter上的技术大牛。

每个人都有惰性，大牛也不例外。有时候他们可能不会写文章、文档或者拍视频，只会随意说一下。比如，我第一次了解Spring Fu这个技术时，是在Twitter上。项目还没有启动，Kotlin + Spring的核心团队就开始不经意流露一些消息，你可能由此获得不错的想法，而且大牛会转发技术新闻，这些新闻都经过他们过滤的，你挑选的成本也就低很多啦。

技术新闻没有很好的地方平台统一管理，相对凌乱一些，你需要有自己的方法，不然找寻成本比较高。 很多人喜欢 Hacker News （ https://news.ycombinator.com/ ），但是没有归类，这个有点麻烦。 https://thenewstack.io/ 的归类好很多。 Google Reader关闭后，个人转投Feedly，还是有订阅blog的习惯。

Medium （ https://medium.com/ ）非常不错， a place to read and write big ideas and important stories，这里推荐一下，很多技术牛人在Medium上，不少技术公司的blog也都在medium上有文章。据说还有付费的会员，个人没有尝试过，强烈推荐。 reddit可以归类一些topic，关注一下。 如果你持续关注某一技术，最好加入该技术的Slack或者gitter讨论群，大家都会在群里将相关的好新闻、技术文章进行分享，我在的Kotlin Slack中就了解非常多新的框架和关联技术，大家毕竟还是乐意分享的。

如果时间和金钱都允许的话，个人建议可以参加技术大会，毕竟现场氛围是不一样的。2-3天内，不用工作，不想其他事情，围绕这个话题，而且keynote，和众多同行在一起，这种感觉是不同的。你需要坚信你找对了一个方向，让你更有动力深入了解下去。技术大会有很多的展台，将这个行业非常优秀的企业和技术聚集起来，也是非常不容易的。

非鸡汤： Twitter上技术大牛follow一下，关注对应的技术新闻和blog，平时逛逛slack和gitter，还是有一定的收获的。技术大会一般是美国较多，这对英文和独立出行有些挑战。大家可以结伴或找当地的同学接待，成本会低不少。但是目前技术大会的门票都非常高，基本上都是1500-2000刀，早点订可能在1000刀左右。虽然时间成本稍微高一些，但95%到99%的提升就是要花更多时间、精力和金钱。

做项目，写Demo，看源码

前面说了学习，但是程序猿不写Demo是不行的。项目中可以考虑尝试新的技术。我们现在推行微服务，所以技术栈还是有自由度的，就看你能否hold住啦。不一定所有的技术都能用到项目中，有些是启发性的或者触类旁通的，你需要写Demo，磨磨刀没有错的。文章前面说过，工具要非常熟练，不然一个demo花掉一个小时不值得。读了很多，看了很多，如果再用代码辅助一下，就更好啦。我不是说这些知识都是为了代码，不少是为了架构的。比如，学习ES 6 + React，如果没有代码，很难想象要如何掌握这个知识。

看源码是非常重要的一个技能。至少你code review技能提升，但成本确实高。个人是对Kubernetes还算比较了解，但是让我看Kubernetes源码，压力很大，尤其是不擅长的领域。看Spring Fu的源码没有问题，但是要看Istio和Envoy源码，压力太大。但是你如果决定投入，看源码帮助还是很大的。

非鸡汤： 项目中多尝试一下你学到的新知识，不能惯性使用你熟悉的技术，要知道你熟悉的东西很快会被淘汰，被淘汰后再调整就来不及了。多写一些demo，多磨磨刀。对你本行业的技术，一些源码还是要能看懂的。跨界技术，阅读源码量力而为，让Java程序去看JS框架源码或者C++源码，是需要心理准备的。

如今阅读的人少了

看到youtube上一个技术人员讲述阅读的观点，还是比较独特的。 其实现代人阅读量是比以前多，每天打开手机，各种新闻、文章、视频和朋友圈，阅读量相较以前变大了。对比图书等，这些知识只是生命周期太短，而且营养不高，这也是为何大家觉得阅读少的原因，没有帮助你增长知识。

如果你不是产品经理或者需要对行业进行分析，就技术人员来说，新闻类app对你来说可能用处不大。 这些新闻都是帮助你找找聊天话题，做为饭后谈资，没有什么大用，反而浪费你不少时间，你可能半个小时都在刷新闻，而且现在新闻都有智能算法，保证能黏住你。大家都在抢用户时间，他们可不会在乎你的知识进步，就是让你停留时间长点，多看一些广告。

非鸡汤：音乐是不错的，好像有针对程序员编码的音乐，个人不是发烧友，但是还是推荐一下。

适当的硬件支持

进办公室看一下同事的电脑，你就大概能区分一些职业。用13寸的MacBook Pro或者Air，绝对不是Java程序员。如果是Golang或者C++程序员，一定不会用JetBrains的IDE工具，基本都是Editor类等。对硬件建议仅仅适合Java类的程序员，硬件好点是让你速度更快。苹果最新的MacBook Pro 2018确实非常不错，终于有32G内存，大家可以考虑入手。

总结

如果没有图片、视频，只是纯粹的文字，读起来会比较枯燥。大家在学习的过程中可能有不少自己的心得，如好用的知识整理方法、做笔记的方法、时间管理法等。

【本文为51CTO专栏作者“阿里巴巴官方技术”原创稿件，转载请联系原作者】