其实之前自己有一套自认为不错的学习方法，这在我之前的【年终总结系列 2021】不变的心态应对变化的环境年终总结中也有提到，大概是这样的：
看到Gap制定学习目标–》合理评估执行方案和周期–》达成目标并获取成就感–》复盘并打磨更科学合理的反馈环，通过这个正反馈环，可以源源不断的看到Gap，汲取知识，填平Gap。通过Step By Step的模式感受到自己真实的变化，越来越自信的应对问题和挑战。这套正循环可以让我在新的环境面对新的问题时不再惧怕，而是用体系化的方式解决，直到新问题处理后后再寻求更高的新目标，新目标达成后有了成就感就会更愿意去学习知识
当然这套是自己摸索出来的一个模糊的实现方式，但是其实并不是一套标准的方法论，直到最近在学习华仔写的一门课程：《大厂晋升指南》才发现，原来有成体系的标准学习的方法论，我自己的这套倒是可以套用其中一些，但他的这套理论更全更专业，所以做了一些学习笔记来记录下。首先围绕四个我们常见的问题展开：
- 时间从哪里来？如果没有足够的时间投入，再好的理论也只是纸上谈兵。WHEN
- 学什么？找到正确的学习方向，明确了学习的目标，才能做到有的放矢。WHAT
- 怎么学？不同的学习目的应该有不同的学习方法，保证学习的投入产出比。HOW
- 怎么保证学习效果？如何解决“学了用不上，学了就忘”两个常见影响学习效果的问题。HOW
整体围绕如何解决这四个问题，重点内容我罗列到了如下的思维导图中
当然有一些我认为比较重要的内容这里再详细的解释一下，
找时间
找时间的问题很好解决，一天至少2h，早1h，晚1h。
学什么
其实接下来就是要解决学什么，当前我的博客知识技能树大概是如下这些，其实也大概对标了COMD模型，对于下一级别的要求主要是补足架构设计上的欠缺
目前集中精力在【设计模式】上也是这个目的，持续到年底，要把设计模式学习完。
怎么学
分为链式学习法，比较学习法和环式学习法
链式学习法
三个步骤：分层，确定学到哪一层
1 领域及细节分层
首先是分层，第一种是自顶向下、层层关联，打通一项技术的领域分层，以 Netty 网络编程为例，相关领域一共可以分为 6 层，要么上层依赖下层，比如 Netty 依赖 Java 网络编程，Java 网络编程在 Linux 上又依赖 Linux 提供的网络编程接口；要么下层是上层的应用和实现，比如 TCP/IP 是原理，而 Linux 网络调优和工具是 TCP/IP 的具体应用
第二种是由表及里、层层深入，打通一项技术的细节分层，同样以 Netty 网络编程为例，技术细节可以分为 4 层，它的细节分层图如下所示
2 确定学到哪一层
学得太浅，达不到提升深度的目的；学得太深，又会耗费太多的时间和精力。以 Netty 网络编程为例，领域分层图的 6 层不用都学，大部分人学个 3～5 层就够了；不过细节分层图的 4 层，建议每一层都学
3 明确每一层怎么学
在领域分层图中，越往上越偏应用，实际工作中用得越多，越往下越偏原理（包括相关的工具和配置），实际工作中用得越少。所以总的原则是，在上层投入更多时间，更关注细节和熟练使用，在下层投入相对少的时间，更加关注原理和简单应用都学。实际使用时要看使用的深度
在细节分层图中，需要详细地学习每一层。要注意的是，对于实现源码这一层，不需要去掌握每一行源码，只要掌握关键源码就行了，也就是和设计原理以及设计方案相关的源码。
比较学习法
所谓比较学习法，就是横向比较同一个领域中类似的技术，梳理它们异同，分析它们各自的优缺点和适用场景。比较学习法的具体操作步骤如下：
- 先用链式学习法掌握某个领域的一项技术，将这个领域的关键技术点整理成表格。
- 基于整理好的技术点，学习这个领域的另一项技术，将它们在技术点上的差异整理成思维导图。
- 找出差异较大的技术点，将背后的原理和对应用场景的影响整理成表格。
以缓存领域的 Memcache 和 Redis 为例
- 1 先用链式学习法掌握 Memcache 技术，整理出缓存领域的 6 个关键技术点
- 2 基于这 6 点快速掌握 Redis 技术，整理出 Memcache 和 Redis 在这些点上的差异。
- 3 找出差异较大的技术点，包括并发方案、数据结构、高可用和持久化，整理出它们背后的原理和对应用场景的影响
我认为比较学习法最大的优势就是：同一个领域的技术在功能上大都是类似的，区别往往在于实现方案和细节。所以当掌握了一项技术之后，再去同一个领域的另一项技术，就不需要从 0 开始了，因为基础的部分已经学会了，只要重点关注它们的差异点就能够快速掌握，而且这样还能对两个技术的差异和应用场景有深刻的认知
环式学习法
所谓环式学习法，就是构建一个完整的闭环过程，将多个领域的“鱼”一网打尽。技术上常见的闭环是功能环，代表某个功能的处理过程以一个最简单的“用户登录”为例，如果它的实现方式是前端在手机 App 上用做登录页面，后端用了微服务架构来存储，
- 1 那么就可以构建这样一个功能环：
- 2 构建完成之后就能依据节点涉及的技术点逐个攻克了
由环式学习法引起的思考：懂业务很重要。很多技术人员有一个误区，认为业务设计是产品经理的事情，产品经理设计好了，技术人员再把自己负责那部分做好就行了。这种想法会让你在工作中非常被动，而且可能吃大亏。常见的吃亏场景包括：
- 讨论需求的时候，因为不懂业务，就算产品的业务需求不合理、实现代价很高，你也发现不了。结果到了设计甚至是编码阶段，你才发现自己做得累死累活，效果还不好。
- 处理线上故障的时候，因为不熟悉业务，只能被动接受别人的分析和推断，很容易背锅。
- 因为不熟悉业务，无法承担整体需求分析和方案设计这种任务，导致个人能力得不到锻炼，失去很多晋升机会。
熟悉业务很重要，要多听需求评审，看PRD，及时和自己相关度不大也要关注，这样才能建立全局视野
高效学
play学习法说白了就是通过自己搭建虚拟环境学习，这种方法我已经用过很多次了，例如学习中间件的时候，搭建虚拟机集群，并在此之上构建Redis集群、ES集群、Kafka集群等，学习Java Web的各类知识的时候也是通过做一些小的Demo，实践出真知，印象也最为深刻。
teach教学法我也一直使用，例如现在秉持着学习必有博客输出，来实现通过write的方式让记忆更深刻，有一点我深表赞同：
当我们看别人写的内容时，我们采取的方式其实是“read”，能吸收的可能只有 30～50%，而自己写出来的话，即使内容是类似的，也能够让自己对技术的掌握程度达到 60～70%
就拿我当前这篇Blog为例，内容相似度和极客时间原文很高，但是自己画了思维导图，弱化了自己理解很深并且已经在做的内容，强化自己做的不好的内容，那么这样一篇学习笔记就是我专属定制的学习笔记了，掌握程度当然就大幅提升了。
当然写作比较占时间，学习了一遍再写一遍当然会浪费时间，所以核心的指导原则就是，看技术和自己工作的相关度，对于强相关的核心技术，自己写文章来学；而对于弱相关的非核心技术，可以通过阅读资料来学习，我目前的学习基本强相关的学习，所以才会篇篇都落Blog.
总结一下
其实自己一直有一种朦胧的学习方法论，但是并不成体系，例如我也会拆目标，大体拆的方式也类似，也会有写博客的teach学习法的习惯，边写边做的play学习法的习惯。但这些都是零散的，不成体系的，而学习完后就能有成体系的学习方法论，收获最大的就是HOW【怎么学】，之前的学习笔记专栏较为盲目，就是按照概述-应用-原理-实践这样的思路去学习，虽然大致有节奏但不全面。现在有了一个解决连环call的链式学习法，解决技术选型call的比较学习法，以及培养全局视野的环式学习法 这样一套组合拳，可以更有的放矢的学习新技术了。还有一个重要收获就是一定要懂业务，以前虽然较为主动，但也并未把业务看的那么重要，实际上要想不一直仅仅当码农，懂业务是第一步。
