要讀別人的代碼,應該如何入手?
01-28
Github是程序員學習的寶庫,但稍微上一點規模的項目(比如node.js的npm,vim的一些插件什麼的),看著那代碼樹層層的目錄就開始手足無措了,向各位前輩們請教,該如何去入手讀別人的代碼?如果可以的話,可不可以舉例說明?謝謝!
這是我通常讀開源代碼方式,希望對你有幫助
- 先用起來,覺得好用、有趣才有更強的動力去看源代碼
- 選一個自己較感興趣的功能,先自己設想一下實現思路
- 快速定位到代碼中關鍵點,主要通過程序與外界的交互方式,如:
- 代碼庫/框架或有二次開發介面的應用,可直接去找到感興趣介面的實現代碼
- 圖形界面應用,應該先找功能的滑鼠鍵盤事件的訂閱處,或者用按鈕等界面元素的名稱來查找代碼。不過很多應用(如,C/C++)的所有文本項,通常是存放在一個資源文件中,每個文本項對應一個宏,所以要用這個宏在代碼中搜索。
- 命令行應用,可以用控制台的輸出關鍵字元,再到代碼中搜索
- 資料庫應用,可以利用資料庫系統的事件跟蹤工具來探取每個操作的SQL命令,並用 SQL 命令到代碼查找。當然現在很多應用的 SQL 是通過 ORM 來生成的,可能這種方式會行不通
- Web 應用的前端與圖形界面應用的快速定位方式類似,因為瀏覽器開發人員工具現在都很方便很容定位到具體界面元素,也可去功能對就的 HTTP 請求特別是 AJAX 請求,然後再用請求URL到代碼中搜
- Web 應用的後端,現在通常是MVC類Web 框架,每一種框架開發的都有特定的目錄結構要先熟悉一下,另外還應該先找路由聲明方面的代碼文件。
- 3D 應用,要先找到主渲染循環,以及滑鼠、鍵盤事件訂閱的代碼。
- 大多數開源代碼都有單元測試,從單元測試是代碼模塊的詳細調用示例,看單元測試比看文檔要直接得多。
- 實在不行就按你設想的實現思路,通常代碼編輯器都有「在文件中查找」的功能,列出幾個關鍵字到代碼中搜索,至於查找什麼關鍵字這就得靠個人經驗了。
- 上述這些需要具有在文件及文件夾中用關鍵字搜索代碼文件內容的IDE、編輯器或工具。當然也可以直接用 github 的搜索功能
- 找到定位點,先大體閱讀該段代碼(函數或方法),用前面設想的實現思路,邊猜邊讀邊驗證
- 如果是 C/C++、Java、C# 等需要編譯的,一定要自己編譯一份出來調試,單元測試的環境最好也要搭配出來,從單元測試進行調試會更直接一些。
- 如果有 IDE 最好定調試斷點,進行單步調試,重點了解代碼中一些分支及循環的條件變數的變化情況。沒有 IDE 的情況下,也修改代碼用控制台或圖形界面上把這些條件變數的值給輸出來。
- 找出該段代碼的所有引用,可以用函數/方法名來搜,以此外延掌握每處調用的含義,很多 IDE 有查找所有引用的功能
- 通過調試信息中的調用堆棧,一層層的調用代碼都要看一下,並盡量追溯到程序的總入口處,如:main 方法。以此掌握整個程序的大體結構風格,這樣再去看該程序的其他功能代碼,就會顯得輕車熟路
- 如果代碼中依賴調用另外一些庫,要了解一下這些庫的開發文檔
- 如果代碼量比較巨大如 linux 內核或 chromium 之類的,要記得作記號。可使用 IDE 或編輯中的書籤功能。實在不行可以在代碼中注釋如://TODO:xxxx ,或者用文本文件或 evernote 來記錄。
- 試著改改代碼,比如調整一些常量的值,如條件判斷的邊界值,或者枚舉性的選項等,或者刪除一小段代碼,來看看會引起哪些變化,通過這些變化更容易推斷代碼邏輯。
- 中間可能會遇到一些無法理解難關,不要輕易打退堂鼓,很多時候並不見得有多難,可能只是暫時忽視了一些早已熟知的思路。那是代碼在玩捉迷藏,考驗一下你的耐性。
找到main方法開始。能有什麼訣竅啊
我來說一個不一樣的思路:
先不要看,先試著自己動手寫。看的是架構,就自己搭建一個簡易的空架子。看的是具體問題,就先簡化問題,自己寫解決方案。
等你動過手以後,你發現你眼前的源代碼,看著都有點眼熟。
-----------------
這個過程中,你要學會提問,一個好的問題是學習的關鍵。你一動手,就會發現很多問題,記下這些問題, 然後針對特定問題,去源碼找答案。 然後隨著自己動手越來越深入, 不斷更新這些答案。
那麼好了,最後這些答案,就是你對該源碼的解讀。程序員最不喜歡做的就是改需求和看別人的代碼。
有時候,迫不得已必須得看別人的代碼。
在看別人的代碼之前,你需要知道這段代碼的用意,即實現的目標。最快捷的方式,就是先讀他的文檔。
如果那個項目沒有文檔或者任何注釋的話,你就可以考慮放棄? 1. 一個項目的目錄和層級,肯定按照不同的功能區分的。認識每個不同的目錄和文件 ,文件夾的名字都是有意義的。2. 從主函數入口開始,了解各層目錄之間的調用關係,把握項目的整體邏輯
3. 代碼都是一個一個的函數和對象組成, 把他們當作一個小單元,精讀我閱讀過的源碼還不算多,但我覺得閱讀源碼無非就兩步:「理解程序結構」-&>「詳細分析代碼」;
概覽:大概清晰一下程序的「執行流程」,按照流程記錄下源碼的「結構層次」(大部分插件或優秀的源碼結構都是很清晰的);
細讀: 找到程序的「入口文件」,開始逐行分析,然後結合「結構層次」進行理解,順藤摸瓜就行了。細讀需要做好閱讀筆記;先好好看看這個代碼究竟是不是自動生成的。
你所見過最噁心的代碼片段是怎樣的? - 知乎用戶的回答Vim + ctags + cscope + tagbar + NERDTree
讀別人的代碼最好是用比較好用的IDE看, 個人感覺比vim看代碼要爽的多。我是用vs2013,層次,代碼結構一看就很清晰。關於內容,別人的東西,永遠是別人的,你要下很多功夫,臨摹或許是最笨的方法或許是最快的
跟他們的開發者要私藏的開發文檔啊,很多開源項目暴露出來的文檔都只是tutorial,看了也不可能明白代碼的架構的。
順藤摸瓜,由點及面。
一個單元一個單元摘取,看一部分改一部分,變成你自己的東西就能更容易吸收全部了。
最主要的是 要了解這段代碼要實現什麼 有時候是很頭大 看別人的代碼 沒有文檔 也看不懂為啥這樣實現 還不知道修改了 有木有後遺症 唉 麻煩
別人說方法了我說一下工具吧
首先干任何事之前你都需要ctags,這樣可以完美的實現代碼之間隨意跳轉。然後你需要一個能調用到ctags的編輯器,比如source insight或者sublime text + ctags插件,或者喜歡自虐的用vim然後好好梳理代碼結構好好看吧其實要了解源碼結構最快的方法是找個關鍵功能調試一下,一般都會有恍然大悟的感覺~
推薦閱讀:
※如何優雅的管理 github 上 star 的項目?
※如何看待大學CS課程中普遍存在的GOP(Github Oriented Programming)現象?
※GitHub入門與實踐
※Github 歡迎所有的持續集成工具
TAG:GitHub |