博客
关于我
强烈建议你试试无所不能的chatGPT,快点击我
技术文章的阅读姿势
阅读量:5223 次
发布时间:2019-06-14

本文共 2484 字,大约阅读时间需要 8 分钟。

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

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

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

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

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

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

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

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

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

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

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

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

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

  一点小心得,全文完。

转载于:https://www.cnblogs.com/williamjie/p/9354898.html

你可能感兴趣的文章
WPF移动Window窗体(鼠标点击左键移动窗体自定义行为)
查看>>
软件测试-----Graph Coverage作业
查看>>
django ORM创建数据库方法
查看>>
创建Oracle synonym 详解
查看>>
php7 新特性整理
查看>>
RabbitMQ、Redis、Memcache、SQLAlchemy
查看>>
linux查看端口占用
查看>>
hdu - 1226 超级密码 (bfs)
查看>>
Sql常见面试题 受用了
查看>>
知识不是来炫耀的,而是来分享的-----现在的人们却…似乎开始变味了…
查看>>
CSS背景颜色、背景图片、平铺、定位、固定
查看>>
口胡:[HNOI2011]数学作业
查看>>
我的第一个python web开发框架(29)——定制ORM(五)
查看>>
中国剩余定理
查看>>
基础笔记一
查看>>
uva 10137 The trip
查看>>
Count Numbers
查看>>
编写高质量代码改善C#程序的157个建议——建议110:用类来代替enum
查看>>
网卡bond技术
查看>>
UITabbarController的UITabbarItem(例:"我的")点击时,判断是否登录
查看>>