阅读源码的真正价值
大家好,我是Z哥。
最近有位小伙伴求職遇到一些挫折,來找到我聊,其中有問到一個涉及到「閱讀源碼的必要性」的問題:“有很多場面試,面試官都有問到某個框架的某個功能是怎么實現的,難道真的要去看源碼嗎?但是感覺看源碼除了面試有用,平時沒啥用……”
我想可能有不少人都有一樣的想法,所以我把我對閱讀源碼這件事的看法在這里和大家分享交流一下。
我曾經和一位同事聊天的時候打趣說,程序員可以分為4個層次。
1. 有閱讀并吃透大型知名框架的能力
2. 能夠知道并通過閱讀框架源碼來解決問題
3. 能夠知道并通過找官方文檔來掌握框架的使用
4. 需要有人手把手教或者自己踩過很多坑才能掌握一個框架的使用
這其實也體現了我對閱讀源碼這件事的看法。想成為厲害的程序員,閱讀源碼的能力必不可少,并且能夠hold住的源碼復雜度越高,水平越高。
我們程序員雖然每天都和代碼打交道,但是大多數時候都是在「寫」而不是「閱讀」。唯有在接手一個新項目的時候,才會被逼著在短時間內閱讀大量源碼。畢竟,大多數情況下我們一直在固定的項目里“深耕細作”,閱讀其它項目的源碼,似乎對手頭的項目沒什么用。
但是在我看來,coding就好比寫作,如果你想寫出好文章,必然需要掌握很多語言組織上的技巧。比如,排比句、反復句等句式,比喻、擬人等修辭手法等等。這些其實就類似于coding中我們需要考慮的設計模式、算法這些東西。
在我們學生時代,老師會引導我們閱讀大量的課外文章來提升這方面的能力,學習別人的寫法,摘錄別人的金句等等。
其實coding也是一樣,如果你平時如果不多積累一些“美化”代碼的“套路”,如何能寫出優雅的代碼呢?
所以通過閱讀源碼來提升你的編程能力,和閱讀好文章提高自己的寫作能力是一樣的。
從這個邏輯也可以衍生一個新的邏輯,就是單憑自己頓悟、踩坑來提升編程技能的速度,必然比不過借助閱讀別人源碼來提升的速度。畢竟,參考、借鑒別人的東西可容易多了。你看,有哪個大文豪是不是閱讀了大量的優質書籍?
回到本文的核心問題上,在Z哥看來,閱讀源碼的價值有很多,面試的作用只是一個短期價值。我認為它至少有以下5個價值。
/01? 短期價值/
01? 面試
正如前文提到的那位來找我咨詢的同學,他也知道閱讀源碼對面試的作用是很大的。
因為有些實現細節如果我們只是會用,但不去看源碼了解細節,其實就是所謂的“知其然而不知其所以然”。
比如,ArrayList 和 LinkedList 的區別?想要回答好這題,必須從源碼入手,了解 ArrayList 和 LinkedList 底層實現。如果你沒有閱讀過源碼的話,這道題肯定是回答不太好的或者回答的時候底氣不足。
/02? 長期價值/
01? 在工作中更快地上手新項目
正如前文所說,每個程序員的職場生涯中,都無法避免“閱讀源碼”。因為你不可能一直在一個項目里工作,必然有機會接手很多陌生的項目。此時如何快速的了解項目的脈絡、結構,以便自己快速的展開工作?這個時候,閱讀源碼能力高低就體現出來了。
雖說,如果上一位接手者還在職的話可以請教他,但是人家不可能真的像網傳的「結對編程」圖片那樣,手把手解釋給你,你說是吧?大部分時候還得看你自己的閱讀源碼能力。
▲圖片來源于網絡,版權歸原作者所有
02? 給自己創造用新技術的機會
很多技術人會抱怨工作中用不到新技術,一直在用老舊的技術。如果你寄希望于公司層面來推動一個新技術的運用,那就有點看緣分了,可能直到你離職也不一定會有這樣的機會。
畢竟站在組織的角度來說,我現在項目跑得好好的,為什么要用新技術?新技術對我有什么好處,值得讓我承擔未知的風險?
但是如果你對某類技術其中之一的框架有源碼級別的了解就不一樣了。你可以借此主動推動運用某項新技術。因為你可以具體說出很多具有說服力的觀點,
這個新技術到底好在哪里?
能夠改善或者提升當前的系統的某幾項能力?
為什么它可以提升這些能力?
它是怎么實現的?
如果我們要用它,需要提前對哪些知識進行儲備?
……
況且,有時候組織層面不敢貿然使用新技術,可能也是擔心沒人能hold住這項新技術,萬一出現什么問題無法及時解決怎么辦?此時,如果他們發現這里有一位閱讀過源碼的伙計,這份擔憂必然大大降低。
03? 完善知識體系
那些大牛之所以能夠在自己專攻的領域內無所不知,是他真的記憶力好嗎?并不是,而是他的知識已經形成了體系框架。
完善體系框架的過程必然是你主動而為之,單憑工作中遇到問題時的百度、google是無法形成體系結構的,因為那些都是零散的碎片化知識。
如何快速的攝入大量原本就已經成體系化的知識?那些成熟的框架中就是啊,一個功能越龐大的框架,它所覆蓋的知識面就越廣,如果你能吃透它,你就可以快速擴充這方面的知識體系。這個過程簡直就像是偷偷學了一本乾坤大挪移。
所以,閱讀源碼是一個加速你知識體系完善的有效方法。用不了多久,你也可以成為別人眼中的大牛。
04? 學習別人的設計思路
靠自己領悟自然也能逐步成長,當然前提是你得能夠「領悟」到什么。但是以這樣的路線來成長,你會陷入以下兩種境地。
自認為自己的設計很牛逼,而實際上……
覺得這樣設計代碼很變扭,但是又不知道有什么更好的方式。
如果你閱讀過足夠多的優秀源碼,能夠不斷地吸取他人之長,這些情況自然就不會發生了。因為當你在看那些優秀的源碼的時候,會有很多驚喜的過程。
“原來這里還可以這樣來設計”、“對呀,這么設計不就搞定了么” 、“哇塞,這段代碼設計的真精辟”,這些都是我在閱讀那些優秀的源碼時腦海中經常蹦出的詞。
每當你覺得有收獲到什么的時候,你可以將它們記錄下來,并思考適用的場景。這樣當你后續項目中遇到類似的場景,你就會想起“好像這里之前看到過一個精辟的設計,我去翻翻之前記錄的代碼案例。”
所謂“萬事開頭難”,閱讀源碼也是如此。因為當你閱讀完第一個源碼再去閱讀下一個的時候,你自然而然地會帶著批判或者說挑剔的眼光去閱讀:為什么這個功能在我之前看的源碼中是那樣實現的,而在這里會是這樣實現的?這其中的道理在哪里,哪種實現方式更優秀呢?通過這樣的對比及探索,你會發現,自己的進步快得難以想象。
好了,總結一下。
這篇呢,Z哥和你分享了我對「閱讀源碼的必要性」這件事的看法。
我認為閱讀源碼和寫作類似,相比自己琢磨、頓悟,更快的方式是通過借助、參考別人的思想成果來提升自己。當然,它的價值不僅僅用于面試,至少還有四個長期價值。
在工作中更快地上手新項目
給自己創造用新技術的機會
完善知識體系
學習別人的設計思路
不知道你對于閱讀源碼的態度是什么?歡迎在評論區分享你的看法。我后續打算再寫一篇如何閱讀源碼,敬請期待。
推薦閱讀:
學得越多,大腦越亂?
產品經理的「臨界點」
原創不易,如果你覺得這篇文章還不錯,就「在看」或者「分享」一下吧。鼓勵我的創作 :)
如果你有關于軟件架構、分布式系統、產品、運營的困惑
可以試試點擊「閱讀原文」
總結
- 上一篇: EFCore查缺补漏(一):依赖注入
- 下一篇: Goodbye 2020,Welcome