摘要：技術人員也并不能免俗，除了，知乎，等幾個大平臺可以展現自己的技術實力，對業界叮出自己聲音外。導致內容汗牛充棟，良莠不齊之因自然不在平臺方，而在哪里不言自明。我的文章會在個人博客和知乎專欄同步發出，歡迎大家關注我的知乎專欄。

作者：胡子大哈

本文原文：http://huziketang.com/blog/posts/detail?postId=58bd1021204d50674934c3ae

轉載請注明出處，保留原文鏈接以及作者信息

每天各種渠道的技術類文章層出不窮，一篇文章看到最后發現說的全都是正確的廢話，另一篇文章看到最后發現只適合某種特殊條件下，再一篇文章發現是包裝迷惑華麗的廣告貼。到頭來最深的感悟——“看了很多，卻什么都不知道”。

人人都是自己的品牌，人人都是自媒體的時代，使得每個人每天接收的信息量是以前的百倍。隨著所謂內容付費的又一波浪潮撥動著人們的心弦，作為有一些想法的小伙伴們都紛紛“下海”，填補著前方付費藍圖的空白。

技術人員也并不能免俗，除了Github，知乎，MDN等幾個大平臺可以展現自己的技術實力，對業界叮出自己聲音外。一些新的專門技術的內容分發平臺，成為了一片新的內容填充洼地。

閱讀技術文章可以說是技術人員的日常。我自己在平時的學習過程中，除了 follow 的一些大V，學習別人對同樣事情的看法角度以外，也會經常的看一些技術類文章。一些新的技術內容分發平臺比如，“掘金”，“簡書”，“開發者頭條”最近也有很多嘗試，不過漸漸的，我發現了問題：各類文章琳瑯滿目，一段時間以內自己看的很累，靜下心來仔細思考確發現回憶不起什么內容。是我出了問題嗎？是文章出了問題嗎？是內容平臺出了問題嗎？

打開“掘金”，“簡書”，“開發者頭條”等平臺（這里不針對任何一個平臺，只描述現象）。每天會看到大量不同的文章，主題各式各樣，內容深淺不一。各式各樣的標題會讓人有種快速暢享知識的欲望，巴不得吃掉所有內容?？墒沁@時候問題就來了，閱讀完一篇以后，會發現其文章內容的質量，和對標題所產生的預期遠不能 Match。很常見的一種現象是，本預期作者會對標題所介紹的技術進行了細節的討論和自己親身的實踐，以得出普適性的意見或見解。而實際上文章的內容卻是官方文檔以偏概全的翻譯，或者“大神們”經典經驗的摘錄，這樣的論述結果往往導致了邏輯不嚴謹，前后銜接不上，雖然說的是同一個事情，卻導致讀者很難理解。而在我看來，作者的個人觀點和嘗試才是更加有意義的，將自己的親身經驗分享出來，幫助后來人少走彎路。一個坑可能坑到一個人 1 個小時，而分享出來以后，卻節省了 10000 個人的 10000 個小時，這價值是何其的大！而以標題見長的文章，除了點擊量可能會有所上升，其價值卻不足為道，整體文章可能都是零碎知識所拼湊，對個人能力的提升或視野的擴展收效甚微。導致內容汗牛充棟，良莠不齊之因自然不在平臺方，而在哪里？不言自明。

內容為王，其意在內容，在優質內容。優質內容往往是稀缺的，而稀缺的資源大都發布渠道穩定，投機倒把才會搖擺飄忽。我所理解的優質內容其實包含了兩層含義：主觀上的優質內容 和 客觀上的優質內容。

何為主觀上的優質內容？說白了就是合適你的，你喜歡的；再說白了就是智能推薦，根據你的歷史閱讀記錄，通過機器學習算法了解到你的喜好，包括：文章類型、標題類型、關注領域等多方面。這就是機器學習的好處，可以把各種影響因素都融合到一個模型中，綜合決定這篇文章是否推薦給你。而隨著你看文章的數量越來越多，你給自己打的標簽也就越來越精細。那么這時候系統給你推薦的內容對你來講，自然是“優質的”，都是你喜歡的。曾經的今日頭條在這方面可以說做到了國內第一，整個推薦模型由上億個維度、幾百臺機器來支撐運行。其實說句公道話，當時的今日頭條的推薦體驗還是不錯的，現在的今日頭條商業性質逐漸濃厚，對于推薦方面的用戶體驗可以用上 hehe 這個形容詞了。

