學會閱讀源代碼

 在計算通信領域，寫幾段人類能夠理解的文字，實在比敲幾行不令編譯器嘔吐的代碼要困難得多。

這就是為什麼每當涉及到代碼，幾乎所有文檔都弱爆了。因為寫東西給人看比寫給機器看難得多，在可以預見的未來，文檔將一直弱下去，而對此你無能為力。

除了一件事。

要學會閱讀源代碼，Luke。

JavaScript中“源代碼包含一切”的變革性力量，就是我提出並將一直信奉的Atwood定律。儘管“查看源代碼”沒有被內置（卻完全應該內置），但你應該為自己的棧要求查看相關源代碼。無論文檔里怎麼說，源代碼才是最終真相，才是你所能找到的最好的、最新的並且是最權威的文檔，這永遠是事實。所以，你越早承認這一點，你就能夠成為一個越來越富裕的軟體開發者。

關於這一點，我曾經有一大批條目準備去寫，後來我發現了Brandon Bloom投遞在Hacker News上的一篇傑出的文章。請認真閱讀，因為他解釋了閱讀源代碼的好處，以及在什麼情況下你需要閱讀源代碼，遠比我解釋得清楚：

15歲時，我開始在微軟平台上從事專業工作，我作為微軟的一名開發者，做一些Visual Studio的整合性工作。在我寫下第一行Visual Basic代碼十多年後，我希望再也不要去鏈接一個封閉的庫。

使用軟體與編寫軟體不同，如果你還是只使用大多數軟體的基本功能，那就已經落後了，其他人已經遇到問題並且許多人將問題積極提出，以此促使核心貢獻者們糾正問題。然而編寫軟體是一個創造的過程，而且有許多方法去做，你會遇到未使用的比特、生鏽的角落以及未完成的試驗代碼路徑；你會遇到已知被破壞的邊界條件卻在正常運行。

有些時候文檔並不完備，有時甚至是錯誤的，而源代碼從不說謊。對於一個有經驗的開發者，閱讀源代碼的速度通常會更快……特別是當你已經對包的結構很熟悉時。我同一些創業者們在一個中等規模的協作空間中工作，很多其他CTO和工程師們偶爾會來我們團隊進行諮詢。當人們報告他們堆棧中存在的問題時，我通常問他們的第一個問題是：“嗯，你讀過源代碼了嗎？”

我鼓勵開發者把他們依賴的任何東西都進行git clone。起初，他們都很擔心，“工程太大了，我不可能找到它！”或者“我不夠聰明，理解不了”亦或者“代碼寫的太丑了！我實在不想再看它”。但你不必全部代碼都搜尋一遍，只需遵循線索。如果你不能理解下層的平台，如何去弄懂自己的軟體？多數時候，沒有經驗的開發者認為的比較好看的東西其實都是些表象，他們認為難看的，卻是編程高手寫的久經沙場、產品級別的代碼。一兩年後，兩個開發者找到我，感謝我曾強迫他們在自己的代碼海洋中沉浮。他們的技術愈發精湛，並且很好奇當初在沒有源代碼的情況下自己是如何做完每件事情的。

當你經營一家公司時，如果你的軟體有bug，你的客戶不會去關心這是否是Linus或其他哪個Rails開發者的錯，他們只知道你的軟體有bug了，這時每個人的軟體都變成了你的軟體，因為他們的bug就是你的bug；當一些東西出錯時，你需要找出哪裡壞了，並修好它們，你得在棧的最佳點處修復它們，以此降低風險、節約成本並爭取時間；有時，有快速的解決方案當然是好事；有時，你卻需要重新編譯。通常情況，你會請上游部門的人來解決，而其實通常你都得自己解決。

• 封閉軟體商店會有兩個選擇：乞求別人寬宏大量，或是想辦法解決問題。
• 較弱開發者的開源商店往往按照封閉軟體商店的做法。
• 老牌商店會慢慢的養蓄必要的“肌肉”，來維持自己的“分叉”和“補丁”諸如此類的東西。

真正的黑客們達成了一個共識：在我的機器上運行，就是我的軟體，我會對它負責，我必須弄懂它；從源代碼創建是規則而不是例外；我必須控制我的環境，我必須控制我的依賴。

讀別人的代碼沒有人會感覺愉悅。而且我TM甚至不喜歡讀自己的代碼。能夠安頓下來深陷皮革沙發中，穿著吸煙夾克（譯者註：男士晚間便服），端一杯白蘭地，一邊閱讀某人寫的代碼，就這樣度過一個美妙的夜晚，這種想法是荒謬的。

但我們需要查看源代碼。我們必須閱讀他人的代碼，因為要完成工作，我們必須先弄懂它。因此，不要害怕讀源代碼，Luke，隨它帶你去任何地方，無論它看起來多麼可怖。

關於譯(作)者:
姚睿堯：入門級程序員，在試錯中成長。（新浪微博：@大隱於微博 | 個人博客：浮遊）