程序员这个行业，日新月异，技术体系更新速度快，新技术新框架层出不穷，所有的技术都像是一个无底洞，当你学得越多就会发现不懂的越多，不懂的越多，需要学习的就更多。
因此，一旦选择了这个行业，就意味着你必须不断学习才能跟得上大家的脚步，而要想成为一名优秀的程序员，更是需要通过正确的方法，设定正确的目标来进行不断地学习。
作为一名常年在各种技术群里吹水却又无比热心肠的老司机，看到有人提问时，总是会蹦出来帮忙解决问题，因此，群里的很多小伙伴经常会找我询问应该怎么样学习一门技术，大家也都亲切地称我面哥。
只要需要帮助的地方就会有我面哥的身影，所以，为了帮助部分同学解决一些学习上的困惑，今天我就来分享和探讨下我的一些学习经验，大家如果有什么意见或建议，欢迎在评论中留言哈。
读文档，读文档，读文档，重要的事情说三遍！！！
首先我要说的就是读官方文档，
注意：这里我提的官方文档主要指的官方教程（guide\tutorial\Training等），当然API文档也是需要读的，但大部分情况可能更多的是查询
如果你是一名有一定开发经验程序员，那我强烈地建议你一定要看官方文档！！！
如果你是一名初学者，那现阶段来说，看文档会是件非常非常的吃力的事，但我还是强烈地建议你一定要看官方文档，不过可以在你通过视频教程或是书籍学习并入门之后再慢慢的阅读。
官方文档就像是城市的一张地图，技术体系则犹如城市的一条条路线，而详细的功能及知识点就是那一座座美丽的城市建筑。
试想一下，当你来到一个陌生的城市，需要去到某个建筑地点时，是有地图快呢还是有地图快呢？
在手握地图的情况下，你可以轻松地定位到建筑的具体位置，并选择最短的线路来到指定的地点。
而没有地图的情况下，只能通过询问他人或者查找资料的方式来找寻方向，你需要花更多的时间来查找路线，而且一不小心便绕进了弯路或是掉进了死胡同。
技术学习则是同样的道理，一门技术的官方文档是对这门技术的体系结构以及重要知识点最直接也是最准确的描述和讲解。
如果你仔细阅读过了它，那你就对这门技术的整个体系、架构、知识点已经有了宏观上的认识，在你实现某个功能时，你可以很快定位并找到最佳的解决方案。
而那些没有阅读过文档的人，在功能实现时则只能通过查找资料或是询问别人的方式来找答案，一些本来可以使用官方特性轻松实现的功能可能一不小心便走了条复杂的弯路。
有人可能会问，面哥，官方文档真的这么神奇？
可以肯定的说，是的，就是这么神奇，99.99%的官方文档内容非常详细，甚至比很多书籍跟博客都要详细，恩，如果不详细，那我想你一定是阅读了假文档！所以，只要你能仔细地将文档阅读一遍，你的某一门技术一定是会有飞跃性的提升的，你对这门技术的理解已经可以超越不少人了。
那读中文文档可以吗？
我的建议是直接上英文吧，一般情况下中文文档的翻译周期比较长，而现在技术的更新迭代速度又非常快，我在读Android官方文档的时候就遇到过上午过还读着的文档下午内容就被大面积更新了，如果你想做个时刻领先的开发者，那阅读官方英文文档绝对是最佳选择。
同时一些翻译的文档夹杂了个人的主观理解，每个人的理解都可能存在偏差，只有自己去阅读才能更好地理解文字的内容。
举个例子，Android开发中一直是在drawable目录中存放图片资源的，后来多了mipmap的目录来存放启动图标进行优化，但是由于一些人阅读理解上的偏差，mipmap很快被误读成了所有图片资源都放在mipmap中，我想很多Android开发被误导的小伙伴对此应该深有感触吧
但是有人要说了，面哥，我也想看文档，可我是个英语渣，怎么办？
这个怎么办呢？我只能说，撸起袖子就是看，用上一切能用的工具，什么谷歌翻译啦，什么有道词典啦，什么有道网页翻译啦（这个很好用，翻译效果也很棒），觉得什么好用用什么！
说起刚开始看官方英文文档，我的内心其实是拒绝的，但是项目用的框架竟然没有什么中文资料，项目的进度压力又压在身上，所以只能委曲求全，通过阅读文档来找答案，一遍不懂读两遍，两遍不懂读三遍，直到读懂为止。
也正是因为这样的经历，让我发现官方文档竟然如此的神奇，同时也渐渐意识到英文文档其实并没有那么难读。
通常，老外的技术文档语法一般都很简单，只要你初中毕业了（别跟我说你初中都没毕业），那花点时间看懂基本是没问题的，而计算机专业单词其实也并不是很多，通常情况下，我并不会去刻意地查找某个单词，而是遇到不懂的单词就去查一下，查得多了，就自然而然记住了。学到技术的同时又提升了英语阅读能力，真的是一举两得，哈哈。
随着单词的积累，阅读数量的增加，你的阅读速度会越来越快，甚至能赶上母语的速度，这时的你，学习任何新的技术都能通过文档来快速入门，有心的人，更是会在第一时间将文档翻译成技术文章发布到博客上，没错，我们不生产文章，我们只是文档的翻译工，此时，在很多人（大部分还没学会阅读文档）眼中，你已经是他们心目中的大牛了。
所以说，很多人跟大牛之间的其实只是差了个官方英文文档！
最后补充个阅读英文文档的另一个作用，就是会提高你在需要解决问题时搜索关键词的能力，因为读得多了，很多关键单词已经留在了脑海中，当你需要google或者stackoverflow的时候，便很容易抓住重点关键词从而搜索到需要的内容。
官方文档扯完了，我们接着来聊聊如何进阶学习
首先要说的是，技术的学习是个日积月累，由量变到质变的过程，没有任何的办法能够让你在短时间内成为大牛，所谓的一步登天，是留给那些传说中的天才的，但天才毕竟只是极少的一部分人。
大部分大牛还是靠着持之以恒的毅力，冠以正确的学习方法，通过不断努力，不断学习，花费了大量的精力才达到了他们现在的成就。
所以，当你通读完官方文档的时候，你实际上只是迈出了一小步，要成为真正的大牛，还需要在之后的学习中不断努力。
那我们如何来进行下一步的学习呢？
那就得说到项目实战了
我们学习一门技术的最终目的就是将其运用到实际项目中，一门技术不管多厉害，如果没有办法运用到实际项目中，那它的意义跟价值就非常有限了。
而且人脑不比计算机，是会遗忘的，如果不通过大量的项目实战，很多知识点你很快便会忘记，至少我是这样的（谁能告诉我，记忆力不好怎么才能被拯救！！）。
所以读完官方文档后，我们是一定要通过大量的项目实战来不断巩固我们的知识点的，此时的你很多知识点其实是不能完全理解的，只有通过项目的历练，在踩坑中分析，在解决问题中成长，才能从本质上理解一些技术的概念。
有经验的开发人员应该多多少少有这样的经历，就是有些概念一开始并不是很理解，但是在一次次的项目过程中，你会发现竟然不知不觉地明白了其中的原理，是的，就是这种感觉！
对于项目实战，我其实没有太多的技巧，还是一句话，撸起袖子就是干，但是这个过程中你一定要去多思考，为什么这么写，为什么这么做，学着去了解原理，去关注本质。
再来聊聊读技术文章
在这样一个信息大爆炸的时代，要从网上找到某一门技术的干货文章是非常容易的一件事，各类的技术平台（csdn，cnblogs，oschina，infoq，segmentfault等等等），各类的微信平台公众号，都是很好的获取干货信息的途径。
虽说官方文档很神奇，但是还是有很多知识点我们可能还没发现，因为他们往往隐藏在更深的API文档之中，而大量的API也导致我们很难将所有的API文档都通读，更多的还是将其作为一个查阅工具来使用。
在我的观念里，不主动去关注各种技术平台获取技术信息的程序员不是一名合格的程序员，
所以每天早晨我都会花至少一个小时在关注的各类技术平台上获取有用的信息
一方面查找相关技术的干货文章，通过对这些文章的阅读对自己的知识点进行巩固和查漏补缺，毕竟技术的学习不仅仅是文档上那些最原始的技术点，还包含各种架构的设计、工具的使用、功能的实现及解决方案的应用等，通过这些平台上的各种文章，可以让自己的知识体系更加地完善。
另一方面，作为一名开发人员，我们需要通过这些平台了解最新的技术动态，关注技术的发展趋势，毕竟现在技术的更新速度非常之快，技术生态圈的转换随时会导致某项技术的淘汰（作为一个俗人，我是来赚钱的，所以根据技术趋势做好技术储备对我来说是必不可少的）
话说回来，程序员真是一群爱分享的小伙伴，所以现在的技术文章真的是太多太多了，多到眼花缭乱。
我们不得不根据自己的情况来进行适当的筛选和阅读，来提高学习效率。
就我来说，我根据自己的理解将技术类文章分为了四类：
知识点讲解类：一般针对某个技术的特定知识点进行介绍。
功能实现\解决方案类：针对性比较强，一般都是某个特定功能或是特定场景下的功能实现或是方案应用包括Bug的解决方案等，文章一般会带有一定的思路分析，以及具体代码实现。
源码\框架原理分析类：针对各个技术点或是框架进行源码拆解、分析和讲解。
学习方法/经验总结类：主要是介绍一些学习方法，以及对项目开发中遇到的问题进行总结分析。
对于知识讲解类的文章，如果你已经学会了阅读官方文档，那很容易就能够判断它是否只是文档的搬运工，如果是文档的搬运工，我会快速略过，重点关注作者是否加入了自己的分析和观点。如果是作者原创的，那我会仔细阅读一遍，看看自己对于某个知识点的理解是否有偏差，是否有遗漏。
功能实现\解决方案这类的文章，场景众多，我重点关注的是它的实现和分析思路，以便在类似的场景中进行举一反三，对于一些常用功能或方案，我会仔细阅读和研究他们的代码，剩下的则主要进行标记和收藏，在大脑中留个印象，建立个索引，在需要的时候再去进行查阅，像我这样的渣记忆，不常用场景的实现一段时间后就只记得标题了。
源码\框架原理分析类的文章我会反复阅读，同时结合源码做验证，并且定期做一下复习或是总结，在大脑里不断加深印象，因为对于原理的理解能够帮助我在遇到项目难题时更快更好地找出最佳的解决方案。
学习方法/经验总结类的文章，数量上相比其他类型的文章并不会太多，一般我会很仔细的阅读，正所谓前人栽树后人乘凉，学习他们的经验可以让我们少走不少弯路，当然这类文章主观意识会比较强，需要我们自己来进行辨别哪些是真的有用。
有人可能要问了，面哥，每天花一小时阅读技术文章，文章读得会很凌乱吧
确实是这样的问题，我们大脑的容量毕竟有限的，就像我们的LRUCache缓存策略，最常用信息的总是会保留在大脑中，但是时间太久了不关注的内容很快就会丢弃遗忘（传说世界上有那么一群“超忆症”患者，没有遗忘的能力。能把自己亲身经历的事情，记得一清二楚，能具体到任何一个细节，好羡慕有木有！)。
对于遗忘的问题，我们能做的就是做好收藏工作，但是技术平台太多，将文章收藏在各个平台中当需要查找的时候会发现记不清收藏在哪个平台了，这时一个平台一个平台的搜寻效率肯定是低下的。
所以我们可以使用云笔记或者github，将那些你觉得优秀的需要收藏的文章整理到一个地点去，按照自己对文章的分类，建立不同的链接索引，给每个索引的标题起个你认为重要的关键词，在每次添加新的文章的时候可都回顾下收藏的索引，这样在你想要查找某篇文章时便能用最快的方式查找到。
我会读文档了，又阅读了这么多技术博客，是不是就不用其他方式再学习了？
答案肯定是不可以！！！
虽然博客的干货文章非常的多，但是大部分情况下知识体系都是相对比较零散的，相比书籍，它没有那么系统化，相比视频教程，它又没有那么的直观，所以抛开文档跟博客的学习，我们还需要根据自己的情况额外地进行书籍或是视频教程的学习。
有人觉得自己总是静不下心来看书，我的方法是，阅读某本书的时候给自己定一个小目标，比如每天阅读该书至少20页内容，这样每天学习的内容不会太多，不容易让人变得焦躁，当然，你可以根据自己的情况制定每天的阅读量，如果按照20页每天的阅读量来算，一本500页的书，不到一个月就读完了。
这里给大家推荐两本我蛮喜欢的书《代码大全》《重构 改善既有代码的设计》，虽然技术框架一直在变，但是这些软件工程类的思想是一直不变的，有兴趣的同学可以去读读这两本书，我想一定会有不少收获。
有人觉得看视频教程时间太久，实际上也确实如此，有的博客十多分钟能够读完的内容，放到视频中去讲常常需要1个小时，但是视频教程的优势就是你可以看到实时的操作跟讲解画面，一些概念更直观，更容易让人理解。
当然如果你播放的是本地视频，可以使用诸如potPlayer这样的支持加速播放视频，同时视频声音又不会改变的播放器来加速视频的观看。
到了验证进阶学习成果的时候了
什么，你读过的博客都忘了？
哎呀，我刚看过的书跟视频的内容好多也记不清了呢！
Oh，NO,几个月前项目实战中遇到问题时的解决方案也忘了！
所以说，人的记忆力是非常有限的，随着时间的流逝，很多东西会自然而然被遗忘！
那么，在技术学习或项目开发中，我们应该怎么做来尽量减少我们的遗忘率呢？
我的做法是准备好笔记类工具，可以是云笔记，可以是博客，也可以是github，总之，能够方便我们使用和随时随地查看的工具都可以。
当我们在技术学习或项目开发的过程中，遇到重要的问题或知识点时，我们可以顺手打开工具进行整理，或者简单记录一下，等到学习或项目功能完成后，再统一归纳总结并重新整理。
这样，我们的知识便整理了成了自己持久化的文档，当你以后有需要的时候，就可以随时打开他们进行知识巩固跟复习了。
如果你乐意，还可以随时将他们分享到博客平台上，当你的分享不断地收获到赞赏，当关注你的用户越来越多时，我想你的成就感一定是不言而喻的，与此同时也能给你的学习工作带来更大的动力。
当你的归纳总结能力越来越强，你的分享越来越优秀时，会有工作机会找上门，也会有供应商找你做项目，更有甚者会有出版商找你出书，可以说，这也是一个自我营销不错的方式！
说了这么多，这里我给大家强烈推荐一个非常适合用来做归纳总结和记录的工具 GitBook,它的功能非常强大：
- 支持markdown编辑器，现在很多博客（csdn,简书）都支持markdown编辑器，这样你自己的记录如果想发布到其他平台上的话只需要复制黏贴就可以了。
- 支持绑定github账号，能够文章存储到github仓库中，进行版本管理和维护，可以让大伙一起来写文章哦，同时还能自动绑定到github的博客系统上。
- 支持章节分类，自动生成各章节目录，可以在线阅读并生成pdf等格式的电子书
这里给大家找了个教程
https://segmentfault.com/a/1190000005859901
如果觉得命令操作太麻烦，可以参照教程到后半部分，直接到
https://www.gitbook.com/editor/ 这个地址下载gitbook editor的客户端，
操作起来非常简单方便。
技术学习光靠一个人是不行的，所以我们还需要多跟别人探讨技术问题，可以是周围的同事跟朋友，也可以是技术群
说到技术群，我加了不少的技术群，闲暇时我会在群里跟大家讨论讨论技术或是唠嗑。
当然我们加技术群的目的绝不只是为了唠嗑。
这里就来聊聊技术群可以给我们带来的帮助吧：
对大部分人而言，技术群给我们的好处之一就是不懂的技术问题可以进去寻求帮助，当然，提问的前提最好是你已经百度，Google跟stackoverflow过了，并且没能找到合适的答案。
群里都是来自五湖四海的小伙伴，他们来自于不同的公司，而不同的公司可能采用不同的技术或架构，通过对群里聊天内容的筛选，我们经常能在大家沟通的过程中看到一些新的技术框架或名词，我会将这些名词跟框架记录下来，然后到网上去进行了解和学习，可以说，这在一定程度，帮助我拓展了视野。
这是我最喜欢干的事，就是帮助别人解决技术问题，有人可能会疑惑为什么我会喜欢帮助别人解决技术问题
首先呢，帮助别人解决技术问题能给我带来一定的成就感
其次呢，你在帮助别人解决某个技术问题时，你需要对这个问题的产生及相关概念有比较透彻的认识，同时还需要组织好自己的语言，用最通俗易懂的方式来让对方理解，这个过程无形中就帮助你巩固了知识点，同时也提高了自己的文字表达能力；
如果遇到没有遇到过的问题，那解决这个问题的过程，不仅可以提升自己解决问题的能力，同时还能帮助我们学到新的知识。
是时候开始更高阶的学习了
通过上面提到的各种方式的学习，在一段时间的积累后，你对技术的各个概念、知识点，都已经掌握得非常不错了，这个时候，想要继续提升，阅读源码\分析原理是成了我们的不二选择。
那我们如何来阅读源码呢？
对于面向对象语言相关的技术，我的建议是如果有时间，一定要把24种设计模式，6大设计原则学一遍。
优秀的项目或者框架，在应用架构的设计上都是非常优秀的，它们往往会应用各种设计模式来优化项目的架构，也因此会导致项目的结构异常复杂。
这类的源码只有当你对设计模式有了一定的理解时，才不会被源码中的各种接口，继承，抽象类搞得晕头转向，才能充分理解为什么代码要这么写，这么写的作用和意义。
当然如果光靠读，你是很难看懂理解各个文件之间的关系的，我们需要准备一些辅助工具，比如UML图绘制工具，例如visio、rational rose等，我自己目前使用的是starUML，这个工具主要安装程序够小，试用版的功能也足够我画大部分图了。
在阅读源码的过程中，我们就可以通过绘制工具将各个文件之间的关系绘制出来，同时绘制出大概的流程图，这样一轮代码读下来，基本就能理清代码的整体结构了，接下来就对代码细节的学习也就会变得相对容易了。
最后，阅读源码后记得做好总结归纳，并记录下来，否则一段时间后，你肯定是会淡忘的，毕竟大部分人连自己的代码过几个月后都搞不清楚了，更何况是别人的代码呢
最后的提升
就像我前面提到的，技术的学习是个日积月累，由量变到质变的过程，按照上述的方法，并且能够持之以恒地学习下去，经过几年的历练，你已经可以超越大部分程序员了。
但是要想成为一名不被淘汰的真正的大牛级程序员，却还有很长的路要走。
想要不被淘汰意味着什么？意味着你写的东西需要足够核心，并且很难被年轻人替代，如果仅仅停留在使用某门技术或是框架上，随着年龄的增长，你的自身价值是会越来越低的（如果转管理，那就另说了）！
我们知道，越是核心越是深层次的技术，会涉及到越来越多的算法、数据结构、编程思想等知识，不管现在的技术及框架更新速度有多快，底层的很多算法跟原理还是万变不离其宗的。
所以，最终我们还是需要在算法，数据结构，编程思想，计算机原理等方向深耕！！
现在你能明白为什么有人会说算法、数据结构决定了程序员的高度了吗？
也许有很多人不是计算机专业出生，或是培训机构培训出来的，没有学过这些内容，其实即使是科班出生的程序员，在几年的应用层开发之后，曾经算法、数据结构相关知识也会被淡忘。
如果有心在这行深耕技术的同学，建议可以补学一下相关知识，这里给大家提供一个系统的计算机专业的学习链接:
顶尖中文大学计算机专业课程体系
有兴趣的同学就指定自己的计划开始学习吧！
最后，如果大伙有什么好的学习方法或建议欢迎大家在评论中积极留言哈，希望大家能够共同学习、共同努力、共同进步。
面哥在这里祝小伙伴们在未来的日子里都可以 升职加薪，当上总经理，出任CEO，迎娶白富美，走上人生巅峰！！