何為客觀上的優質內容？是說真正的好文章，干貨文章?；蚴亲约航涷灴偨Y，或是自己技術洞見，亦或是某一常見技術問題的解決方案。這里我著重強調第三種，通篇介紹作者對某一技術的看法和其實踐經驗是很有價值的。比如在一個新的東西出來的時候，首先吃螃蟹的，必然是有坑在等著你的。踩到了坑從坑里爬出來的過程就是學習，就是成長。但是同樣的坑，千千萬萬的人依然會掉進去。那么這時候總結出來的文章，就是干貨，就是好文。舉個不恰當的例子，我在用 ReactNative 寫 App 的時候，要加載長列表。RN 自帶的 ListView 是沒有使用 Recycling 的，這樣就使得 RN 無法使用大數據的長列表。那么你的 App 就會非常吃內存，導致的結果自然不言而喻。而這個問題官方也沒有一個很好的解決方案。（這里是 issue：[[ListView] renders all rows? · Issue #499 · facebook/react-native · GitHub](https://link.zhihu.com/?targe...）。為什么說是不恰當的例子，是因為我沒有解決方案，官方也沒有解決方案。我只是把問題 push 出來，以免后人采坑。倘若這個問題描述，再配合上行之有效的解決辦法，那么這就是一篇精華文章，得以 RN 界廣泛傳播都不為過。

這兩種都是我所謂的優質文章，而對于技術人員來講，客觀上的優質內容顯然來的更加實在。

“不要用戰術上的勤奮，掩蓋戰略上的懶惰”，這句話用在這里同樣恰如其分。一天下來讀個十篇八篇文章的問題不大，感覺收獲滿滿，但實際上回憶不起多少內容。這種情況的知識獲取其實是潛意識懶惰的一種表現，甚至和人交流的時候都說不上來，更別談實際應用于項目中了。那么怎樣才是一種好的閱讀方式呢？

我們老生常談，從泛讀、精讀和研讀聊起。三者爛大街的概念我就不說了。我個人來講不推崇泛讀，上面說到的情況就屬于泛讀的范疇。而技術類文章恰恰是最不適合泛讀的一類，因為泛讀的目的一般而言是擴展自己的視野和知識面，技術類文章則更多的是針對某一技術的討論分析和實踐。講道理的話這類文章，適合精讀甚至研讀。但不是說泛讀在這里就不起作用了。正如前面所說的，文章鋪天蓋地，如何能從如此繁多的文章中挑出合適自己的來精讀呢？這就是泛讀在技術類文章閱讀中的價值體現。通過泛讀，找到合適自己的一篇或幾篇準備深入的文章；通過精讀，掌握其中的原理和實踐方法；必要時通過研讀，深刻理解技術思想。這樣的一種情況下，一天讀一篇，甚至幾天讀一篇都是值得的。我總結為：走馬觀花，不如退而結網。當然，每個人的閱讀習慣不同，產生的效果和效用也不同，僅表達個人方法。

本文也只是表達了本人的一些觀點和方法，同樣也是屬于“可能正確的廢話”一類文章，且看且思。針對這個問題每個人都有自己叫苦不迭的煩惱，甚至有的時候點一篇文章都不受自己理性的控制，有什么看法歡迎與我交流。

再講一次道理，閱讀到這里，應該花掉你 6 分鐘上下的時間。如果你也看到這里了，回想一下自己用了多久，是不是在閱讀這篇文章的時候，依然是從前的閱讀習慣呢？

不管怎么樣，看了本文，如果能讓你產生一絲絲想要調整自己閱讀方法的念頭，也算幸事一件。套用一句流行的話來結束本篇文章：我說的，都是錯的。大家下期再見。

后記：
很多讀者對文章反饋，表達了對文章的不滿，本文就是那種沒營養，沒技術含量的文章。確實，這部分讀者的看法我是同意的。本文確實內容空洞，技術含量底下，并沒有體現技術方面的東西。實際上，這只是我的一點思考和感悟。這里再多叨叨幾句吧。對于閱讀習慣，不同人是不一樣的，不同人的閱讀方法也是不一樣的。我比較贊同掘金 kalasoo 的說法：無所謂好和壞，合適自己的就是最好的。如果看了本文以后，能對自己的閱讀方式和習慣有一個思考，提升自己，那也算本文的一點點成功了。

我自己的文章，不論是初級教程，還是高階經驗，都會以言之有物作為文章質量的標準。我的文章會在個人博客和知乎專欄同步發出，歡迎大家關注我的知乎專欄。

我最近正在寫一本《React.js 小書》，對 React.js 感興趣的童鞋，歡迎指點。