技术文章首选官方重精读不泛读，求阅读质量而非数量---转自peak

Posted 2020-09-08 andyroyal

阅读技术文章可以说是我们程序员的日常之一，Peak 君每天也会进行定量的阅读。特写一篇小文分享下心得，介绍下过去几年，在纠正阅读习惯上所做的一些努力和取得的成果，或许可以帮助一些朋友，节省少许阅读时间，提升一点学习效率。

　　差不多两年前，我开始搭建 android 相关的知识体系。最开始的想法是从基础知识的积累开始，正好这几年社区的技术分享盛行，「掘金」、「开发者头条」、「简书」等渠道上每天都有大量的新文章发布，文章主题五花八门，内容深浅不一，看上去都很不错。可坚持读了几天之后，深感自己踏进了错误的方向，读过的比较有代表性的一篇文章是：「关于 Service 你所需要知道的一切」，文章内容的质量远低于标题所勾起的预期，无非是把官方文档里的几个知识点做下摘录，有些地方反而因为摘录不全导致逻辑不连贯，顺藤摸瓜找到出处之后，发现官方文档才是我的救赎。

　　最初学习 ios 的时候，也走过类似的弯路，急于在短时间内掌握要点，急于能尽可能快的开始写代码，所以略过了看上去冗长繁琐的官方文档，转而搜索各类总结文章以求速成，结果是所有心存侥幸投机取巧跳过的知识点，都会在某一天变成一个个费时费力去填的坑。

　　对于基础知识框架的搭建，没有比官方文档更好的起点了。当然官方文档太过全面，无法在一开始就通读一遍。正确的做法是，在计划深入某一块知识域之前，先读一遍与之相关的官方文档，如果还有疑惑再去其他渠道搜索相关知识点，做进一步的深入发掘，这就涉及到下面有关「精读」的话题。

　　从这一角度来说，上面提到的三个渠道，对于基础知识的积累，阅读价值并不高，很有可能，整篇读下来都是些零零碎碎已知的知识点，收效甚微，绝大部分文章都是标题惊艳，内容单薄。当然不排除偶尔会遇到一些高质量的深度好文，但这些好文大多是转载的，是有自己的发布渠道的。按我以往经验观之，好文是稀缺资源，数量稀少且发布渠道稳定，比如一些类似 bugly 这样的大厂对外渠道，国内外一些优秀的博客写作者，或者是偶尔在微博上被大量转发的文章。这些渠道都可以被分门别类的装进浏览器的收藏夹，无需每次去「掘金」这类的渠道做大海捞针式的搜索。

　　阅读行为一般可以划分为两类：泛读、精读。技术类的文章阅读也不外如是，不同点在于，技术阅读应该重精读，轻泛读。技术知识的价值能否得以体现，关键在于最后是否在阅读者的记忆里得以沉淀。泛读行为很难形成有效且深刻的记忆，但偏偏泛读较之精读要轻松很多，所以很多初学者习惯性的去做大量的泛读行为，看标题感兴趣就点进去浏览，一天下来能读好几篇，最后形成收获颇丰的错觉，这其实是一种潜意识下的偷懒行为。这种阅读行为中收获的知识，别说难以在实际项目中去应用，就是在面试中聊聊都是不能。这条弯路 Peak 君也走过。

　　在精选、形成完自己特有的阅读渠道之后，我们应该调整自己的阅读行为，尽量强迫自己去做精读，去深入挖掘、消化自己认可的深度好文。一篇技术好文，一天能消化干净算得上奢侈了，有些文章需要陆陆续续读上一个星期也是可能的。精读一篇文章确实会比较辛苦，但你想想，写文章的人更辛苦，不光要理解文中所谈的各个知识点，还需要做串联归纳以成体系，精读一篇深度好文就是一次和某个领域的专家做深入交流的机会，只是草草的浏览一遍而错过一次宝贵的加深知识域的机会岂不可惜。如果文章主题和当前自己的关注点切合，读起来越是费力的文章，其价值也越高。简而言之，技术类文章阅读，是宜少不宜多，宜静不宜泛。

　　相信不少人阅读技术文章时，都有过类似的体验：在文中发现一个陌生的术语，转而 google，搜出更多的术语或者相关文章，于是切换到新的环境中去继续阅读行为，有时会如此反复跳跃几次，最后浏览器上的 tab 越来越多，感觉文章根本读不完。

　　这是由于技术的知识体系往往是个树形的结构，单个术语下都有其相关的知识域，可以一层又一层牵扯出更多的子术语。在阅读文章遭遇这种树形结构的时候，要能抑制住自己不停探索的欲望，对于技术术语的学习只做适度延伸，最终的目的还是在于完成根部文章的阅读。Peak 君的阅读习惯是只做一到两层的延伸，比如刚开始学习 ReactiveCocoa 的时候，接触到函数式编程，了解函数式编程又挖出了 pure function，pure function 又包含若干其他的概念，可以持续的深入下去，但到 pure function 这一层之后其实就可以适可而止了，可以回过头来完成原先的阅读任务。

　　要克制对于知识的求索欲，有时也不容易。现实是，我们精力有限，无法在每个领域都成为专家，看到优质深入的分享好文时，很容易产生知识的焦虑感，迫使自己去阅读并无太大交集的话题，这反而容易造成时间和精力上的浪费。不同技术人员之间，在知识的储备量上其实不具备可比性，真正需要在意的是学习和解决问题的能力。

　　再者是对于阅读时间段的选择。程序员工作时很容易被打断，产品，设计，测试随时都有可能找上门，做深度阅读时一旦中断，阅读效果会大打折扣。我们应该根据自身的情况，尽量选择没人打扰的时间段来做阅读，可以是早上刚到公司，或者别人午睡时，总之越安静，越没人找越好。

　　最后一点，可以从慌不择食的技术文章阅读时间里，多抠出一些来，完完整整的阅读一些大部头的英文原版技术书，这才是知识学习的正餐，别人写的零散文章更适合作为饭后甜点。比如 Peak 君经常推荐的 【TCP/IP 协议详解】，这种经典书籍，即使耗费一年的时间去阅读，也远远强过读一年别人所写五花八门的技术文章。

　　说了这么多，提炼下摘要：对于基础知识的阅读，要重官方文档，切莫心急动手，看完文档形成知识体系后再写代码不迟。减少泛读行为，避免漫无目的的随意浏览技术文章。注重精读，一天一篇不算少，一周一篇也正常。重阅读质量而非数量，挑选每天安静且不易被打断的时间点来阅读，尽量多啃原版书。

　　一点小心得，全文完。