如何有效率地閱讀源碼以及修改源碼的技巧?

一名計算機研究生,剛進實驗室,發現一些工作需要在源碼的基礎上修改,增加一些自己所需要的功能。但是感覺讀源碼總是摸不著頭腦。PS:本人編程經驗不足。


閱讀別人的代碼作為開發人員是一件經常要做的事情。一個是學習新的編程語言的時候通過閱讀別人的代碼是一個最好的學習方法,另外是積累編程經驗。如果你有機會閱讀一些操作系統的代碼會幫助你理解一些基本的原理。還有就是在你作為一個質量保證人員或一個小領導的時候如果你要做白盒測試的時候沒有閱讀代碼的能力是不能完成相應的任務。最後一個就是如果你中途接手一個項目的時候或給一個項目做售後服務的時候是要有閱讀代碼的能力的。

  知識準備

  了解基礎知識,不要上來就閱讀代碼,打好基礎可以做到事半功倍的效果

  留備份,構造可運行的環境

  代碼拿到手之後的第一件事情是先做備份,最好是刻在一個光碟上,在代碼閱讀的時候一點不動代碼是很困難的一件事情,特別是你要做一些修改性或增強性維護的時候。而一旦做修改就可能發生問題,到時候要恢復是經常發生的事情,如果你不能很好的使用版本控制軟體那麼先留一個備份是一個最起碼的要求了。

  在做完備份之後最好給自己構造一個可運行的環境,當然可能會很麻煩,但可運行代碼和不可運行的代碼閱讀起來難度會差很多的。所以多用一點時間搭建一個環境是很值得的,而且我們閱讀代碼主要是為了修改其中的問題或做移植操作。不能運行的代碼除了可以學到一些技術以外,用處有限。

  找開始的地方

  做什麼事情都要知道從那裡開始,讀程序也不例外。在c語言里,首先要找到main()函數,然後逐層去閱讀,其他的程序無論是vb、delphi都要首先找到程序頭,否則你是很難分析清楚程序的層次關係。

  分層次閱讀

  在閱讀代碼的時候不要一頭就紮下去,這樣往往容易只見樹木不見森林,閱讀代碼比較好的方法有一點象二叉樹的廣度優先的遍歷。在程序主體一般會比較簡 單,調用的函數會比較少,根據函數的名字以及層次關係一般可以確定每一個函數的大致用途,將你的理解作為註解寫在這些函數的邊上。當然很難一次就將全部注 解都寫正確,有時候甚至可能是你猜測的結果,不過沒有關係這些註解在閱讀過程是不斷修正的,直到你全部理解了代碼為止。一般來說採用逐層閱讀的方法可以是 你系統的理解保持在一個正確的方向上。避免一下子扎入到細節的問題上。在分層次閱讀的時候要注意一個問題,就是將系統的函數和開發人員編寫代碼區分開。在 c, c++,java ,delphi中都有自己的系統函數,不要去閱讀這些系統函數,除非你要學習他們的編程方法,否則只會浪費你的時間。將系統函數表示出來,註明它們的作用 即可,區分系統函數和自編函數有幾個方法,一個是系統函數的編程風格一般會比較好,而自編的函數的編程風格一般比較會比較差。從變數名、行之間的縮進、注 解等方面一般可以分辨出來,另外一個是象ms c6++會在你編程的時候給你生成一大堆文件出來,其中有很多文件是你用不到了,可以根據文件名來區分一下時候是系統函數,最後如果你實在確定不了,那就 用開發系統的幫助系統去查一下函數名,對一下參數等來確定即可。

  寫註解

    寫註解是在閱讀代碼中最重要的一個步驟,在我們閱讀的源代碼一般來說是我們不熟悉的系統,閱讀別人的代碼一般會有幾個問題,1搞明白別人的編程思想不 是一件很容易的事情,即使你知道這段程序的思路的時候也是一樣。2閱讀代碼的時候代碼量一般會比較大,如果不及時寫註解往往會造成讀明白了後邊忘了前邊的 現象。3閱讀代碼的時候難免會出現理解錯誤,如果沒有及時的寫註解很難及時的發現這些錯誤。4不寫註解有時候你發生你很難確定一個函數你時候閱讀過,它的功能是什麼,經常會發生重複閱讀、理解的現象。

  好了,說一些寫註解的基本方法:

1.猜測的去寫,剛開始閱讀一個代碼的時候,你很難一下子就確定所有的函數的功能,不妨採用採用猜測的方法去寫註解,根 據函數的名字、位置寫一個大致的註解,當然一般會有錯誤,但你的註解實際是不但調整的,直到最後你理解了全部代碼。

2.按功能去寫,別把註解寫成語法說明 書,千萬別看到fopen就寫打開文件,看到fread就寫讀數據,這樣的註解一點用處都沒有,而應該寫在此處開發參數配置文件(****。dat)讀出 系統初始化參數。。。。。,這樣才是有用的註解。

