我之前写过几篇关于微服务的文章，读者们看完反馈不错。
同时，也有读者说：
看完文章是懂了，但是自己学的时候，还是有点懵，不知道怎么下手
授人以鱼不如授人以渔。
鱼能解决一时之饥，却不能解决长久之饥。读者们需要知识，同时更需要学习知识的方法。
所以，这篇文章就说说渔，正文开始。
程序员的某些技术也会过时，就像冰箱里的食物，长期不拿出来吃掉，就会过期和腐败。所以，程序员这个行业，需要不断的学习。
我现在已经从程序员转成技术管理了，管理 100 多人团队每天一堆事……还是写代码、研究技术的日子比较纯粹，没有那么多浪费时间的无聊会议，没有那么多技术无关的事。
虽然如此，但是技术也不能丢。每当出现非常流行的新技术，或者团队技术栈准备升级，我都必须去学习这些新技术，争取在短时间内，能把控住技术栈升级带来的风险。
正是在这种形势下，我也从中琢磨出了一些快速学习的套路和技巧。我分享出来，希望抛砖引玉，能对后来者有一些帮助和启发。
第一步：技术栈需要先分类
当想要学习任何新技术的时候，我经常做的第一件事就是
对要学习的技术领域去做一个分类
比如，几年前，公司的系统要改造成微服务架构，那我就必须去学习微服务的这套技术栈。但是，一学我才发现，微服务的技术栈怎么这么多……
这时候，就要对微服务的技术栈进行分类。目的也很简单，就是为了对学习作出一个规划，根据技术栈的分类，作出一个有着明显轻重缓急的学习计划。
就微服务而言，我将其划分为如下几类：
- 微服务的设计
- 微服务的原理
- 微服务的架构
- 微服务的开发框架和代码规范
- 微服务的安全
- 微服务的运维
分完类之后，再结合当时的情况，我的计划是这样的。
1.
首先，由于我是从零开始，需要设计到落地一条龙。所以，我决定优先摸熟微服务的设计。
这里我会找书看，通过看书弄清楚概念和知道怎么划分业务。为什么是看书不是看网上文章，原因后面会说。
2.
然后，再根据落地的需要，去学习微服务的架构最佳实践以及微服务的开发框架和代码规范。学好这些内容，等以后把微服务落地的时候都用得上。
学的时候，先不需要去深入语法细节，我只需要明白框架的核心思想和代码规范，把控技术落地不会脱离大方向。技术的细节可以等后面真正写代码的时候，再和同事们一起去钻研，
3.
在微服务落地后，就需要微服务的运维了。而微服务的运维，其实可以浅尝辄止的学习，重点是要知道微服务的运维组件和运维常规工作流程。
公司有专门运维团队的，剩下的工作交给运维同事就好了。
4.
在微服务运维后，我感觉只靠学习市面上的微服务套路肯定还不太够，如果要让微服务能更好的适合我们自己的业务，还需要根据底层微服务的原理，去搞透微服务最佳实践为何这样做的原因。
很显然，这块的学习难度非常大，需要不少知识储备。
但是，再难学也值得学，因为极有可能我们需要结合自己公司的业务，对微服务作出个性化的定制。
建议：找几个兄弟一起组队学习原理这块。
5.
微服务的安全，主要是网关的安全措施，大部分公司都有安全团队，这部分交给他们负责就好了。
所以，再经过分门别类之后，我们就很清晰了。
微服务的学习顺序就是：
微服务设计 > 微服务架构 > 微服务开发框架和代码规范 > 微服务原理 > 微服务运维 > 微服务安全
学习内容的详尽程度则是：
- 微服务设计、微服务原理需要多读几本书，尤其是原理，要深入学习 + 和牛人广泛讨论；
- 其他部分的学习，优先级没那么高。
第二步：选择合适的书
当我们根据技术栈分类定出学习计划后，接下来就要选择合适的书籍学习了。
这里需要强调一下，以我的经验，对一门全新的技术学习，不建议完全通过看网上的文章。
因为网上的文章有好也有坏，坏的是真坑人，而且作为初学者，你没有什么经验，不知道文章是否有错误。
我举个例子，网上的链路跟踪，尤其讲 SkyWalking 的相关文章，很多都是错的，如果对链路跟踪不熟悉，就很难分辨出错误，到时候不慎把错误的观念用到了系统里，再改正就非常费劲了。
所以，入门阶段还是老老实实的找一些权威书籍看吧。
但是，权威书籍也有问题，因为书的受众不一样，如果一些书读的不合适，比如，选的书籍讲的都是过时的技术，又或者有的书籍讲的非常晦涩，理解起来非常费劲，那这些书就不合适我们去读，读了要么浪费时间，要么错用过时的技术。
怎么选择合适的书？
比如，我想学微服务设计，我发现微服务设计和领域驱动设计又是紧密关联的。领域驱动设计又有很多的书，有讲理论的，有讲实战的，甚至还有混杂着其他技术栈的。
我当时需要的是理论 + 实战的书，并且最好有在已有项目移植到微服务的相关案例的书。
接下来就是去网上看书评了。一般来说，现在豆瓣、当当、京东的书评和书籍简介都比较不错了。
不过，我更偏好英文书一些，所以，当时根据亚马逊的评价找到了一本《Implementing Domain-Driven Design》，这本书后来翻译成中文了，叫《实现领域驱动设计》—— 我粗看过，我认为翻译的不好。
事后证明，这本书确实解决了我的问题，让我摸清楚了域、子域、边界上下文之类的关键概念。
第三步：读书需要技巧
选完了书，就要去读书。但是，任何一本 IT 书籍，可都是不薄的。
像我前面举例的《Implementing Domain-Driven Design》，这本书就是六百多页的厚度。如果一天读 20 页，需要 30 多天，这个时间就太慢了。所以，就需要技巧：
先速读后精读
一般来说，对于六百多页的书，尤其是讲解的概念穿插实战的，应该开始的时候，快速阅读。我大概一天是 100 - 200 页左右，时间控制在 4 个小时，连续不断的阅读。
这种阅读，看上去很难，其实是建立在快速的跳读和略读上的。读取的时候，只找关键词，尤其是名词。
找到关键词后，一般就要提取知识点。三五个关键词，就能提取出一个关键知识点来。遇到不会的，也可以当做关键词提取出来。
关键词往往和小章节的标题能对应上，根据关键词，找到章节中的解释，看明白了，就能跳过别的章节内容。
速读，弄懂即可，不需要把所有的内容都读完。
这样，一本六百多页的书，大概一周就读完了。
读完后，别着急，然后就需要根据你提取的关键词和知识点去做精读了。
这时候，由于书籍的关键点已经提取出来了，你只需要精心学习提取的知识即可。
一般而言，知识点提取后，需要精读的内容往往只有原来整体内容的几分之一。
我精读这本书大概花了一周左右。
在精读期间，如果有一些发现理解不足的，还需要去查一些别的资料来补充理解，或者动手实践，或者和别人一起交流，除了讲解自己的看法和理解，也需要能汲取别人的看法和理解。
精读的最佳结果是，你能用自己的话把原来的概念和别人讲清楚。
这样，总的算下来，读这本六百多页的书需要花十天、半个月的时间。
说起来，其实大家可以问问身边认识大厂的高手，你会发现，他们大多数人读书，都是我这样类似的读法，确实非常有用。
第四步：落地实践
书读完了，肯定有很多不足的地方。这时候，就需要通过技术实践去加深理解、弥补不足。
实践分为两种：
1. 书中的实验
大部分技术书籍，大部分都有些对应的课后习题或者实验。
因为这些实验都是附属在某些具体讲解、某些概念的章节后，针对性非常强。所以，如果能不看书，根据自己的理解，去顺利把实践做出来，那就证明，确实学习到位了，可以把学到的东西用到实战中了。
2. 实际中的场景
当书中的实验都做完了，就可以考虑真实的项目场景了。
可以先根据工作需求，打造出一个包含了所学新技术全栈的 Demo 出来。
比如，微服务，就可以搭建一套，有网关、有配置中心、有链路跟踪的 Demo。
Demo 搭建之后，还可以采取一些测试用例对这个 Demo 进行测试，不管是业务测试还是性能压测，都要进行。
当 Demo 的指标达到要求后，就可以考虑抽取出一个不重要的项目进行新技术栈的尝试了。
总结
如上所说，这就是我日常学习技术的几板斧：
-
我是先通过对要学习的技术分类，去减少学习负担。
-
再去根据技术分类，提取出要解决的一些问题。
-
然后，根据问题去预测出想要读的书的内容范围。又根据这些范围，去各种卖书、评书网站去选书。
-
选书完，采用一些读书技巧，去快速学习。
-
学习完后，必须实践，加深理解。如此，完成一整套新技术学习。
原创不易，看完觉得有帮助，来个三连支持。
你好，我是四猿外。
一家上市公司的技术总监，管理的技术团队一百余人。
我从一名非计算机专业的毕业生，转行到程序员，一路打拼，一路成长。
我会把自己的成长故事写成文章，把枯燥的技术文章写成故事。
欢迎关注我的公众号，关注后可以领取高并发、算法学习资料。
