既然看得懂代码，那为啥说看不懂书？

最近在看龙书，看书的过程中偶尔会分个神。可分神回来后，发现自己居然看不下去了。但是我很想快速的把书看完，所以我会强迫自己强行的去接着看，去试着看懂每个字的意思。可我滴个乖乖，我看的可是中文书啊，每个字都是汉字，每个字我都见过无数次了，可我心里还是有一万匹草泥马呼啸而过，一边跑一边喊口号：“啥啥啥，这写的都是啥?”

说也巧，我刚好看到的地方讲的是上下文无关的文法。在举反例的时候，就提了下哪些不是上下文无关的文法。比如说，大部分的程序语言，在涉及到先定义后使用的时候，就不是上下文无关的文法了。

“先定义后使用”，这不就是在尝试理解书的内容时所做的事情吗？没做好这个事情，“没定义就使用”，不就是在看天书吗？

我试着对着书套了套，发现还真是这个道理。这种技术类书籍甚至说理科类的教科书，是通过定义一个一个的概念开始的。书本对每个概念解释说明，把概念组合起来，去证明这个组合出来的结果的某个特性，用这个特性去回答某个答案。

首先，看书时先抓住提到的概念。一个都不能放过，不仅要看了，关键要去理解，否则后面就会晕。比如在看书时没用心去理解“闭包”的定义，那么后面在谈及闭包的特性和应用的时候，就会感觉到不知所云。更严重的是，我发现这种问题常常是很隐蔽的，因为我看过定义，但是没理解这个定义，所以我会觉得那个概念很熟悉，熟悉到就像自己知道这个东西是什么一样，但就是不知道它的特性和应用是怎么来的。自己就会去死抠后面的文字的描述，而不会想到回去重看定义。

其次，在概念定义的后面，会跟着一个更加详细的混搭例子的描述。这个描述是概念的补充，是理解概念细节的辅助。比如定义了一个“加法”，在这个描述里面，会更详细的说明在整数、有理数、实数、复数的下面，这个加法的动作是什么。我会选择这部分混搭前面的定义来理解，因为我是在跟书本对话，对于定义里面用文字描述不清楚的，我不能跟作者Q&A，只能选择看这部分来消除心中的疑问。

最后，就是这个概念的使用场景。写程序定义了变量要用，看书提到了概念肯定会说明它存在的意义。在理工类的书籍里面，每个概念定义出来，一定是为了解决某个问题的，而这部分就说明这个概念怎么与这个问题交互，从而去解决它。这部分的篇幅最长，而且一般都图文并茂，这部分往往也是最吸引眼球的地方。因为相对前面的章节，这部分需要思考的东西最少，看起来也就最轻松。然而必须要在完全理解前面描述的情况下，这部分文字才能发挥它最大的作用。否则这部分是最容易脱线的。

总结完成后，每次被打断都试着按照这三条整理思路重建现场，倒也发现有用。我兴奋的将这个发现分享到了技术群，没想到被人泼了冷水。有个人冒出来说了一句，我还没法反驳。因为他的说的是：“看书是不是能看进去，这件事，主要看智商 ╮(╯╰)╭”。