难于理解的技术文本，之所以难，在于文本本身，以及阅读者的阅读方式。
我们可以先想一下我们感到难的时候，是什么样的状态。
从文献的角度讲：
比如，读到一份日志文本，这个日志是我们第一次碰到的。这个文本有什么特征呢？
大量的以前没有遇见过的信息。像这样：
再比如，我们阅读一份科技文献。就让我们之前没有在这个领域做过深入研究，后果就是满篇都是新概念——大量的以前没有遇见过的信息。
大量的以前没有遇见过的信息是一份文本难于理解的原因之一。
除此之外，从细节上讲，还有其他原因：
1.模型的复杂程度。也就是说，如果是一个很复杂的模型，那么理解起来困难也是很正常的。比如我第一次接触reactor设计模式的时候，也是读了差不多3到5遍才弄清楚reactor设计模式是怎么个意思的。
2.文本的表述水平。有很多文本本身表述的时候会把不同层面的知识混杂在一起。比如我在阅读《hadoop权威指南》的时候，时常一不注意就陷入一个不知道自己在读什么的状态。因为这本书总是喜欢把模型（也就是抽象的东西）和具体的实现细节混在一起讲，假如我不注意将模型从细节里面剖开，就会陷入不知道自己在读什么的状态。
3.文献章节之间的组织结构。不管是从基础开始到高阶知识，还是从结论开始往底层构建逐步推导，一个很重要的原则是循序渐进。这一层很容易理解。而且大部分的较正式的文献都可以做到这一点，因为这一点写作的人都知道。
从读者的角度讲
读者在不同的情况下往往会用不同的方式去阅读。
比如自己有充足的时间的时候，很可能会过分关注细节；而当自己时间比较紧张的时候，就会懒得理会那些细节，想要直接得出最终结果。
我对阅读的理解是：反省、分层与关键词。
反省：给自己提问。每当读到一个关键词的时候，提一个或几个简单的问题：这个东西提出来的目的是什么？怎么达到目的的？假如我想要对所学的东西有一个更加深入的理解，可以问这样一个问题：假如我来设计这个东西，我怎么做？
分层：抽离出不同层面的知识。对于一个模型，我们要深入理解其内在知识，可以考虑暂时无视那些细节。举个例子，在第一次阅读MapReduce框架下的shuffle过程的时候，我当时陷入了细节的泥沼里面：因为hadoop本身是一个综合性很强的系统，从操作系统细节，当算法、数据结构知识，都有涉及，再加上mapreduce本身的工作流程特点，可以想见shuffle是一个比较复杂的过程。我当时并没有刻意去将shuffle过程抽离出来。最近有人问我：你知道shuffle怎么回事么？我不知道说什么好，因为我真的没有理解这个过程。好了，如果我现在讲，什么是shuffle，我会这么讲：
shuffle分为好几步：
Map1:map=>{partition=>sort=>merge（+combine）=>A1,B1,C1
Map2:map=>{partition=>sort=>merge（+combine）=>A2,B2,C2
Map3:map=>{partition=>sort=>merge（+combine）=>A3,B3,C3
ReduceA:merge(A1+A2+A3)}=>reduce
ReduceB:merge(B1+B2+B3)}=>reduce
ReduceC:merge(C1+C2+C3)}=>reduce
上述过程是一个高度简化了的shuffle过程。但是这也足以表达shuffle所起的作用了。至于数据存在内存还是磁盘，merge的算法，combine要注意的细节等等等等，都属于另一个层面的事情。至少在模型上，shuffle已经被剖离出来了。而且很容易理解。这就是我想要讲的分层的意思。
关键词：有很多时候，我们学一个知识，往往学的是这个知识包含的关键词。做到尽量不去忽视那些“刚认识”的关键词（特别是在看日志的时候），加上对关键词的反省和分层阅读，就可以很快建立一个阅读的脉络了。
还有一个问题，如何把握精读和泛读的度呢？
对关键词进行分层。越是底层和抽象概念的东西越要优先掌握，然后看你打算花多少时间了。