我之前写过几篇关于微服务的文章，读者们看完反馈不错。

微服务的架构模式（上）

微服务的架构模式（中）

微服务的架构模式（下）

恕我直言，微服务挺好，但不适合你

同时，也有读者说：

看完文章是懂了，但是自己学的时候，还是有点懵，不知道怎么下手

授人以鱼不如授人以渔。

鱼能解决一时之饥，却不能解决长久之饥。我知道，你们需要知识，同时更需要学习知识的方法。

所以，这篇文章就说说渔，正文开始。

程序员的某些技术也会过时，就像冰箱里的食物，长期不拿出来吃掉，就会过期和腐败。所以，程序员这个行业，需要不断的学习。

我现在已经从程序员转成技术管理了，管理 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 的指标达到要求后，就可以考虑抽取出一个不重要的项目进行新技术栈的尝试了。

总结

如上所说，这就是我日常学习技术的几板斧：

• 我是先通过对要学习的技术分类，去减少学习负担。

• 再去根据技术分类，提取出要解决的一些问题。

• 然后，根据问题去预测出想要读的书的内容范围。又根据这些范围，去各种卖书、评书网站去选书。

• 选书完，采用一些读书技巧，去快速学习。

• 学习完后，必须实践，加深理解。如此，完成一整套新技术学习。

原创不易，看完觉得有帮助，来个三连支持。

你好，我是四猿外。

一家上市公司的技术总监，管理的技术团队一百余人。

我从一名非计算机专业的毕业生，转行到程序员，一路打拼，一路成长。

我会通过公众号，
把自己的成长故事写成文章，
把枯燥的技术文章写成故事。

我建了一个读者交流群，里面大部分是程序员，一起聊技术、工作、八卦。欢迎加我微信，拉你入群。