原文出處：http://www.cocoachina.com/programmer/20170612/19490.html （感覺講得很有道理，分享一下）
閱讀技術(shù)文章可以說是我們程序員的日常之一，Peak 君每天也會進(jìn)行定量的閱讀。特寫一篇小文分享下心得，介紹下過去幾年，在糾正閱讀習(xí)慣上所做的一些努力和取得的成果，或許可以幫助一些朋友，節(jié)省少許閱讀時間，提升一點(diǎn)學(xué)習(xí)效率。
差不多兩年前，我開始搭建 Android 相關(guān)的知識體系。最開始的想法是從基礎(chǔ)知識的積累開始，正好這幾年社區(qū)的技術(shù)分享盛行，「掘金」、「開發(fā)者頭條」、「簡書」等渠道上每天都有大量的新文章發(fā)布，文章主題五花八門，內(nèi)容深淺不一，看上去都很不錯?？蓤猿肿x了幾天之后，深感自己踏進(jìn)了錯誤的方向，讀過的比較有代表性的一篇文章是：「關(guān)于 Service 你所需要知道的一切」，文章內(nèi)容的質(zhì)量遠(yuǎn)低于標(biāo)題所勾起的預(yù)期，無非是把官方文檔里的幾個知識點(diǎn)做下摘錄，有些地方反而因為摘錄不全導(dǎo)致邏輯不連貫，順藤摸瓜找到出處之后，發(fā)現(xiàn)官方文檔才是我的救贖。
最初學(xué)習(xí) iOS 的時候，也走過類似的彎路，急于在短時間內(nèi)掌握要點(diǎn)，急于能盡可能快的開始寫代碼，所以略過了看上去冗長繁瑣的官方文檔，轉(zhuǎn)而搜索各類總結(jié)文章以求速成，結(jié)果是所有心存僥幸投機(jī)取巧跳過的知識點(diǎn)，都會在某一天變成一個個費(fèi)時費(fèi)力去填的坑。
對于基礎(chǔ)知識框架的搭建，沒有比官方文檔更好的起點(diǎn)了。當(dāng)然官方文檔太過全面，無法在一開始就通讀一遍。正確的做法是，在計劃深入某一塊知識域之前，先讀一遍與之相關(guān)的官方文檔，如果還有疑惑再去其他渠道搜索相關(guān)知識點(diǎn)，做進(jìn)一步的深入發(fā)掘，這就涉及到下面有關(guān)「精讀」的話題。
從這一角度來說，上面提到的三個渠道，對于基礎(chǔ)知識的積累，閱讀價值并不高，很有可能，整篇讀下來都是些零零碎碎已知的知識點(diǎn)，收效甚微，絕大部分文章都是標(biāo)題驚艷，內(nèi)容單薄。當(dāng)然不排除偶爾會遇到一些高質(zhì)量的深度好文，但這些好文大多是轉(zhuǎn)載的，是有自己的發(fā)布渠道的。按我以往經(jīng)驗觀之，好文是稀缺資源，數(shù)量稀少且發(fā)布渠道穩(wěn)定，比如一些類似 bugly 這樣的大廠對外渠道，國內(nèi)外一些優(yōu)秀的博客寫作者，或者是偶爾在微博上被大量轉(zhuǎn)發(fā)的文章。這些渠道都可以被分門別類的裝進(jìn)瀏覽器的收藏夾，無需每次去「掘金」這類的渠道做大海撈針式的搜索。
閱讀行為一般可以劃分為兩類：泛讀、精讀。技術(shù)類的文章閱讀也不外如是，不同點(diǎn)在于，技術(shù)閱讀應(yīng)該重精讀，輕泛讀。技術(shù)知識的價值能否得以體現(xiàn)，關(guān)鍵在于最后是否在閱讀者的記憶里得以沉淀。泛讀行為很難形成有效且深刻的記憶，但偏偏泛讀較之精讀要輕松很多，所以很多初學(xué)者習(xí)慣性的去做大量的泛讀行為，看標(biāo)題感興趣就點(diǎn)進(jìn)去瀏覽，一天下來能讀好幾篇，最后形成收獲頗豐的錯覺，這其實(shí)是一種潛意識下的偷懶行為。這種閱讀行為中收獲的知識，別說難以在實(shí)際項目中去應(yīng)用，就是在面試中聊聊都是不能。這條彎路 Peak 君也走過。
在精選、形成完自己特有的閱讀渠道之后，我們應(yīng)該調(diào)整自己的閱讀行為，盡量強(qiáng)迫自己去做精讀，去深入挖掘、消化自己認(rèn)可的深度好文。一篇技術(shù)好文，一天能消化干凈算得上奢侈了，有些文章需要陸陸續(xù)續(xù)讀上一個星期也是可能的。精讀一篇文章確實(shí)會比較辛苦，但你想想，寫文章的人更辛苦，不光要理解文中所談的各個知識點(diǎn)，還需要做串聯(lián)歸納以成體系，精讀一篇深度好文就是一次和某個領(lǐng)域的專家做深入交流的機(jī)會，只是草草的瀏覽一遍而錯過一次寶貴的加深知識域的機(jī)會豈不可惜。如果文章主題和當(dāng)前自己的關(guān)注點(diǎn)切合，讀起來越是費(fèi)力的文章，其價值也越高。簡而言之，技術(shù)類文章閱讀，是宜少不宜多，宜靜不宜泛。
相信不少人閱讀技術(shù)文章時，都有過類似的體驗：在文中發(fā)現(xiàn)一個陌生的術(shù)語，轉(zhuǎn)而 google，搜出更多的術(shù)語或者相關(guān)文章，于是切換到新的環(huán)境中去繼續(xù)閱讀行為，有時會如此反復(fù)跳躍幾次，最后瀏覽器上的 tab 越來越多，感覺文章根本讀不完。
這是由于技術(shù)的知識體系往往是個樹形的結(jié)構(gòu)，單個術(shù)語下都有其相關(guān)的知識域，可以一層又一層牽扯出更多的子術(shù)語。在閱讀文章遭遇這種樹形結(jié)構(gòu)的時候，要能抑制住自己不停探索的欲望，對于技術(shù)術(shù)語的學(xué)習(xí)只做適度延伸，最終的目的還是在于完成根部文章的閱讀。Peak 君的閱讀習(xí)慣是只做一到兩層的延伸，比如剛開始學(xué)習(xí) ReactiveCocoa 的時候，接觸到函數(shù)式編程，了解函數(shù)式編程又挖出了 pure function，pure function 又包含若干其他的概念，可以持續(xù)的深入下去，但到 pure function 這一層之后其實(shí)就可以適可而止了，可以回過頭來完成原先的閱讀任務(wù)。
要克制對于知識的求索欲，有時也不容易。現(xiàn)實(shí)是，我們精力有限，無法在每個領(lǐng)域都成為專家，看到優(yōu)質(zhì)深入的分享好文時，很容易產(chǎn)生知識的焦慮感，迫使自己去閱讀并無太大交集的話題，這反而容易造成時間和精力上的浪費(fèi)。不同技術(shù)人員之間，在知識的儲備量上其實(shí)不具備可比性，真正需要在意的是學(xué)習(xí)和解決問題的能力。
再者是對于閱讀時間段的選擇。程序員工作時很容易被打斷，產(chǎn)品，設(shè)計，測試隨時都有可能找上門，做深度閱讀時一旦中斷，閱讀效果會大打折扣。我們應(yīng)該根據(jù)自身的情況，盡量選擇沒人打擾的時間段來做閱讀，可以是早上剛到公司，或者別人午睡時，總之越安靜，越?jīng)]人找越好。
最后一點(diǎn)，可以從慌不擇食的技術(shù)文章閱讀時間里，多摳出一些來，完完整整的閱讀一些大部頭的英文原版技術(shù)書，這才是知識學(xué)習(xí)的正餐，別人寫的零散文章更適合作為飯后甜點(diǎn)。比如 Peak 君經(jīng)常推薦的 【TCP/IP 協(xié)議詳解】，這種經(jīng)典書籍，即使耗費(fèi)一年的時間去閱讀，也遠(yuǎn)遠(yuǎn)強(qiáng)過讀一年別人所寫五花八門的技術(shù)文章。
說了這么多，提煉下摘要：對于基礎(chǔ)知識的閱讀，要重官方文檔，切莫心急動手，看完文檔形成知識體系后再寫代碼不遲。減少泛讀行為，避免漫無目的的隨意瀏覽技術(shù)文章。注重精讀，一天一篇不算少，一周一篇也正常。重閱讀質(zhì)量而非數(shù)量，挑選每天安靜且不易被打斷的時間點(diǎn)來閱讀，盡量多啃原版書。