3.在寫註解的使用另外要注意的一個問題是分清楚系統自動生成的代碼和用戶自 己開發的代碼,一般來說沒有必要寫系統自動生成的代碼。象delphi的代碼,我們往往要自己編寫一些自己的代碼段,還要對一些系統自動生成的代碼段進行 修改,這些代碼在閱讀過程是要寫註解的,但有一些沒有修改過的自動生成的代碼就沒有必要寫註解了。

4.在主要代碼段要寫較為詳細的註解。有一些函數或類在程序中起關鍵的作用,那麼要寫比較詳細的註解。這樣對你理解代碼有很大的幫助。

5.對你理解起來比較困難的地方要寫詳細的註解,在這些地方往往會有一些編程的技巧。不理解這些編程技巧對你以後的理解或移植會有問題。

6.寫中文註解。如果你的英文足夠的好,不用看這條了,但很多的人英文實在不怎麼樣,那就寫中文註解吧,我們寫註解是為了加快自己的理解速度。中文在大多數的時候比英文更適應中國人。與其寫一些誰也看不懂的英文註解還不如不寫。

  重複閱讀

  一次就可以將所有的代碼都閱讀明白的人是沒有的。至少我還沒有遇到過。反覆的去閱讀同一段代碼有助於得代碼的理解。一般來說,在第一次閱讀代碼的時候 你可以跳過很多一時不明白的代碼段,只寫一些簡單的註解,在以後的重複閱讀過程用,你對代碼的理解會比上一次理解的更深刻,這樣你可以修改那些註解錯誤的 地方和上一次沒有理解的對方。一般來說,對代碼閱讀3,4次基本可以理解代碼的含義和作用。

  運行並修改代碼

  如果你的代碼是可運行的,那麼先讓它運行起來,用單步跟蹤的方法來閱讀代碼,會提高你的代碼速度。代碼通過看中間變數了解代碼的含義,而且對 以後的修改會提供很大的幫助

  用自己的代碼代替原有代碼,看效果,但在之前要保留源代碼

  600行的一個函數,閱讀起來很困難,編程的人不是一個好的習慣。在閱讀這個代碼的時候將代碼進行修改,變成了14個函數。每一個大約是40-50 行左右.

———————————————源碼下載網站—————————————————————

跟你說幾個我常用的源碼下載網站

csdn(中文IT社區)它是集新聞、論壇、群組、Blog、文檔、下載、讀書、Tag、網摘、搜索、.NET、Java、遊戲、視頻、人才、外包、第二書店、《程序員》等多種項目於一體的大型綜合性IT門戶網站,源碼只是其中的一項,但是很實用 裡邊有很多大牛。

DevStore(源碼下載)主要是開發者服務平台,彙集國內外眾多第三方開發者服務,為開發者提供從設計開發到運營推廣一站式的解決方案,源碼和服務評測也是亮點,很專業,很實用,這裡邊聚集的都是開發者和PM,可以看看。

站長之家(網站源碼)針對個人站長,企業網管提供的資訊和源碼,包含的語言和類型也比較多。


讀代碼比寫代碼要難得多,尤其是讀垃圾代碼,各種思想變態,慘不忍睹,我讀老譚的代碼深有體會。

所以,有時候可能還真不如自己重寫一遍。

讀實驗室別人以前寫的代碼,我認為最重要的是了解程序功能,順著這個線索讀,可能會好些。但我覺得沒必要讀那麼細,因為那些代碼的質量我猜不會好到哪裡去。能了解各個函數的功能也就差不多了。

有一本書叫《閱讀代碼》,也許能給你更多提示,不過恐怕幫助有限。因為前提是你讀的代碼的質量到達一定程度才行。

修改代碼,流行的術語叫重構。這方面我寫過一些東西,不知道對你來說是否有參考價值。不過你說你缺少編程經驗,所以我覺得這些對你應該是有參考價值的。

重構 - 標籤 - garbageMan

評析 - 標籤 - garbageMan

目前我也在寫這樣的書。


看代碼最好有個文檔導讀什麼的,另外你要知道你想改什麼。找到入口,順藤摸瓜,忽略無關細節。

說個笑話,程序員最討厭的100件事:

0.寫文檔

1.寫注釋

10.別人不寫文檔

11.別人不寫注釋

ps:最近接手一個沒有文檔幾乎沒有注釋打包後9M多的項目源碼包,想死的心都快有了。


推薦閱讀:

讀源碼要注意哪些方面?有哪些值得推薦的經典源碼?
閱讀django源代碼?
HashMap的doubleCapacity()方法這樣寫妙在哪?
你對APM飛控的源碼做過哪些有意思的改動?
修改基於GPL協議的軟體,不公開源代碼,如何規避那個狗比協議?

TAG:編程 | 源代碼 | 源碼閱讀 |