讀技術性文本的技巧

 

難於理解的技術文本，之因此難，在於文本自己，以及閱讀者的閱讀方式。

 

咱們能夠先想一下咱們感到難的時候，是什麼樣的狀態。

　　從文獻的角度講：

　　好比，讀到一份日誌文本，這個日誌是咱們第一次碰到的。這個文本有什麼特徵呢？

　　大量的之前沒有碰見過的信息。像這樣：

　　

　　再好比，咱們閱讀一份科技文獻。就讓咱們以前沒有在這個領域作過深刻研究，後果就是滿篇都是新概念——大量的之前沒有碰見過的信息。

 

　　大量的之前沒有碰見過的信息是一份文本難於理解的緣由之一。

　　除此以外，從細節上講，還有其餘緣由：

　　　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已經被剖離出來了。並且很容易理解。這就是我想要講的分層的意思。

　　 關鍵詞：有不少時候，咱們學一個知識，每每學的是這個知識包含的關鍵詞。作到儘可能不去忽視那些「剛認識」的關鍵詞（特別是在看日誌的時候），加上對關鍵詞的檢討和分層閱讀，就能夠很快創建一個閱讀的脈絡了。

　　

　　還有一個問題，如何把握精讀和泛讀的度呢？

　　對關鍵詞進行分層。越是底層和抽象概念的東西越要優先掌握，而後看你打算花多少時間了。