程序員提高閱讀代碼能力的幾個方法

ybhuangfugui 2021-08-16 01:00:51 阅读数:925

本文一共[544]字,预计阅读时长:1分钟~
程序 提高 能力 方法

關注+星標公眾,不錯過精彩內容

來源 | 嵌入式客棧

有小夥伴問:如何能快速提昇編程能力?這感覺永遠沒有正確答案,每個人都有自己的套路,今天就來聊聊我對這個問題的看法:

學會高效讀代碼,就是一個不錯的辦法。閱讀代碼,可能和寫代碼一樣重要!

為什麼要會讀代碼?

考慮這樣一些場景:

  • Case 1: 你還在讀書,照著教程,照著例子,學習編程。剛開始,大概率是先讀別人的代碼,理解別人的代碼,而非一上來,就開始寫。

這是我YY的一個學寫代碼的學習模型,所以讀了,理解了,在自己就可以發揮了,然後書本上、他人的知識,就流進了自己的腦瓜了。

  • Case 2: 一個職場新人,一進公司,就加入一個項目組,那項目代碼真是海了去了!然後老大可能給你一個小小的活,在現有基礎上,添加一個小功能。項目經驗少的童鞋,一下就傻眼了,特麼的,這代碼這麼多行,文件幾百上千!該從何入手呢?別說改了,看都看不懂!完了,試用期是不是就要被幹掉?!

  • Case 3: 你進了一個小公司,技術管理混亂,前任已閃人,你受命接任一個一坨翔一樣的項目,那代碼寫的真是雲裏霧裏,工期又緊,老板又逼著出貨,怎麼辦?閃人?可是下家會更好麼?跳槽往往是從一個坑裏,跳到另一個坑裏。所以讀吧,總是要讀的。。。

  • Case n: ......

學校往往教授的是如何寫代碼,可能從沒有教如何讀代碼。

然而,理想很豐滿,現實很骨感!工作中,你寫代碼的時間可能只占工作時間很少很少的一部分,大部分時間你可能都是在閱讀已有的代碼,當然除非這個項目從0到1都是你一個人幹,可即便是自己寫代碼,也是漸進增長、不斷迭代的,也需要不斷反複閱讀自己寫的代碼。

再者,編程與寫文章,有异曲同工之處。編程與寫作相似之處,都是用語言錶達寫作者的想法。

對於如何提昇寫作,古人曾講:熟讀唐詩三百首,不會作詩也會吟。回想學生時代,老師也常說:讀書破萬卷,下筆如有神!强調寫作需要大量閱讀,讀的多了,寫作能力也會相應提昇。閱讀之於寫作,相輔相成,互為促進。

那麼大量閱讀別人的代碼,也能提昇自己的編程水平。閱讀代碼,個人覺得會有這樣些好處:

博采眾長

優秀的源碼,就如傳世佳作一樣,值得反複揣摩,細細品味。其編寫技巧、設計範式、架構思想,都具有極大的學習借鑒價值。比如一些優秀的開源項目:Linux內核、lwIP、u-boot等等。這些作品都匯集了全球優秀頂級程序員的思想智慧。都是非常優秀的作品,廣為流傳,廣為應用。如果能花些時間去閱讀理解一下其代碼,一定是大有裨益的。

正如牛頓所說:如果我能比別人看的更遠,只因為我站在巨人的肩上。

解决難題

編程生涯中,總會遇到一些感動束手無策的場景。github,搜索都已無能為力的時候。如果說還沒遇到,那一定是機緣未到~

比如做Linux編程的時候,遇到某個API出錯,或許在網上查找半天,都找不到答案。實在找不到答案了,嘗試讀一讀內核底層相關代碼,有時候就能發現問題的原因。

開闊視野

很多時候,日常工作內容或許只是很小的領域,修複一些小的bug,修改一些小的功能等。如果只專注這些小的點,個人成長一定會受到局限。

如果能善於發現一些新的感興趣的領域,並去閱讀相關的代碼,則一定會提昇自己的編程能力的。

所以為什麼要讀代碼呢?

  • 找bug

  • review別人的代碼

  • 學習

  • 維護等

如何閱讀代碼呢?

這裏聊聊我的一些體會,也未必都對,也未必適合其他的朋友。分享以作交流,如有其他想法,也歡迎大家留言交流。

先粗後細

