自己总结的办法，并靠它去了不错的厂子。只要你本身不是很菜，用此法三个月足够学好多个技术，而且是真学会、可以拿出来用的那种。
需要注意的是，此方法对于大部分技术都很有效（比如java，spring，Redis、网络、操作系统等等），但对于算法、数据结构、设计模式这种需要慢慢积累基本功的不太有效。
具体操作步骤：
1. 初步整理成思维导图
去网上找一个有深度的面试题列表，比如阿里系的。然后逐一尝试回答，不会的就查资料，边回答边整理成思维导图。
思维导图不需要太细致，也没有固定的格式，你自己看着舒服就好。
2. 完善思维导图
解答完全部的面试题后，对于这个技术你会得到一个大体的思维导图。然后继续刷更多新题来查缺补漏，思维导图就会比较完整了。
3. 不断的复述和巩固知识点
有了思维导图之后，就不断在大脑中复述导图中的内容。
一定要用具体的语言把知识点表达出来，就像教别人一样，默念即可。这一步比较重要，学名叫小黄鸭学习法，用具体的语言表述知识点才会知道自己有哪些模棱两可的地方。
这样几次之后就会形成稳固的“晶体记忆”（不用百度了，是我自己发明的词汇）。
4. 加深技术的厚度
每次回忆时，深入挖掘还不太懂的部分，尝试理解底层原理，更新到思维导图上，这样对于该技术的理解就会慢慢变深厚。
这一步也很重要，一直停留在表层技术并不能帮你拿到一个好的offer。
5. 出去装X吧
等你对思维导图了然于胸，并且有了一定深度之后，就去面试吧，很大可能会把面试官忽悠住，以为你是个隐藏王者。我靠这个方法硬生生把Redis从零学到了源码级，蚂蚁金服的面试官都被我忽悠瘸了。
晶体记忆是个什么鬼？我的感觉就是一个知识体系已经被大脑完全吸收并且压缩成一个结晶。处于这种状态时你会觉得这个知识体系就那么大一点，但你真的去扩展回忆时，会发现里面的内容真特么多，而且都是已掌握的。
Update 1：此方法不一定适合所有人
打铁还需自身硬，用这种速成方法首先你得有不错的基础，否则在研究面试题解法这一步你就坚持不下来，因为看不懂原理。靠死记硬背永远都过不了面试。
保留好这些知识图谱，它们都是你的财富。找到工作后也最好每天抽一个分支出来复习，在深冬冰封之际，我等食物链底层的码农要时刻保持武器的锋利，自己足够强悍才能抵御风险。
此方法具有普适性，我正在用这个方法学习金融知识，效果还不错。
Update 2: 关于小黄鸭学习法
在第三步中，我们需要复述思维导图的内容，以达到透彻理解的目的，这其实就是小黄鸭学习法。
简而言之就是把知识讲解给别人，比如一只玩具小黄鸭。。。检验自己是否完全理解一个知识的最好方式就是教会一只小黄鸭。
这个方法是有神经学依据的。据我所知，人脑非常善于为不合理的事情找一个合理的解释，也就是所谓的脑补。
具体研究过程可以去看一些裂脑人的实验记录，当右脑出现负面情绪时，左脑并不知道发生了什么（因为左右脑的信息交换通道被切断），但最终左脑会脑补出一个“合理”的解释，并相信那就是事实，然而这个解释实际上是错误的。
因此当你学会了一个知识点之后，你的大脑会产生“朕已完全学会”这样的假象。
然而当你尝试给别人讲解该知识点时，就会发现其实还有很多解释不通的地方，这种情况基本上100%会出现。
另外，在编程实践中，用这种方法可以快速排查故障，快速弄懂复杂的代码等等。
打个比方，如果你看不懂一段代码背后的业务逻辑或实现细节，那么可以试着用几句话来精确描述这段代码的功能和实现手段。如果能做到这一点，说明你已经懂了。
不要以为这是多此一举，人脑不可能在任何时候都保持清醒。在实际开发中，我们的大脑并不会用自然语言来处理代码，而是直接进行逻辑和抽象思维。这就产生了很多脑补，你对代码的理解很有可能是错误的，想必很多人都经常遇到。
这个方法看起来有点蠢，实际上非常有用。
Update 3: 关于结构化思维
玩知乎快6年，好不容易有了个千赞的答案，就再说点干货。
之前我们使用了结构化思维的一些手段（思维导图），但这仅仅是冰山一角。对于程序员来说，具备良好的结构化思维习惯会显著提高生产力，它的作用比小黄鸭学习法还要大，我已经在自己身上验证过多次。
大家可以自行在知乎搜索“结构化思维”来进行深入学习，有很多优秀的答案。接下来我只说说自己常用的几种思维方式以及在编程中的实施。
5W1H法
这个方***的人比较多，这里主要介绍一下在编程实践中怎么进行5W1H分析。遇到一个问题或需求，按照以下步骤分析：
- 写一个列表，每一项分别为What, Why, Where, When, Who, How
- What：简短的用几句话精准的描述出问题的内核是什么，需求的本质是什么。这是总体纲领，确保你在后续的工作中不会走偏。
- Why：用一两句话描述为什么要做这件事。这可以确保你做的事情有意义，并且目标是正确的。
- Where：在空间维度上静态的分析问题。宏观上，问题涉及到哪些组件；微观上，该问题涉及到哪些关键的类、方法、配置等等。原则上你可以把任何与空间有关的因素都扔进这个篮子里，分析的越全面越好。
- When：在时间维度上动态的分析问题。宏观上，组件之间怎么互相通讯；微观上，上述的代码何时被触发等等。原则上你可以把任何与时间有关的因素都扔进这个篮子，同样分析的越全面越好。Where和when常常会有重叠的因素，这个不要紧，随便你放哪里都行。
- Who：在人物关系这个维度上分析问题。一般这一步比较直观，列举出问题涉及到的人、人与人之间的关系以及每个人的职责即可。这样你遇到事情就能够找到正确的人。
- How：用一个列表来描述怎么完成这件事。这一步其实是一个总结，把前面五个维度的因素综合到一起，来找出一个优质省力的解决方案，然后按照解决方案来实施即可。
5W1H思维法最大的好处就是强制你去进行多个维度的全面思考。就像我之前说的，我们的大脑很喜欢脑补，如果不能明确的一条一条去分析，我们的大脑就会进行各种跳跃性的思维，最终遗漏了很多因素。在稍微复杂的项目里，你可能连需求的内核是什么都弄不清楚，别问我是怎么知道的。
链路法
我自己总结的一个方法，对程序进行线性的因果分析。无论是单线程、多线程还是复杂的系统，用静态眼光来看，程序都是线性的，这是此方法的依据。具体步骤：
- 组成链路
遇到一个问题或需求时，先用5W1H法进行多维度分析，再把Where篮子里的因素按照When因素来粗略排序，一个一个链接起来。如果你对自己的工作足够了解，这一步应该会比较快。
2. 分析链路
按照你遇到问题的类型来进行不同的分析：
- 如果遇到的是一个故障排查问题，那么仔细观察链路的每个节点，根据问题上下文，从最有可能出问题的几个节点开始验证和推断，缩小问题半径，直到找出问题所在。其实很多人进行故障排查时都在这么做。
- 如果遇到的是一个改祖传屎山的需求，那么进行链路分析时就需要寻找代码中的太极节点。所谓太极点，就是能够以小博大的关键部位。我们都知道祖传代码改的越多越容易出毛病，为了安全着想，我们一定要尽量控制修改范围。找到这些太极点，就可以在少量的改动下，完成需求。
- 如果遇到的是一个测试的需求，那么可以对链路中的每个节点进行扩展分析，列举出每个节点可能出现的边界条件、异常情况等等，再写测试用例来覆盖到这些节点。
链路法最大的好处就是让你不再依靠直觉去做事，在各个阶段都知道自己在做什么。有时候直觉很重要，尤其是故障排查时，但如果你只依靠直觉，那么肯定会遗漏掉很多有用的信息。如果你只依靠直觉去改代码，那么最终结果大概率不是最优解，无形中会增加很多测试和验证成本。
其他方法
STAR法：此方法常常用来向别人描述某一个具体的事情或问题。在沟通中用的比较多，但在具体编程中用的不多所以请自行搜索。
金字塔法：这个方法比较普遍。但说实话，这个方法掌握起来并不容易，我主要用它来汇报工作。
PK法：当你对于决策踌躇不定时（比如技术选型），可以找一张纸，列举出几个方案的所有优缺点，优点和优点PK，缺点和缺点PK，最后你会得到答案。
京公网安备 11010502036488号