自從建立了?TopLanguage?以來，發現在上面待的時間越來越多，與高手討論問題是個粘性十足的事情，一方面，分享自己的認識是整理不成熟的想法的極好途徑，另一方面，互相之間視角不同，所以往往自己忽視的地方會被別人發現。在討論中不斷精化既有的知識體系。以下這段基本上摘抄自（略有整理和添加）在 TopLanguage 上的發言：

抓住不變量

我喜歡把知識分為essential的和non-essential的。對于前者采取提前深入掌握牢靠的辦法，對于后者采取待用到的時刻RTM (Read the manual)方法（用本）。

如何區分essential和non-essential的知識想必絕大多數時候大家心里都有數，我舉幾個例子：對程序員來說，硬件體系結構是essential的，操作系統的一些重要的實現機制是essential的，主流編程范式（OO、FP）是為了滿足什么需求出現的（出現是為了解決什么問題），是怎么解決的，自身又引入了哪些新的問題，從而適用哪些場景）。這些我認為都是essential的。我想補充一點的是，并不是說硬件體系結構就要了解到邏輯門、晶體管層面才行（其實要了解到這個層面代價也很小，一兩本好書就行了），也并不是說就要通讀《Computer Architecture: Quantitative Approach》才行。而是關鍵要了解那些重要的思想（很長時間不變的東西），而不是很細的技術細節（易變的東西）。《Computer Systems: A Programmer’s Perspective》就是為此目的，針對程序員的需求總結出那些essential knowledge的好書。

再來說一下為什么需要預先牢靠掌握這些essential的知識：

根據Joel Spolsky同學的說法（原文），編程語言技術是對底層設備的封裝，然而封裝總是會出現漏洞的，于是程序員被迫下到“下水道”當中去解決問題，一旦往下走，漂亮的OO、N層抽象就不復存在了，這時候不具備堅硬的底層知識就會無法解決問題。簡而言之就是這些底層知識會無可避免的需要用到，既然肯定會被用到那還是預先掌握的好，否則一來用到的時候再查是來不及的，因為essential的知識也往往正是那些需要較長時間消化掌握的東西，不像Ruby的mixin或closure這種翻一下manual就能掌握的東西。（英語也是這樣的essential knowledge——上次在PyCN上看到一個招Python開發人員的帖子將英語列為必備技能，卻并不將自然語言處理列為必備技能，正是因為英語不是可以臨陣磨槍的東西，而且作為知識的主要載體，任何時候都少不了它，如果不具備英語能力，這個就會成為個人知識結構的短板或瓶頸，而且由于需要長時間才能獲得這項能力，所以這個瓶頸將持續很長時間存在。我們曾經在 TopLanguage 上討論過如何花最少的時間掌握英語）另一方面，在問題解決當中，如果不具備必要的知識，是根本無從思考的，再好的分析能力也并不是每個問題都能分析出該用哪些知識然后再去查手冊的，很多時候是在工具和問題之間比較，聯想，試探性的拼湊來解決問題；這就使得一個好的既有知識基變得至關重要。（實際上以上這個是一個較大的話題，希望有一天我能夠把它詳細展開說清:)）

如果你不知道某個工具的存在，遇到問題的時候是很難想到需要使用這么樣一個工具的，essential knowldge就是使用最為廣泛的工具，編程當中遇到某些問題之后，如果缺乏底層知識，你甚至都不知道需要去補充哪些底層知識才能解決這個問題。