我一般拿到一份別人的代碼,會先去找這個項目的入口,先梳理個大概的脈絡。如單片機程序,一般會從下面幾個角度先掃一遍:

  • main在哪裏?

  • 開了幾個任務?

  • 哪些是關鍵任務,主要功能鏈是怎麼樣的?

  • 任務間如何協作的?任務的執行周期是如何安排的?

  • 使用哪些硬件外設?

  • 使用了哪些中斷?中斷與哪些任務發生了交互?

  • 從軟件角度看,大致有哪些子系統?

  • 是否有關鍵算法?

  • 是否使用開源組件?

  • ......

先不關心很細的函數具體怎麼寫,數據結構是如何設計的?這樣,我大致能先有一個總體認識,然後在對自己感興趣的進行細讀。當然如果是review別人的代碼則就另當別論了。

如果是Linux應用程序,或者C++應用程序,我也大致采用差不多的思路,先讀個大概,然後再細讀。比如對一個Linux應用程序,會先了解這些方面的概要信息:

  • 入口在哪個文件?一般都是main函數。

  • 是否支持命令行傳啟動參數?

  • 是否是守護進程?

  • 開了哪些線程?

  • 大致有哪些子系統?

  • 使用了哪些開源組件?

  • 是否使用驅動,是否有通訊等?

  • ......

如果項目采用cmake或者makefile進行組織的,那麼先閱讀下makefile也會是了解項目概要信息的一個比較好的切入點。

善做筆記

在閱讀代碼的概要信息的時候,我比較喜歡做做筆記,畫畫圖。在閱讀代碼的時候,我比較喜歡先去研究代碼中的數據結構。數據結構往往會體現作者抽象問題、對問題建模的一些思路,並使用UML圖畫出來,剛開始可能都不去看每個函數是怎麼實現的,只關心與這些數據結構相關有哪些函數以及數據結構間關系。

“Bad programmers worry about the code. Good programmers worry about data structures and their relationships.”

— Linus Torvalds

或許,有的朋友會說,UML不會。不會沒關系,用你習慣自己能看懂的方式都可以,而且即便是用UML也不必過分糾結繪制的圖是否嚴謹。甚至拿支筆在筆記上手繪也可以。不過個人更建議,盡量寫電子筆記,更容易保存和查閱。

閱讀某一個具體函數時,如果函數內或者模塊內具有狀態機,如果這部分是需要仔細理解的時候,我就會將其狀態機圖,先繪制出來。比如,之前寫的modbus協議中的狀態圖:

這樣做有個好處,邊繪圖邊去理解代碼,就會加速對代碼的理解,對我來說,我如果只用兩只眼睛盯著看,和一邊看一比畫圖效率會低很多。

這樣做還有一個好處,可以將理解以圖的形式記錄下來,如果光用圖還不能錶達清楚的時候,我還會再加點文字描述。時間過了很久之後,再來看代碼,可能之前的理解全忘了,可是如果有這樣一份圖文並茂的筆記,我就會很快找回記憶。

善用工具

比如source insght, vs code等工具,都是提高閱讀代碼效率的好工具。盡量熟悉如何使用鍵盤控制閱讀跳轉,用熟了,效率倍增。

另外,還有些工具,可以自動將代碼轉化成類圖等,比如visual studio,可以自動繪制類圖,Enterprise Architect也具有根據代碼生成類圖的功能。具有此類功能的軟件還有很多。有興趣可以搜索一下。

多多調試

如果遇到有的代碼,怎麼看也理解不了。這時候可以試著加些打印日志,運行調試一下,也可以使用調試工具進行斷點、單步調試,觀察程序運行的軌迹,數據的變化情况,可能就找到了突破口。

或者嘗試對原有的代碼,做些小的修改,來印證理解,也是不錯的方法。

一個經常調試的程序猿,鍵盤上F10,F11這些鍵大都壞的比較快。

總結一下

把自己閱讀代碼的一些體會分享一下,每個人都會有適合自己的方法。利用適合自己的方法,高效的閱讀代碼,是提昇編程的一個行之有效的辦法。

如果我講的這些,如對你有所啟發,也不妨點個贊或者再看,小小的鼓勵一下我。當然你如願意擴散分享,那就感激不盡啦。

------------ END ------------


●嵌入式專欄精選教程

●精選匯總 | ST工具、下載編程工具

●精選匯總 | 嵌入式軟件設計與開發

●精選匯總 | STM32、MCU、單片機

歡迎關注我的公眾號回複“加群”按規則加入技術交流群,回複“1024”查看更多內容。

歡迎關注我的視頻號:

點擊“閱讀原文”查看更多分享,歡迎點分享、收藏、點贊、在看。

版权声明:本文为[ybhuangfugui]所创,转载请带上原文链接,感谢。 https://gsmany.com/2021/08/20210816010025128s.html