by 楊軍前端
原文地址:
有關讀書求知的一些想法
一件事情,若是你不能說清楚,十有八九你就作很差
有些事情,作起來要比想象中的容易編程
出於勉勵本身和分享優秀的心得體會的緣由,在此彙總記錄。若有侵權,我會馬上刪除。數據結構
在求知的過程當中,咱們常常會要面對這樣,那樣的誘惑。編程語言
以讀書爲例,一部經典的好教材,想要把它讀通,搞明白,弄紮實,除了在讀的過程當中理解做者想要描述的字面意思之外,每每還須要經過做大量的相關習題及實驗來創建起更爲紮實,深入的認識,而捧着厚厚的一本書,人類心理潛在的佔有本能又每每會驅使着本身以最快的速度將這部教材拿下,知足本身的成就感,因而在沒有外人監督,沒有外力監控的狀況下,很容易演變爲一開始的時候讀書,作題皆顧,隨着時間的推移,本身開始不能抗拒快速讀完書本的誘惑,因而作題的頻率愈來愈低,最終在快速攻克目標的指導原則下,書讀完了,習題卻沒有作幾道。在讀的過程當中,在每一個閱讀的局部階段,對做者想要傳遞的意思彷佛都搞明白了,但真的把書本一合,要求你對某一小節,某一大章,乃至全書作一個總結性的回顧,每每就以爲不少想法,不少話,彷佛就在嘴邊,就在腦子裏,卻就是不能以流暢的方式表達而出。真要讓你用書上講述的知識解決一些實際問題,卻每每感受無從下手。究其根源,實際上仍是學習過程作得還不夠紮實。學習
在咱們的閱讀範疇中,有不少圖書,是不值得精讀的,特別是資訊性質的圖書,資料,(尤以互聯網上的信息爲甚),製做這些信息源的做者,出於快速傳播其信息的須要,每每會在製做過程當中對資訊進行適當的處理,以下降受衆理解消化的門坎。對於這類資訊,在閱讀它們的過程當中,可以增長咱們的見識,卻不能增進咱們的理解力,由於在開始閱讀以前,咱們的理解力就已經與這些資訊的製做者至關了。(資訊的源製做人在其專業的領域固然有着超出常人的理解力,但在他製做資訊的過程當中,已經試圖經過各類手段,下降理解資訊所需的理解力了,不然,閱讀一份資訊類的報紙還須要一個普通人通過一兩天的思考才能完成的話,這些資訊製做機構也就早早關門大吉了)。google
而一本經典的好教材,其定位與資訊類讀物則大不同了,通俗來講,讀資訊類讀物,是爲了知道發生了什麼,而讀經典的教材類讀物,則是爲了知道在發生的事情背後蘊藏的機理。再換句話說,經典教材的目的是爲了提高人的理解力,而資訊類讀物,則是爲了讓人長見識。設計
想要經過讀經典教材的過程來提高本身的理解力,就比如要經過讀書的過程,將做者身上所具有的,而在讀以前本身身上還未具有的某些能力,特質,吸取過來。不一樣的知識背景,不一樣的知識結構,不一樣的知識基礎,甚至不一樣的文化背景都註定了要想讓本身經過讀一本書得到跟做者在這本書所述及的內容上相近的理解力,不會是件容易的事情。大量的思考,習題,實驗,乃至於查找相關資料辨僞存真,相互印證,都是重要的手段。一本好的教材,也許只有500頁,但爲了將其讀通,讀透,進而提高本身在這本書所述範疇的理解力,你須要作的習題,須要查的資料,須要寫的筆記和讀書報告,可能會遠大於這個頁數。若是在讀這類書的過程當中,只是知足於在快速閱讀中理解本身目光所觸的書本範圍內容,恐怕,讀完了整本書,你都還未必能體會到做者真正想要傳達內容的十分之一,我的在理解力上的增益也就頗有限了。接口
因此,對於閱讀經典教材,我會試着採用以下的方法:
1。堅持連續的閱讀ip
關鍵是連續,我本人不主張那種"這周看100頁,下週休一週,再過一週再看幾頁"的這種不均勻的閱讀方式,現代社會裏,咱們接觸到的事物,須要處理的事情都是很是繁多的,而個體的處理能力,記憶能力是有限的,因此,若是閱讀一本書的間隙太長,極可能你讀到第150頁的內容時,會發現本身已經淡忘了前面的不少內容,這種淡忘在閱讀過程當中確定在所不免,可是不規律,不連續的閱讀引發的淡忘效果要明顯得多。 一股做氣的策略,在讀書過程當中也適用。內存
2。堅持思考
早就有古人說過"學而不思則罔",長時間的閱讀,卻不去花時間思考why and how? 會讓本身退化爲一個知識存儲機器,達不到提高理解力的效果了。對書本上的東西,若是隻是人云亦云,所掌握的每每浮於表象,只有真正通過本身深刻思考,推敲的,才能更有效的歸入本身的知識體系。
3。堅持作題
曾經有過一段時間,我很排斥做題,以爲作題實在是一種應試教育的弊端,但多年以後,經歷過一些認知,學習上的困境,也走過一些彎路以後,我如今的體會是,作題是一種頗有效的鞏固所學,紮實所學的方式。只不過,傳統的應試教育過度強調做題自己在功利方面的回報,容易激發起人的心理反彈,以至於個體一旦得到自由學習的環境之後,會傾向於排斥這種方式了。
有不少時候,咱們在讀書的過程當中,感受本身已經明白了做者所說的某句話,某個意思了,而實際上卻未必如此。不一樣的背景,不一樣的知識結構,註定了讀者與做者常常會在相同的某個描述上存在理解誤差。做者實際想闡明的意圖是a,他用來闡明意圖a的描述是B,而讀者在讀完描述B之後所創建起來的初始理解則多是c,c與a可能存在交集,也可能不存在交集。不經過作題,僅僅思考,是很難確立本身對做者的主要意圖的理解是否是存在誤差。而經過作題,每每能發現本身在理解上的誤差和盲點,讓本身對描述B的理解更接近於做者想要表達的原始意圖a了。
4。堅持階段性地寫讀書筆記。
我的以爲,階段性地寫讀書筆記,有那麼幾分"跳出畫外看畫"的感受,不停地閱讀,思考,作題,會讓本身一直糾纏於書本,教材的細節,而適時地跳出來,作一個小結,會有助於本身廓清方向,梳理思路,不囿於一書一時,另外一方面,還能起到鞏固所學的目的。至於查找資料,互爲印證,由於如今的精力實在是有限,也跟本身的惰性有關,如今本身讀書的過程當中,作得還很不夠,(我的感受,作學術研究的話,查找資料,互爲印證是必要條件,而僅僅是求知的話,則不那麼緊迫。)可是上面所述的四點,本身在閱讀經典教材類的圖書的過程當中仍是基本在一直堅持的。
最後引用法國學者Pascal曾經說過的一句話做爲此貼的結尾吧:
"讀得太快或太慢,都一無所得。"
記得有一次開會,個人頭兒說了標題所寫的這句話,本身深覺得然。
有過較多解決問題的經歷的人可能會有這樣的感受,不少時候,面對一個問題,咱們即便沒有徹底將之想清楚,也能夠基於已有的經驗給出一個可以work的解決方案,固然這種狀況下給出的方案每每不是最優的。而即便給出瞭解決方案,極可能本身都未必能把本身給出的解決方案所基於的推理邏輯,清晰無誤地闡述出來。由於隨着人的知識,經驗的積累,咱們能夠愈來愈多地依靠經驗來解決一些問題,這些經驗有些是本身身體力行,實踐得來的,有些則是道聽途說,經卷紙傳,從其餘的地方得到的。在得到這些經驗的同時,咱們的大腦會創建起這樣的一個觸發機制:遇到問題A,經驗B會有效。遇到問題C,經驗D會有效...
至於爲何經驗B對問題A會有效,是否是在全部場景下都會有效,是否還存在更有效的解法,大多數狀況下,咱們未必會深刻去思考挖掘。
因而,在遇到了與本身之前經歷過的問題類似,相近的場景時,咱們就會條件反射地基於已有經驗,設計出一個解決方案,大多數狀況下這個方案work得很好。但也有不少狀況下,這個方案雖然能work,但並非最優解,甚至本身都未必能說得清楚爲何給出這樣的方案。
最近在工做中,須要爲語法規則設計相應的數據結構,本身就有了這樣的感受,在作設計的過程當中,有的時候,是舊有經驗做祟,有的時候,則是由於偷懶的情緒佔了上風,本身會知足於淺嘗輒止,對某個問題給出一個未經深思熟慮的解決方案,而隨着設計過程的推動,暴露出來的信息愈來愈多,就會發現已有的設計不能很好地知足一些場景的要求,於是對已有的設計進行調整,可是在調整時,本身每每會發現,對於已經做出的設計,爲何當時本身選擇那樣的接口,定義那樣的數據成員,本身並不能給出清晰明確的解釋,這就說明在作出當時的設計的時候,本身並未將問題想清楚,也未將本身給出的設計想清楚,而是基於一些已有的經驗,給出了一個差強人意的方案而已。
在這方面,個人老大做得要比我好不少,對於一個問題,他每每會將之想得很是清楚以後,纔會去着手去作。之前的技術討論會上,凡是他提出的設想和方案,幾乎不多會有被咱們駁斥倒的,由於只要是他在會議上提出來的東西,幾乎方方面面,各類可能,他都已經去思考過了。而在工做過程當中經驗的積累上,他也常常會做深刻的思考和挖掘。通常來講,凡是他解決過的問題,只要不是太detail的,跟他討論起來,他每每可以對答如流,而可以做到這一點正是由於他在儲備這些經驗的時候已經做足了功夫。而本身在儲備經驗的時候則每每不會花費太多精力。一個典型的場景就是我和老大同時遇到一個問題,有的時候,我能更快地給出答案和解法。可是過了一段時間,又遇到了相似的問題,我卻可能會忘了當時解決問題的思路,須要從新進行思考,而個人老大每每可以直接從他的經驗體系中找出當時的解法思路。遇到一個問題,我每每能較快地給出一個解決方案,但細究起來,我就時有被卡住的場景,而個人老大,雖然給出問題答案須要的時間會較長一些,但通常他給出的答案,每每都經得起推敲。
外人看來,我幹起活來很快,效率蠻高,可是本身心裏才清楚,這種效率是以損失紮實性爲代價的。
記得去年8月份就曾經想本身動手設計一門語言,一開始的想法是先實現一門跟本身的目標語言特徵有類似性的現存語言的編譯器,在實現中積累對語言設計和實現的理解。記得當時選定了Ruby之後,就把C Ruby的源碼下載下來,打印出其語法BNF範式。後來就是一直在研讀Ruby的源碼,零零星星也花了些時間,由於老是感受對C Ruby自己的實現理解的還不夠通透,就一直沒有真正開始本身的實做,在個人想象中,真正動手去實現一門編程語言(僅指實現,不包括設計層面的工做) 並非一件容易的事情,潛在的這種假想就這樣讓本身一直處於儲備階段。
及至到了新公司這邊,本身的第一個任務就是實現一門語言( 已經有相應的IEEE標準)的編譯器。這門語言已經比較成熟,市面上支持它的編譯器不少,也不乏一些開源的實現。本身一開始固然也是下載了語言的IEEE標準和相應的開源實現研讀了一番。不過公司裏的工做不像我的任務那樣,老是在你感受達到一個好整以暇的狀態之後纔開始進行,項目的schedule、release的deadline每每會驅使我的在達到相對準備就緒的狀態之後就須要開始實際工做的推動了(在個人理解中,對於預研型的項目來講,可能還能夠有更多的儲備時間,但對於工程性較強的項目來講,儲備時間每每並不會給很長)。因而在閱讀了語言的BNF描述,並對相應開源實現做了一些研究之後,本身就開始上馬了。
到如今爲止,過去了大概有兩個月時間,回頭看來,本身也基本上實現了這個語言的詞法,語法部分,支持80%的核心語法,能夠成功地讀入該語言的源文件,並生成內存語法樹。如今本身已經開始着手作一些語義層面的事情了,這個進度仍是有些出乎本身意料以外的。在剛着手作這件工做的時候,本身其實還多少是有些忐忑不安的,由於畢竟感受還有太多的東西不徹底處於本身的掌控中,沒有那種充沛的胸有成竹的感受。但真的推動起來,才發現,有不少東西、不少理解,,都是在實際的工做中強化、得到的。
想一想去年的8月份,本身就開始蘊釀設計一門語言,也一直在做儲備工做。過了一年時間,仍是停留在儲備階段,沒有開始多少實質工做。
而真的被工做驅使,卻在不到兩個月的時間就已經大體實現了一門之前本身並不太熟悉的語言的parser前端。這裏面當然有部分緣由是由於近一年來工做的積累讓本身能夠更快速的完成相應工做,但也真切的感覺到一個問題,若是不實際動手作,僅僅是從外面看,每每會被一些表面上的困難阻塞住,產生不可逾越的感受,及至真的動手作了,纔會發現未必然。若是不是在新公司有工做須要,本身可能仍是感受沒有作好自主實現編譯器的積累。雖然本身如今在編譯器設計實現方面仍存在大量的知識薄弱項須要補充,但這並不意味着本身不能夠開始着手做一些實際的工做。 老是期待達到一個完美的積累狀態再去動手實際作,結果可能就是一直陷入積累的狀態不能拔出。