我觉得任何技术都可以从这么几个角度去考虑:

技术选型

• 这个框架它解决了什么旧的问题? 又带来了什么新的问题?
• 它与其他同类技术相比有什么特点? 其侧重点在什么地方?
• 基于以上问题, 该框架适用于什么场合?

软件工程的一个基本原则就是没有银弹, 任何技术都有其适用的场合, 在学习一个技术之前先想清楚为什么要学它.

比如说, 微服务的两大主要优点是 分布式部署 和 代码解耦, 但问题是如果你的项目量级根本没有大到需要分布式部署, 而且业务的复杂程度也没有大到耦合度很高, 那么到底是为什么需要它呢? 不要忘记了, 一项技术会有优点的同时那么必然也会有缺点以及其带来的问题.

优点没有享受到, 反倒是被缺点坑到吐血, 那就是本末倒置了.

当然你说是做技术储备, 从长远考虑, 那当我没说.

技术学习

一般来说, 技术文档可以分为三类: Tutorial, User Guide和Reference

• 首先应该看的是Tutorial, 一般是step-by-step的教你做一个基本的demo出来.
• 然后应该看的是User Guide, 一般是介绍整体功能结构以及常见场景的解决方案.
• 最后是Reference, 基本上就是事无巨细的罗列所有功能了.

一般来说, Tutorial用来快速上手, 深入学习需要User Guide看一遍, Reference那就纯粹是查漏补缺了, 需要的时候翻一翻就行.

我个人的学习路线基本上是:

• 首先通过step-by-step的Tutorial快速构建出一个demo, 了解其基本写法
• 然后根据User Guide, 在demo上进行魔改以完成我所想的功能
• 如果遇到一些奇葩问题, 可以去stackoverflow上看看有没有解答
• 如果没有, 可能就需要去怼源码了→_→

学习Tutorial的时候可能很重要的一点是, 不仅仅是照着做, 更要想清楚为什么要这么做, 每一行都有什么用, 我能不能不这么写, 有没有别的写法.

技术总结

纸上得来终觉浅，绝知此事要躬行

在使用技术的过程中, 更要去思考和总结, 还是上面提到的几个问题:

• 横向比较: 它与其他同类框架相比有什么特点?
• 纵向比较: 这个框架它解决了什么问题? 又带来了什么问题?
• 最后: 基于以上问题, 该框架适用于什么场合?

这是软件工程层面的, 从纯技术层面上, 在使用过程中会逐渐对其机制逐渐了解, 那么能不能从机制反推出框架内部的实现原理?

• 如果实现一个功能类似的框架, 会怎么设计?
• 框架现有的一些坑, 如果重新设计的话, 会怎么去设计?

带着以上问题再去学习源码, 必然是事半功倍, 你会了解到:

• 框架的设计和你的设计有什么不同, 侧重点分别在什么地方?
• 为什么框架会有这些坑? 也许是没想到, 那么你可以提交PR, 也许只是一种折衷和妥协, 那么为什么要这么妥协?
• 如果你发现你的理念和现有框架的理念完全不同, 在某一方面又有突出优势, 那么说不定你就可以开个新的框架了呢233

技术本身不是重点, 重点是技术背后的思想和设计理念.

就好比挖沙子, 到底用铁铲挖还是挖掘机挖其实取决于你到底要挖多少沙子(不同场景). 挖基坑可以用挖土机, 那挖古墓还用挖土机? 而且会用铁铲挖了再去学怎么用挖掘机挖很难吗? 毕竟造挖掘机的人也是从用铲子挖开始的.
更重要的是, 怎么从挖掘机联想到推土机, 甚至是如何去自动化整个造房子的过程.