程序員每天都和代碼打交道。經(jīng)過(guò)數(shù)年的基礎(chǔ)教育和職業(yè)培訓(xùn)，大部分程序員都會(huì)「寫」代碼，或者至少會(huì)抄代碼和改代碼。但是，會(huì)讀代碼的并不在多數(shù)，會(huì)讀代碼又真正讀懂一些大項(xiàng)目的源碼的，少之又少。這種怪狀，真要追究起來(lái)，怪不得程序員這個(gè)群體本身 —— 它是兩個(gè)原因造成的：

• 我們所有的教育和培訓(xùn)都在強(qiáng)調(diào)怎么寫代碼，并沒有教大家如何讀代碼
• 大多數(shù)工作場(chǎng)景都是一個(gè)蘿卜一個(gè)坑，我們只需要了解一個(gè)系統(tǒng)的局部便能開展工作，讀不相干的代碼，似乎沒用

我常常把寫代碼和寫作進(jìn)行類比 —— 二者有很多相通之處;但從培養(yǎng)寫代碼和寫作的過(guò)程來(lái)看，二者又有很多不同。我們的寫作能力，是建立在大量基礎(chǔ)閱讀的基礎(chǔ)上的，是除了學(xué)習(xí)語(yǔ)法和文法知識(shí)外，從小學(xué)開始，經(jīng)年累月，通過(guò)閱讀各種不同層次的名家的作品，再加上各種各樣的寫作訓(xùn)練，累積出來(lái)的;而我們的寫代碼的能力，在了解和掌握了語(yǔ)法/文法之后(學(xué)習(xí)和抄寫 example 代碼也算語(yǔ)法/文法學(xué)習(xí)的一部分)，跳過(guò)了大量閱讀名家作品的過(guò)程，直接 biu 地一下就自動(dòng)養(yǎng)成了：學(xué)會(huì)基礎(chǔ)的語(yǔ)法和試驗(yàn)了若干 example 后，我們就火箭般躥到了自己寫代碼打怪贊經(jīng)驗(yàn)的階段。這樣略過(guò)大量閱讀代碼的階段有三個(gè)害處：

1. 寫代碼的基礎(chǔ)是不牢靠的，打怪升級(jí)的過(guò)程也是最慢的。道理很簡(jiǎn)單 —— 前輩們踩過(guò)的坑，總結(jié)的經(jīng)驗(yàn)教訓(xùn)，你都不得不親自用最慢的法子一點(diǎn)點(diǎn)試著踩一遍。
2. 很容易養(yǎng)成 stackoverflow driven 的寫代碼習(xí)慣 —— 遇到不知如何寫的代碼，從網(wǎng)上找現(xiàn)成的答案，找個(gè)高票的復(fù)制粘貼改吧改吧，湊活著完成功能再說(shuō)。寫代碼的過(guò)程中遇到問題，開啟調(diào)試模式，要么設(shè)置無(wú)數(shù)斷點(diǎn)一步步跟蹤，要么到處打印信息試圖為滿是窟窿的代碼打上補(bǔ)丁，導(dǎo)致整個(gè)寫代碼的過(guò)程是一部調(diào)代碼的血淚史。(見我的文章：你要避免的軟件開發(fā)模式)
3. 你周圍***的那個(gè)工程師的開發(fā)水平的上限就是你的上限。

我們?cè)倩氐阶x書進(jìn)行類比。

從小學(xué)到高中，就語(yǔ)文而言，12年時(shí)光，單單課本我們要讀十二冊(cè)，數(shù)百篇文章。如果每篇文章平均一千字，那么我們讀了數(shù)十萬(wàn)文字。這些文字，我們是精讀過(guò)的(有些甚至要求全文背誦)。每篇文章我們需要總結(jié)中心思想，段落大意，歸納出論點(diǎn)論證論據(jù)或者時(shí)間任務(wù)地點(diǎn)起因經(jīng)過(guò)結(jié)果，會(huì)分析長(zhǎng)句難句，會(huì)學(xué)習(xí)起承轉(zhuǎn)結(jié)，并反復(fù)訓(xùn)練基礎(chǔ)的遣詞造句能力，并最終模仿那些文章寫出自己的文章。在這個(gè)過(guò)程中，我們學(xué)會(huì)了賦、比、興，我們掌握了三段論，我們知道了如何用更優(yōu)雅地方式表達(dá)自己的思想。更重要的是，這些閱讀訓(xùn)練讓我們?cè)谖覀冊(cè)诿撾x學(xué)校的基礎(chǔ)教育后，可以自己獨(dú)立完成一本書的閱讀。我們不再依賴?yán)蠋熁蛘邊⒖紩鵀槲覀兘o出段落大意，中心思想，我們知道如何粗讀，細(xì)讀甚至類比閱讀一本書，我們能把書中的精髓濃縮成思維導(dǎo)圖，也大段大段摘錄書中精彩的句子，段落或者篇章。

