by 杨军
原文地址：
有关读书求知的一些想法
一件事情，如果你不能说清楚，十有八九你就做不好
有些事情,做起来要比想象中的容易
出于勉励自己和分享优秀的心得体会的原因，在此汇总记录。如有侵权，我会立刻删除。
有关读书求知的一些想法
在求知的过程中，我们经常会要面对这样，那样的诱惑。
以读书为例，一部经典的好教材，想要把它读通，搞明白，弄扎实，除了在读的过程中理解作者想要描述的字面意思以外，往往还需要通过作大量的相关习题及实验来建立起更为扎实，深刻的认识，而捧着厚厚的一本书，人类心理潜在的占有本能又往往会驱使着自己以最快的速度将这部教材拿下，满足自己的成就感，于是在没有外人监督，没有外力监控的情况下，很容易演变为一开始的时候读书，做题皆顾，随着时间的推移，自己开始不能抗拒快速读完书本的诱惑，于是做题的频率越来越低，最终在快速攻克目标的指导原则下，书读完了，习题却没有做几道。在读的过程中，在每个阅读的局部阶段，对作者想要传递的意思似乎都搞明白了，但真的把书本一合，要求你对某一小节，某一大章，乃至全书做一个总结性的回顾，往往就觉得很多想法，很多话，似乎就在嘴边，就在脑子里，却就是不能以流畅的方式表达而出。真要让你用书上讲述的知识解决一些实际问题，却往往感觉无从下手。究其根源，实际上还是学习过程做得还不够扎实。
在我们的阅读范畴中，有很多图书，是不值得精读的，特别是资讯性质的图书，资料，（尤以互联网上的信息为甚），制作这些信息源的作者，出于快速传播其信息的需要，往往会在制作过程中对资讯进行适当的处理，以降低受众理解消化的门坎。对于这类资讯，在阅读它们的过程中，能够增加我们的见识，却不能增进我们的理解力，因为在开始阅读之前，我们的理解力就已经与这些资讯的制作者相当了。（资讯的源制作人在其专业的领域当然有着超出常人的理解力，但在他制作资讯的过程中，已经试图通过各种手段，降低理解资讯所需的理解力了，否则，阅读一份资讯类的报纸还需要一个普通人经过一两天的思考才能完成的话，这些资讯制作机构也就早早关门大吉了）。
而一本经典的好教材，其定位与资讯类读物则大不一样了，通俗来说，读资讯类读物，是为了知道发生了什么，而读经典的教材类读物，则是为了知道在发生的事情背后蕴藏的机理。再换句话说，经典教材的目的是为了提升人的理解力，而资讯类读物，则是为了让人长见识。
想要通过读经典教材的过程来提升自己的理解力，就好比要通过读书的过程，将作者身上所具备的，而在读之前自己身上还未具备的某些能力，特质，吸收过来。不同的知识背景，不同的知识结构，不同的知识基础，甚至不同的文化背景都注定了要想让自己通过读一本书获得跟作者在这本书所述及的内容上相近的理解力，不会是件容易的事情。大量的思考，习题，实验，乃至于查找相关资料辨伪存真，相互印证，都是重要的手段。一本好的教材，也许只有500页，但为了将其读通，读透，进而提升自己在这本书所述范畴的理解力，你需要做的习题，需要查的资料，需要写的笔记和读书报告，可能会远大于这个页数。如果在读这类书的过程中，只是满足于在快速阅读中理解自己目光所触的书本范围内容，恐怕，读完了整本书，你都还未必能体会到作者真正想要传达内容的十分之一，个人在理解力上的增益也就很有限了。
所以，对于阅读经典教材，我会试着采用如下的方法：
1。坚持连续的阅读
关键是连续，我本人不主张那种"这周看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前端。这里面固然有部分原因是因为近一年来工作的积累让自己可以更快速的完成相应工作，但也真切的感受到一个问题，如果不实际动手做，仅仅是从外面看，往往会被一些表面上的困难阻塞住，产生不可逾越的感觉，及至真的动手做了，才会发现未必然。如果不是在新公司有工作需要,自己可能还是感觉没有做好自主实现编译器的积累。虽然自己现在在编译器设计实现方面仍存在大量的知识薄弱项需要补充，但这并不意味着自己不可以开始着手作一些实际的工作。
总是期待达到一个完美的积累状态再去动手实际做，结果可能就是一直陷入积累的状态不能拔出。