我觉得任何技术都可以从这么几个角度去考虑:
技术选型
- 这个框架它解决了什么旧的问题? 又带来了什么新的问题?
- 它与其他同类技术相比有什么特点? 其侧重点在什么地方?
- 基于以上问题, 该框架适用于什么场合?
软件工程的一个基本原则就是没有银弹, 任何技术都有其适用的场合, 在学习一个技术之前先想清楚为什么要学它.
比如说, 微服务的两大主要优点是 分布式部署 和 代码解耦, 但问题是如果你的项目量级根本没有大到需要分布式部署, 而且业务的复杂程度也没有大到耦合度很高, 那么到底是为什么需要它呢? 不要忘记了, 一项技术会有优点的同时那么必然也会有缺点以及其带来的问题.
优点没有享受到, 反倒是被缺点坑到吐血, 那就是本末倒置了.
当然你说是做技术储备, 从长远考虑, 那当我没说.
技术学习
一般来说, 技术文档可以分为三类: 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
技术本身不是重点, 重点是技术背后的思想和设计理念.
就好比挖沙子, 到底用铁铲挖还是挖掘机挖其实取决于你到底要挖多少沙子(不同场景). 挖基坑可以用挖土机, 那挖古墓还用挖土机? 而且会用铁铲挖了再去学怎么用挖掘机挖很难吗? 毕竟造挖掘机的人也是从用铲子挖开始的.
更重要的是, 怎么从挖掘机联想到推土机, 甚至是如何去自动化整个造房子的过程.