技术文章的阅读姿势

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

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

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

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

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

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

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

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

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

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

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

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

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

一点小心得,全文完。

最后编辑于
©著作权归作者所有,转载或内容合作请联系作者
  • 序言:七十年代末,一起剥皮案震惊了整个滨河市,随后出现的几起案子,更是在滨河造成了极大的恐慌,老刑警刘岩,带你破解...
    沈念sama阅读 161,326评论 4 369
  • 序言:滨河连续发生了三起死亡事件,死亡现场离奇诡异,居然都是意外死亡,警方通过查阅死者的电脑和手机,发现死者居然都...
    沈念sama阅读 68,228评论 1 304
  • 文/潘晓璐 我一进店门,熙熙楼的掌柜王于贵愁眉苦脸地迎上来,“玉大人,你说我怎么就摊上这事。” “怎么了?”我有些...
    开封第一讲书人阅读 110,979评论 0 252
  • 文/不坏的土叔 我叫张陵,是天一观的道长。 经常有香客问我,道长,这世上最难降的妖魔是什么? 我笑而不...
    开封第一讲书人阅读 44,489评论 0 217
  • 正文 为了忘掉前任,我火速办了婚礼,结果婚礼上,老公的妹妹穿的比我还像新娘。我一直安慰自己,他们只是感情好,可当我...
    茶点故事阅读 52,894评论 3 294
  • 文/花漫 我一把揭开白布。 她就那样静静地躺着,像睡着了一般。 火红的嫁衣衬着肌肤如雪。 梳的纹丝不乱的头发上,一...
    开封第一讲书人阅读 40,900评论 1 224
  • 那天,我揣着相机与录音,去河边找鬼。 笑死,一个胖子当着我的面吹牛,可吹牛的内容都是我干的。 我是一名探鬼主播,决...
    沈念sama阅读 32,075评论 2 317
  • 文/苍兰香墨 我猛地睁开眼,长吁一口气:“原来是场噩梦啊……” “哼!你这毒妇竟也来了?” 一声冷哼从身侧响起,我...
    开封第一讲书人阅读 30,803评论 0 205
  • 序言:老挝万荣一对情侣失踪,失踪者是张志新(化名)和其女友刘颖,没想到半个月后,有当地人在树林里发现了一具尸体,经...
    沈念sama阅读 34,565评论 1 249
  • 正文 独居荒郊野岭守林人离奇死亡,尸身上长有42处带血的脓包…… 初始之章·张勋 以下内容为张勋视角 年9月15日...
    茶点故事阅读 30,778评论 2 253
  • 正文 我和宋清朗相恋三年,在试婚纱的时候发现自己被绿了。 大学时的朋友给我发了我未婚夫和他白月光在一起吃饭的照片。...
    茶点故事阅读 32,255评论 1 265
  • 序言:一个原本活蹦乱跳的男人离奇死亡,死状恐怖,灵堂内的尸体忽然破棺而出,到底是诈尸还是另有隐情,我是刑警宁泽,带...
    沈念sama阅读 28,582评论 3 261
  • 正文 年R本政府宣布,位于F岛的核电站,受9级特大地震影响,放射性物质发生泄漏。R本人自食恶果不足惜,却给世界环境...
    茶点故事阅读 33,254评论 3 241
  • 文/蒙蒙 一、第九天 我趴在偏房一处隐蔽的房顶上张望。 院中可真热闹,春花似锦、人声如沸。这庄子的主人今日做“春日...
    开封第一讲书人阅读 26,151评论 0 8
  • 文/苍兰香墨 我抬头看了看天上的太阳。三九已至,却和暖如春,着一层夹袄步出监牢的瞬间,已是汗流浃背。 一阵脚步声响...
    开封第一讲书人阅读 26,952评论 0 201
  • 我被黑心中介骗来泰国打工, 没想到刚下飞机就差点儿被人妖公主榨干…… 1. 我叫王不留,地道东北人。 一个月前我还...
    沈念sama阅读 36,035评论 2 285
  • 正文 我出身青楼,却偏偏与公主长得像,于是被迫代替她去往敌国和亲。 传闻我的和亲对象是个残疾皇子,可洞房花烛夜当晚...
    茶点故事阅读 35,839评论 2 277

推荐阅读更多精彩内容