這十幾年的時(shí)光，算上各種課外閱讀，世界名著，古典文學(xué)，金庸古龍，修正玄幻，一個(gè)大學(xué)畢業(yè)的二十幾歲的青年人，閱讀量應(yīng)該不下幾百萬(wàn)字。而稍稍涉獵廣些的讀者，上千萬(wàn)字的閱讀累積是常有的事。有了這些累積，你才能在迎面走來(lái)一位妙齡女子，想到的是肌膚勝雪，明眸善睞，桃腮帶笑，齒如含貝，氣若幽蘭，美艷不可方物，一笑傾城，再笑傾國(guó)，沉魚落雁，閉月羞花這些詞句，而非不知如何表達(dá)，只能吞吞口水，在肚子里悶上一句：「我擦，美女啊」。

這是讀書的***大功用：累積素材(information)。你是否寫文章時(shí)，經(jīng)過(guò)一番搜腸刮肚，也不知該如何描述某事某物?同樣的，寫代碼時(shí)，有沒有毫無(wú)頭緒，不知從何寫起的時(shí)候?或者有了些的思路，雙手卻在鍵盤上遲滯，不知所措?這些現(xiàn)象，大多是缺乏累積所致。

讀書的第二大功用：是開拓思路。有時(shí)候，一段文字，甚至一個(gè)句子，在你意料之外撲面而來(lái)，讓你有種醍醐灌頂?shù)母杏X。比如『圍城』里，趙辛楣和方鴻漸鴻初次見面，錢老描述趙的傲慢無(wú)禮，是這么寫的：「傲兀地把他從頭到腳看一下，好像鴻漸是本一覽而盡的大字幼稚園讀本」。初讀圍城的時(shí)候，我關(guān)注點(diǎn)是其故事性，將這樣的句子輕易放了過(guò)去，幾年前再讀時(shí)，才發(fā)覺它的精妙：竟能如此簡(jiǎn)單地以物喻人，就把整個(gè)場(chǎng)景復(fù)原到如同發(fā)生在我的面前一樣活靈活現(xiàn)。隨后，我自己的文字里也模仿著，有時(shí)甚至刻意地如此這般使用比喻來(lái)增強(qiáng)畫面感。前些日子偶爾再讀到這句，因我有了作為一個(gè)成人，給女兒讀幼稚園讀本的經(jīng)驗(yàn)，不由得莞爾一笑，旋即明白了一個(gè)道路：精妙的不是比喻本身，而是對(duì)生活的細(xì)微觀察。

我在邊學(xué) elixir 邊做 policy engine(見：Policy Engine 的前世今生)的過(guò)程中，除了官方的文檔和零星的博文外，可讀的內(nèi)容少得可憐，我要解決的一些問題，論壇里也沒人能給我較好的思路。于是我轉(zhuǎn)而讀了部分 iex 的代碼，了解了 elixir 代碼編譯的方式，最終完成了一個(gè) auto compiler 的 app —— 它能接受一些 API 請(qǐng)求，對(duì)預(yù)先配置的屬于其他 app 下的源碼可以在 cluster 里的有且僅有一個(gè) node 上進(jìn)行編譯，編譯完成后在整個(gè) cluster 的所有 node 里重新加載;在做 API 的過(guò)程中，我讀了 plug(elixir 下官方的 connection adapter 實(shí)現(xiàn))里面的主要邏輯，尤其是精讀了 Plug.Router 的代碼，搞明白了為何 Phoenix 的 router 敢宣稱在 route match 階段，其 performance 就甩同行好幾個(gè)數(shù)量級(jí)。于是我做 API 時(shí)，對(duì)如何在 match / dispatch 前后如何做些動(dòng)作實(shí)現(xiàn) middleware，甚至 hook 進(jìn) before send，有了更清晰的思路，在寫代碼時(shí)，也更加明白如何寫出類似的 composable adapter。

