读书到什么程度才能算融会贯通？

我是一个喜欢读书的人，因为面对这样一个复杂的世界，我渴望了解它的真相，我想获得关于这个世界各个层面的知识，从而提高我的认知，进而成为一个不糊涂、有趣的人，这就是我的原始驱动力。

我们也应该都读了不少书了，但是始终有一个问题，书读到什么程度才算通汇贯通呢？

我觉得可以从两方面作答：纵向和横向。

首先是纵向。怎么做到融会贯通呢？就是当你读一本书的时候，还能推荐这一类的其他几本书。

比如说我前一段时间写了几篇文章：

只看题目就好了，想了解细节的可以点进去看看，其实这几篇文章阐述了读书的几个基本步骤：
1、摆脱对读书的敬畏感。就是别怕。
2、速读。先看主题，再看结构和脉络，找你想看的重点，提出好的问题。注意这部分一定要不求甚解。
3、精读。根据你的问题有针对性地仔细去看。
4、输出。或者叫反馈，这里指写作。

其实我的观点主要是来自于我读过的几本书，并且我也是这么实践的。如果你看完我这几篇文章，觉得要是志哥也读过这几本就更好了，那里面有个什么什么观点比这几篇文章要好，那你在这个小的领域差不多就算融会贯通了。

列一下这几本书：
《如何阅读一本书》 ——莫提默.J.艾德勒
《这样读书就够了》——赵周
《如何高效读懂一本书》——秋叶
《如何有效阅读一本书》——奥野宣之
《书都不会读，你还想成功》——二志成

当然还有很多其他类似的书就不多介绍了。

另一个是横向。也就是不只是读书，在做其他事情的时候也是能够用这一套方法的。我举几个例子。

比如读源码，我是一个程序员，平时肯定要读源码，有些人一听到读源码，觉得那都是牛逼的人才读的，我等渣渣就算了。那现在我们套用上面几条读书心得，来看看这个问题。

首先就是要摆脱对读源码的敬畏感，很多人怕读源码，其实这种心理大可不必有，你想想看，你新加入一个公司，或者接手一个新项目，如果不是你从头开始开发的话，是不是需要先了解这个项目的源码，难道你自己项目的源码就不是源码？只是那些优秀的开源技术框架写的好一点而已。

第二是先速读一遍，根据需求文档、技术文档，先去了解这个项目的大概内容，找到关键的点，提出你自己的问题。同样注意，这步要不求甚解，不要去跟某个小的函数里面的实现。

第三是精读，可能你急需改这一部分的 bug，或者你想弄明白这个地方是怎么实现的，这就要你精读这一部分的代码。这一步就要求甚解了，每一行都要明白是干嘛的。

最后是输出，把你遇到的那些坑，或者这段代码写的比较好的地方记下来，留着以后回顾，还可以分享给同事，或者写篇文章，加深一下记忆，还能帮助他人。

你看，是不是和读书一样的道理，读开源的框架也是一样的。其实同样的文章我可以再写几篇，只要把关于读书改成关于读源码就好了。

上面那个可能比较技术一点，再举一个生活中的例子，就是前几天发生的，我朋友圈的都知道我装了个桌子，有人说装个桌子还不简单吗？你先听我讲啊。

我和两个同事合租的三室一厅，我们买了三个桌子，要自己装，刚开始一个室友尝试了一下，说不好装，我大致瞄了一眼，加上他说的话，也觉得不好装，于是就在那放了一个月，我每天没桌子也挺痛苦的，但是那句不好装加上拖延症，也就没装，其实这就是对装桌子有点敬畏感。