不會(huì)讀代碼的程序員，不是好廚師
[導(dǎo)讀]會(huì)讀代碼，和會(huì)寫一樣重要
[導(dǎo)讀] 大家好，我是逸珺。
某日一好友，調(diào)侃我的筆名，說讀起來好像“抑菌”！嗨，還真是，不管了，“抑菌”就“抑菌”吧。
寫號(hào)以來，有小伙伴問：如何能快速提升編程能力？這感覺永遠(yuǎn)沒有正確答案，每個(gè)人都有自己的套路，今天就來聊聊我對(duì)這個(gè)問題的看法：
學(xué)會(huì)高效讀代碼，就是一個(gè)不錯(cuò)的辦法。閱讀代碼，可能和寫代碼一樣重要！
然而，理想很豐滿，現(xiàn)實(shí)很骨感！工作中，你寫代碼的時(shí)間可能只占工作時(shí)間很少很少的一部分，大部分時(shí)間你可能都是在閱讀已有的代碼，當(dāng)然除非這個(gè)項(xiàng)目從0到1都是你一個(gè)人干，可即便是自己寫代碼，也是漸進(jìn)增長(zhǎng)、不斷迭代的，也需要不斷反復(fù)閱讀自己寫的代碼。
再者，編程與寫文章，有異曲同工之處。編程與寫作相似之處，都是用語言表達(dá)寫作者的想法。
對(duì)于如何提升寫作，古人曾講：熟讀唐詩(shī)三百首，不會(huì)作詩(shī)也會(huì)吟?；叵雽W(xué)生時(shí)代，老師也常說：讀書破萬卷，下筆如有神！強(qiáng)調(diào)寫作需要大量閱讀，讀的多了，寫作能力也會(huì)相應(yīng)提升。閱讀之于寫作，相輔相成，互為促進(jìn)。
那么大量閱讀別人的代碼，也能提升自己的編程水平。閱讀代碼，個(gè)人覺得會(huì)有這樣些好處：
正如牛頓所說：如果我能比別人看的更遠(yuǎn)，只因?yàn)槲艺驹诰奕说募缟稀?br />
比如做Linux編程的時(shí)候，遇到某個(gè)API出錯(cuò)，或許在網(wǎng)上查找半天，都找不到答案。實(shí)在找不到答案了，嘗試讀一讀內(nèi)核底層相關(guān)代碼，有時(shí)候就能發(fā)現(xiàn)問題的原因。
如果能善于發(fā)現(xiàn)一些新的感興趣的領(lǐng)域，并去閱讀相關(guān)的代碼，則一定會(huì)提升自己的編程能力的。
如果是Linux應(yīng)用程序，或者C 應(yīng)用程序，我也大致采用差不多的思路，先讀個(gè)大概，然后再細(xì)讀。比如對(duì)一個(gè)Linux應(yīng)用程序，會(huì)先了解這些方面的概要信息：
閱讀某一個(gè)具體函數(shù)時(shí)，如果函數(shù)內(nèi)或者模塊內(nèi)具有狀態(tài)機(jī)，如果這部分是需要仔細(xì)理解的時(shí)候，我就會(huì)將其狀態(tài)機(jī)圖，先繪制出來。比如，之前寫的modbus協(xié)議中的狀態(tài)圖：
這樣做有個(gè)好處，邊繪圖邊去理解代碼，就會(huì)加速對(duì)代碼的理解，對(duì)我來說，我如果只用兩只眼睛盯著看，和一邊看一比畫圖效率會(huì)低很多。
這樣做還有一個(gè)好處，可以將理解以圖的形式記錄下來，如果光用圖還不能表達(dá)清楚的時(shí)候，我還會(huì)再加點(diǎn)文字描述。時(shí)間過了很久之后，再來看代碼，可能之前的理解全忘了，可是如果有這樣一份圖文并茂的筆記，我就會(huì)很快找回記憶。
另外，還有些工具，可以自動(dòng)將代碼轉(zhuǎn)化成類圖等，比如visual studio，可以自動(dòng)繪制類圖，Enterprise Architect也具有根據(jù)代碼生成類圖的功能。具有此類功能的軟件還有很多。有興趣可以搜索一下。
或者嘗試對(duì)原有的代碼，做些小的修改，來印證理解，也是不錯(cuò)的方法。
一個(gè)經(jīng)常調(diào)試的程序猿，鍵盤上F10,F11這些鍵大都?jí)牡谋容^快。
如果我講的這些，如對(duì)你有所啟發(fā)，也不妨點(diǎn)個(gè)贊或者再看，小小的鼓勵(lì)一下我。當(dāng)然你如愿意擴(kuò)散分享，那就感激不盡啦。
某日一好友，調(diào)侃我的筆名，說讀起來好像“抑菌”！嗨，還真是，不管了，“抑菌”就“抑菌”吧。
寫號(hào)以來，有小伙伴問：如何能快速提升編程能力？這感覺永遠(yuǎn)沒有正確答案，每個(gè)人都有自己的套路，今天就來聊聊我對(duì)這個(gè)問題的看法：
學(xué)會(huì)高效讀代碼，就是一個(gè)不錯(cuò)的辦法。閱讀代碼，可能和寫代碼一樣重要！
為什么要會(huì)讀代碼？
考慮這樣一些場(chǎng)景：-
Case 1: 你還在讀書，照著教程，照著例子，學(xué)習(xí)編程。剛開始，大概率是先讀別人的代碼，理解別人的代碼，而非一上來，就開始寫。
-
Case 2: 一個(gè)職場(chǎng)新人，一進(jìn)公司，就加入一個(gè)項(xiàng)目組，那項(xiàng)目代碼真是海了去了！然后老大可能給你一個(gè)小小的活，在現(xiàn)有基礎(chǔ)上，添加一個(gè)小功能。項(xiàng)目經(jīng)驗(yàn)少的童鞋，一下就傻眼了，特么的，這代碼這么多行，文件幾百上千！該從何入手呢？別說改了，看都看不懂！完了，試用期是不是就要被干掉？！
-
Case 3: 你進(jìn)了一個(gè)小公司，技術(shù)管理混亂，前任已閃人，你受命接任一個(gè)一坨翔一樣的項(xiàng)目，那代碼寫的真是云里霧里，工期又緊，老板又逼著出貨，怎么辦？閃人？可是下家會(huì)更好么？跳槽往往是從一個(gè)坑里，跳到另一個(gè)坑里。所以讀吧，總是要讀的。。。
-
Case n: ......
然而，理想很豐滿，現(xiàn)實(shí)很骨感！工作中，你寫代碼的時(shí)間可能只占工作時(shí)間很少很少的一部分，大部分時(shí)間你可能都是在閱讀已有的代碼，當(dāng)然除非這個(gè)項(xiàng)目從0到1都是你一個(gè)人干，可即便是自己寫代碼，也是漸進(jìn)增長(zhǎng)、不斷迭代的，也需要不斷反復(fù)閱讀自己寫的代碼。
再者，編程與寫文章，有異曲同工之處。編程與寫作相似之處，都是用語言表達(dá)寫作者的想法。
對(duì)于如何提升寫作，古人曾講：熟讀唐詩(shī)三百首，不會(huì)作詩(shī)也會(huì)吟?；叵雽W(xué)生時(shí)代，老師也常說：讀書破萬卷，下筆如有神！強(qiáng)調(diào)寫作需要大量閱讀，讀的多了，寫作能力也會(huì)相應(yīng)提升。閱讀之于寫作，相輔相成，互為促進(jìn)。
那么大量閱讀別人的代碼，也能提升自己的編程水平。閱讀代碼，個(gè)人覺得會(huì)有這樣些好處：
博采眾長(zhǎng)
優(yōu)秀的源碼，就如傳世佳作一樣，值得反復(fù)揣摩，細(xì)細(xì)品味。其編寫技巧、設(shè)計(jì)范式、架構(gòu)思想，都具有極大的學(xué)習(xí)借鑒價(jià)值。比如一些優(yōu)秀的開源項(xiàng)目：Linux內(nèi)核、lwIP、u-boot等等。這些作品都匯集了全球優(yōu)秀頂級(jí)程序員的思想智慧。都是非常優(yōu)秀的作品，廣為流傳，廣為應(yīng)用。如果能花些時(shí)間去閱讀理解一下其代碼，一定是大有裨益的。正如牛頓所說：如果我能比別人看的更遠(yuǎn)，只因?yàn)槲艺驹诰奕说募缟稀?br />
解決難題
編程生涯中，總會(huì)遇到一些感動(dòng)束手無策的場(chǎng)景。github，搜索都已無能為力的時(shí)候。如果說還沒遇到，那一定是機(jī)緣未到～比如做Linux編程的時(shí)候，遇到某個(gè)API出錯(cuò)，或許在網(wǎng)上查找半天，都找不到答案。實(shí)在找不到答案了，嘗試讀一讀內(nèi)核底層相關(guān)代碼，有時(shí)候就能發(fā)現(xiàn)問題的原因。
開闊視野
很多時(shí)候，日常工作內(nèi)容或許只是很小的領(lǐng)域，修復(fù)一些小的bug，修改一些小的功能等。如果只專注這些小的點(diǎn)，個(gè)人成長(zhǎng)一定會(huì)受到局限。如果能善于發(fā)現(xiàn)一些新的感興趣的領(lǐng)域，并去閱讀相關(guān)的代碼，則一定會(huì)提升自己的編程能力的。
所以為什么要讀代碼呢？
- 找bug
- review別人的代碼
- 學(xué)習(xí)
- 維護(hù)等
如何閱讀代碼呢？
這里聊聊我的一些體會(huì)，也未必都對(duì)，也未必適合其他的朋友。分享以作交流，如有其他想法，也歡迎大家留言交流。先粗后細(xì)
我一般拿到一份別人的代碼，會(huì)先去找這個(gè)項(xiàng)目的入口，先梳理個(gè)大概的脈絡(luò)。如單片機(jī)程序，一般會(huì)從下面幾個(gè)角度先掃一遍：- main在哪里？
- 開了幾個(gè)任務(wù)？
- 哪些是關(guān)鍵任務(wù)，主要功能鏈?zhǔn)窃趺礃拥模?/span>
- 任務(wù)間如何協(xié)作的？任務(wù)的執(zhí)行周期是如何安排的？
- 使用哪些硬件外設(shè)？
- 使用了哪些中斷？中斷與哪些任務(wù)發(fā)生了交互？
- 從軟件角度看，大致有哪些子系統(tǒng)？
- 是否有關(guān)鍵算法？
- 是否使用開源組件？
- ......
如果是Linux應(yīng)用程序，或者C 應(yīng)用程序，我也大致采用差不多的思路，先讀個(gè)大概，然后再細(xì)讀。比如對(duì)一個(gè)Linux應(yīng)用程序，會(huì)先了解這些方面的概要信息：
- 入口在哪個(gè)文件？一般都是main函數(shù)。
- 是否支持命令行傳啟動(dòng)參數(shù)？
- 是否是守護(hù)進(jìn)程？
- 開了哪些線程？
- 大致有哪些子系統(tǒng)？
- 使用了哪些開源組件？
- 是否使用驅(qū)動(dòng)，是否有通訊等？
- ......
善做筆記
在閱讀代碼的概要信息的時(shí)候，我比較喜歡做做筆記，畫畫圖。在閱讀代碼的時(shí)候，我比較喜歡先去研究代碼中的數(shù)據(jù)結(jié)構(gòu)。數(shù)據(jù)結(jié)構(gòu)往往會(huì)體現(xiàn)作者抽象問題、對(duì)問題建模的一些思路，并使用UML圖畫出來，剛開始可能都不去看每個(gè)函數(shù)是怎么實(shí)現(xiàn)的，只關(guān)心與這些數(shù)據(jù)結(jié)構(gòu)相關(guān)有哪些函數(shù)以及數(shù)據(jù)結(jié)構(gòu)間關(guān)系。“Bad programmers worry about the code. Good programmers worry about data structures and their relationships.”或許，有的朋友會(huì)說，UML不會(huì)。不會(huì)沒關(guān)系，用你習(xí)慣自己能看懂的方式都可以，而且即便是用UML也不必過分糾結(jié)繪制的圖是否嚴(yán)謹(jǐn)。甚至拿支筆在筆記上手繪也可以。不過個(gè)人更建議，盡量寫電子筆記，更容易保存和查閱。
— Linus Torvalds
閱讀某一個(gè)具體函數(shù)時(shí)，如果函數(shù)內(nèi)或者模塊內(nèi)具有狀態(tài)機(jī)，如果這部分是需要仔細(xì)理解的時(shí)候，我就會(huì)將其狀態(tài)機(jī)圖，先繪制出來。比如，之前寫的modbus協(xié)議中的狀態(tài)圖：
這樣做有個(gè)好處，邊繪圖邊去理解代碼，就會(huì)加速對(duì)代碼的理解，對(duì)我來說，我如果只用兩只眼睛盯著看，和一邊看一比畫圖效率會(huì)低很多。
這樣做還有一個(gè)好處，可以將理解以圖的形式記錄下來，如果光用圖還不能表達(dá)清楚的時(shí)候，我還會(huì)再加點(diǎn)文字描述。時(shí)間過了很久之后，再來看代碼，可能之前的理解全忘了，可是如果有這樣一份圖文并茂的筆記，我就會(huì)很快找回記憶。
善用工具
比如source insght, vs code等工具，都是提高閱讀代碼效率的好工具。盡量熟悉如何使用鍵盤控制閱讀跳轉(zhuǎn)，用熟了，效率倍增。另外，還有些工具，可以自動(dòng)將代碼轉(zhuǎn)化成類圖等，比如visual studio，可以自動(dòng)繪制類圖，Enterprise Architect也具有根據(jù)代碼生成類圖的功能。具有此類功能的軟件還有很多。有興趣可以搜索一下。
多多調(diào)試
如果遇到有的代碼，怎么看也理解不了。這時(shí)候可以試著加些打印日志，運(yùn)行調(diào)試一下，也可以使用調(diào)試工具進(jìn)行斷點(diǎn)、單步調(diào)試，觀察程序運(yùn)行的軌跡，數(shù)據(jù)的變化情況，可能就找到了突破口。或者嘗試對(duì)原有的代碼，做些小的修改，來印證理解，也是不錯(cuò)的方法。
一個(gè)經(jīng)常調(diào)試的程序猿，鍵盤上F10,F11這些鍵大都?jí)牡谋容^快。
總結(jié)一下
把自己閱讀代碼的一些體會(huì)分享一下，每個(gè)人都會(huì)有適合自己的方法。利用適合自己的方法，高效的閱讀代碼，是提升編程的一個(gè)行之有效的辦法。如果我講的這些，如對(duì)你有所啟發(fā)，也不妨點(diǎn)個(gè)贊或者再看，小小的鼓勵(lì)一下我。當(dāng)然你如愿意擴(kuò)散分享，那就感激不盡啦。
下載文檔