累積素材是基礎(chǔ)，被啟發(fā)出來(lái)的思路將這些素材串成線，這就形成了知識(shí)(knowledge)。書讀得越多，越勤于思考的人，知識(shí)也就越豐富。而知識(shí)的融會(huì)貫通，最終形成讀書的第三大功用：通過(guò)了解，吸收別人的思想，去蕪存菁，最終形成自己的思想，或者說(shuō)智慧(wisdom)。

information -> knowledge -> wisdom 是個(gè)長(zhǎng)期的累積，并非一朝一夕之功。

我的文章除幾篇廣告外，全部是原創(chuàng)，而原創(chuàng)中 99% 是我自己原創(chuàng)。這些原創(chuàng)完完全全是我「原創(chuàng)」么?我在 『如何選擇工作』一文中借用了『黑客與畫家』的思想：可測(cè)量性和可放大性。我贊同這個(gè)思想，同時(shí)將其融入了我自己的思考;在『程序員和拉條子』一文，我其實(shí)是寫了個(gè)現(xiàn)代版的庖丁解牛;『代碼重構(gòu)之道』我借用了松本行弘，Martin Fowler，荀子等人的思想，形成了我自己的見解。當(dāng)然，我書還是讀得太少，所以，真正有價(jià)值的思想還貧瘠得很。

同樣的，閱讀名家的優(yōu)秀的代碼最終的歸宿是形成你自己寫代碼的思路。我去年撰寫的一個(gè)基于 node restify 的 API framework(見：再談 API 的撰寫 - 總覽 系列)，雖然有很多不完善的地方，但內(nèi)核還是相當(dāng)穩(wěn)定，一年多來(lái)只是些許小修小補(bǔ)。撰寫它的過(guò)程，是我對(duì)之前所讀各種項(xiàng)目的一個(gè)融會(huì)貫通：為了確定我是否該基于 restify，我通讀了它的代碼(沒多少)，融合進(jìn)了 hapi 和 loopback 的一些思路，提供了一套類似于 rails 的 CLI，再加上早年在 parser 上的一點(diǎn)經(jīng)驗(yàn)，把 framework 邏輯上分出了：compile time(嚴(yán)格講 nodejs 沒有 compile time，但 configuration 的處理，route / middleware / model / task 對(duì)應(yīng)的內(nèi)部數(shù)據(jù)結(jié)構(gòu)的生成，算進(jìn)了 compile time 中)，load time 和 run time，用前兩個(gè)階段的「低效」換取后一個(gè)階段的高效(其實(shí)也類比了我的老本行，路由器/防火墻上的 control plane / data plane，first path / fast path 的設(shè)計(jì))。如果沒有之前各種源碼閱讀的累積，我很難做出這樣的設(shè)計(jì)。

同樣的，閱讀 elixir unicode 實(shí)現(xiàn)的過(guò)程在兩年前激發(fā)我做了一個(gè)使用同樣思路的漢字的 slugify，或者漢字轉(zhuǎn)拼音(解決多音字問題)的暴力方法(see github: chinese_translation)，這一思路在今年年初進(jìn)一步發(fā)揚(yáng)光大成了我們現(xiàn)在在 Tubi TV 使用的 policy engine 和 content engine，為每日不計(jì)其數(shù)的內(nèi)容請(qǐng)求保駕護(hù)航。我們使用了 code as cache 的方法，把數(shù)據(jù)庫(kù)里的內(nèi)容的不必在運(yùn)行時(shí)做的 transformation 都在 compile time 完成，然后在 run time 結(jié)合記敘文三要素，得到最終的結(jié)果。以前我們系統(tǒng)中我們最慢的 API，采用新的 engine，如今快了至少數(shù)十倍 —— 尤其是在低并發(fā)下就慘不忍睹的 95 percentile response time(高并發(fā)都無(wú)法完成測(cè)試)，如今在高并發(fā)，沒有任何 failure 的情況下，99 percentile response time 都能控制在 500ms 左右。

所以你說(shuō)，閱讀優(yōu)秀的，有啟發(fā)性的源代碼，多重要?

解決了 why 的問題，過(guò)兩天我們講講 how。