你必須首先熟悉你的工具，才能有效地使用它（須知工具的強是無敵的，但這一切得以“了解你的工具”為前提，甚至得以“了解目前可能有哪些工具適合你的問題”為前提）。一門語言，你必須了解它的適用場景，不適用場景（比如繼承能解決你的問題不代表繼承就是解決你的問題的最適合的方案，須知問題是一個復雜系統，解決方案總是常常引入新的問題）。你必須了解它支持的主要編程范式，此外你還必須了解它的traps和pitfalls（缺陷和陷阱，如果不知道陷阱的存在，掉進去也不知道怎么掉的。）這些都是essential knowledge，如果不事先掌握，指望用的時候查manual，是很浪費時間的，而且正如第2點所說，正因為你不知道這些知識（如適用場景），從而用sub-optimal的方式使用了一門語言自己可能還不知道（最小白的例子是，如果你不知道語言支持foreach，那么可能每次都要寫一個冗長的循環，較常見的例子是不知道有很方便的庫設施可以解決手頭的問題所以傻乎乎的自己寫了一堆代碼），因為人的評價標準常常是：只要解決了最醒目的問題并且引入的新問題尚能忍受，就行。注意，熟悉并非指熟悉所有細節，而是那些重要的，或者無法在需要用到的時候按需查找的知識。比如上面提到的：適用場景不適用場景，編程范式，主要語言特性，缺陷和陷阱。

當然，以上作為程序員的essential knowledge列表并不完備，關鍵是自己在學習新知識的時候帶著第三只眼來敏銳地判斷這個知識是否是不變量，或不易變的量，是否完全可以在用的時候查手冊即可，還是需要提前掌握（一些判斷方法在上文也有所提及）。并且學會在紛繁的知識中抽象出那些重要的，本質的，不變的東西。我在之前的part里面也提到我在學習新知識的時候常常問自己三個問題：該知識的（體系或層次）結構是什么、本質是什么、第一原則是什么。

另外還有一些我認為是essential knowledge的例子：分析問題解決問題的思維方法（這個東西很難讀一兩本書就掌握，需要很長時間的鍛煉和反思）、判斷與決策的方法（生活中需要進行判斷與決策的地方遠遠多于我們的想象），波普爾曾經說過：All Life is Problem-Solving。而判斷與決策又是其中最常見的一類Problem Solving。盡管生活中面臨重大決策的時候并不多，但另一方面我們時時刻刻都在進行最重大的決策：如：決定自己的日常時間到底投入到什么地方去。如：你能想象有人寧可天天花時間剪報紙上的優惠券，卻對于房價的1%的優惠無動于衷嗎？（《別做正常的傻瓜》、《Predictably Irrational》）如：你知道為什么當手頭股票的股價不可抑止地滑向深淵時我們卻一邊揪著頭發一邊愣是不肯撤出嗎？（是的，我們適應遠古時代的心理機制根本不適應金融市場。）糟糕的判斷與決策令我們的生活變得糟糕，這還不是最關鍵的，最關鍵的是我們從來不會去質疑自己的判斷，而是總是能“找到”其他為自己辯護的理由（《錯不在我（Mistakes were made, but not by me）》）又，現在是一個信息泛濫的時代，于是另一個問題也出現：如何在海洋中有效篩選好的信息，以及避免被不好的信息左右我們的大腦（Critical Thinking）關于以上提到的幾點我在豆瓣上有一個專門的豆列（“學會思考”），希望有一天我能夠積累出足夠多的認識對這個主題展開一些詳細介紹。

最后分享一個學習小Tip：

學習一個小領域的時候，時時把“最終能夠寫出一篇漂亮的Survey”放在大腦中提醒自己，就能有助于在閱讀和實踐的時候有意無意地整理知識的結構、本質和重點，經過整理之后的知識理解更深刻，更不容易忘記，更容易被提取。

楊軍在 TopLanguage 上也曾分享了三篇非常棒的學習心得的文章，字字珠璣：

[1]?有些事情做起來比想象中容易?
[2]?有關讀書方法的一點想法?
[3]?一件事情如果你沒有說清楚，十有八九不能做好

from:?http://mindhacks.cn/2008/12/05/learning-habits-part4/

總結

以上是生活随笔為你收集整理的一直以来伴随我的一些学习习惯(四)：知识结构的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。