閱讀開源碼

Ⅰ 如何閱讀程序源代碼

閱讀源代碼的第一個工具，就是你手中的code base。把它編譯出來，運行它，加log，試著修改一些數據和代碼，看看有什麼變化。

第二個重要的工具就是debugger，而debugger最重要的功能是獲取call stack。在你感興趣的use case里pause一下，在你不知道有什麼用的函數里加個斷點，顯示出來的call stack都能讓你對系統有更清晰的認識。

一個軟體系統就是一個小宇宙。別期待有什麼高明的文檔。要把自己當成探求自然真理的物理學家。

必須找好切入點。你要解決什麼問題。是要fix bug；還是要把這個系統和其它模塊集成；還是要增加新功能。物理學家沒有上來就研究整個宇宙的，必須選好分支。
如果你有一個猜想，但是又和你的目標關聯不太大，那就堅持這個猜想，直到出現明顯反例。物理學有很多這樣的例子，和數學不同，為了旁支猜想投入過多研究是不明智的。
如果有明顯證據證明你的某個旁支猜想大錯特錯，你就要放棄主要目標，暫時把解決旁支猜想作為主要目標。比如，你本來以為某個結構是LRU的cache，結果發現怎麼做都不對，那就先放棄原來的目標，專門研究這個結構的用途。
對於旁支猜想的不斷切換，要做好自己的task stack保留。在旁支猜想解決之後，要根據結論盡快回到上次中斷的任務。

復雜的軟體系統更像一個動物，待久了你會了解它的脾性。有些是通過邏輯，有些是通過感覺。玩車的尚且有這種感覺，我們玩的東西比車復雜上萬倍，就更不能對它缺乏感情投入。（這也是我不愛做企業開發的原因，我不愛養個爬行類當寵物，還是貓貓狗狗的親切。）

Ⅱ 關於閱讀開源項目的源碼，有哪些經驗值得分享

閱讀源代碼的過程中，最重要的一點是反復地重復。ttserver來源只是解讀台詞時,我將不熟悉C,有很多奇怪的代碼ttserver習慣,所以硬著頭皮vim線看它一遍又一遍,有些不明白的地方,看到十幾次,真正理解,可能被視為量變引起質變。

所以我一直認為，寫一篇文章，你可以毫無問題地閱讀和理解，這是一個好主意。

Ⅲ 為什麼以及如何閱讀源碼

對於這些問題，說到底主要是因為經驗不夠，而經驗主要從項目實踐中積累，所以招聘單位一般都會限定工作時間大於 3 年，因為這些人的項目經驗相對較豐富，項目中遇到的場景相對較多。
工作經驗的積累來自於年限與實踐，然而看源碼可以擴展我們的思路，這是變相增加我們經驗的不錯方法。雖然不能短時間內通過時間積累經驗，但是可以通過學習開源框架、開源項目來獲取。
另外進職場後一般都要先熟悉現有系統，如果有文檔還好，沒文檔的話就得自己去翻代碼研究。如果大家之前對閱讀源碼有經驗，那麼在研究新系統的代碼邏輯時就不會那麼費勁了。

Ⅳ 如何去閱讀並學習一些優秀的開源框架的源碼

對於開發者來說，社區里豐富的開源代碼其實是筆極為寶貴的財富。如果能充分利用好開放源代碼的資源，不僅可以掌握多種編程方法，提高實踐能力，還能獲得好的思想，激發編程靈感。開源代碼怎麼學以及怎樣才能學好是大家經常關注的話題，日前，在問答網站知乎上，有人拋出了「如何更有效地學習開源項目的代碼？」的話題，眾技術好手各抒己見，CSDN軟體研發頻道對本文內容進行了整理，方便大家學習與參考。盛大創新研究院研究員 庄表偉：學習開源 盡可能在代碼里找答案 庄表偉提供了以下9個建議：1.在下載源代碼之後，首先要跑起來，編譯通過、正常運行；2.在你覺得最有可能運行到的地方，設置斷點或者拋出異常，這樣，就能夠找到一個項目在正常運行時的入口點；3.從入口點所在的那個源文件開始閱讀，逐步把握整個項目是如何啟動起來；4.隨便改點代碼，看看會不會報錯，如果報錯，會從哪裡報錯；5.試著把報錯屏蔽、修復、或者繞開；6.嘗試理解一個系統的內部結構，多少組成部分，主線模塊是哪些？輔助模塊是哪些？7.從實際需要出發，修改這個項目，滿足自己的某一個小的需求。(注意在此之前，盡量不要在網路上找答案)；8.看看相關的討論與心得，是否與自己的理解相一致；9.提交bug fix或者某個新的功能代碼。在學習開源的過程中，有幾個方面會獲得大量收獲，1.架構與模式；2.開源社區常見的一些慣用法；3.相關領域的結構與演算法。總結一點：學習開源，盡可能在代碼里找答案，而不是在代碼之外找答案，那些都是二手的，而且很可能不準確。互聯網評論員 朱曉陽：從簡單做起 理論聯系實踐朱曉陽對此發表了兩點看法：首先，從簡單做起。剛開始的時候學習一些領域內基礎理論，然後找一些簡單的東西去實現，不能一開始就去找開源項目。建議大家經常動手寫一些小程序，如改進宿舍網路登錄客戶端等。積小成多，能顯著提高自己的編程能力。其次，學習的知識一定要和自己生活或工作有聯系，這樣才會有樂趣或動力。互聯網評論員孫竟：先構想一個想做的項目首先，構想一個想做的項目（比如論壇、博客、微博等）；然後，思考需要什麼功能，應該怎麼去實現，盡可能包括各種細節，有必要時記錄下來；最後，去找個類似的開源應用，看看它是怎麼實現的，和你的想法有什麼差異，有什麼可以學習或需要改進的地方。互聯網草根hqman：我的5個建議：1.反復地使用軟體，熟釋軟體的組成文件和軟體功能，注意IE地址欄內的地址變化；2.打開資料庫文件或存放數據的XML文件，參照數據字典了解各個表和欄位的數據含意；如果沒有數據字典，就運行軟體輸入數據，參照所輸入的數據，了解各個表和欄位的數據含義；3.利用Visio進行反向工程，將類圖抽出來；4.研究類之間的關系，注釋各個類的屬性和方法，弄清程序的整體框架；5.另開一個項目，按照軟體開發的流程，將代碼分段復制進新的項目，進行編譯調試，關注一些實現細節，學習一些編程的技巧。在讀研究生張偉：在校學生空閑時間多參加一下比賽張偉的建議是大家在空閑時間多參加一些比賽。一個完整的項目，不管再小，只要做完了，就會有收獲。多看一些比較大的開源項目源代碼，每次看完後都會受益匪淺。從網上成熟的開源代碼里，可以學到很多的設計思想。他認為，從項目入手，以項目為驅動，可激勵自己進步。當然，是否一定需要看開源代碼，這將取決於個人的興趣和需要。畫出程序流程圖 理解程序流程思想CSDN博客專家i_like_cpp：曾在CSDN分享了《如何將源代碼學好》的博文，對此，他給出了四點建議：1. 畫出整個程序的流程圖，理解整個程序流程的思想。畫流程圖的方式更讓人很直接的理解程序的整體流程，而不會被代碼所干擾，讓程序員總體上把握整個程序；2. 對流程各節點（函數或過程）的理解，流程的每一節點是構成整個流程的不可缺少的部份；3.再把流程和流程各節點串起來理解整個程序，可能的話最好寫出讀書筆記；4. 如果想深刻的學習到源代碼的精髓所在，請寫一個相近的程序進行操練。理解了這個程序並不表明掌握了這個程序，只有在操練一個相近的程序時，才知道你到底理解了多少，掌握了多少。編後語：源代碼的學習是一個從整體到不斷細化的過程，是一個極為繁瑣的過程同時也是一個不斷認清事物本源的過程。

Ⅳ 如何閱讀源碼包

在Eclipse查看開發包jar源碼的方法如下：
1.選擇項目，右鍵中單擊【Properties】
2.【java Build Path】-【Configure Build Path】-【Libraries】，在下面找到如：Guava-r09.jar包，展開它，選擇【Source attachment】，單擊右邊的【Edit…】按鈕。
3.在打開的窗口中，可選擇文件(jar\zip)，目錄或工作空間中的jar文件，在這里我選擇External Folder…，選擇如E:/java project/guava即可。

4.連續單擊【OK】兩次回到Eclipse工作平台即可。

有源碼，把它加到eclipse中：

方法1：直接用壓縮軟體打開相應的jar包，然後把源碼拖進去壓縮一下，最後選中工程刷新一下ok。

方法2：右擊referenced

Ⅵ 如何閱讀源代碼

一個大項目的源代碼，不要過份詳細的閱讀。大項目，其代碼量基本上是可以嚇死人的。過份的關注細節，常常會拘泥於細節，而忽略了整體框架。當你能夠看清框架的時候，亦花費了太多的時間。
因此，閱讀一個大項目的源代碼，其目的不在於欣賞代碼細節，而在於迅速看清項目整體框架的大概面貌：都有那些模塊，這些模塊是幹嘛的（不關心具體怎麼干），模塊之間的通訊機制大概是怎樣的，然後在考慮子模塊，通常只要掌握兩級子模塊就夠了。花上1，2天的時間掌握這一切，就達到了閱讀大項目源碼的目的。因為一旦你掌握了框架，你就可以按照這個框架實現這個項目，雖然和原項目全然不同，但是完成的需求卻是一樣的。
在軟體中，架構才是本質。
也許你指望詳細閱讀大項目源代碼能看到高質量的代碼，但是，大項目通常都是團隊的勞動成果，每個人的不同水平造就了代碼質量的高高低低，一個人在不同時間不同環境的代碼質量也是不同的。要指望在大片源碼面前找到高質量，簡直是天方夜譚。
也許你要從閱讀源碼中掌握某項技術細節，比如bsp，又或者換裝，那麼，最好的建議是查找相關的技術文檔以及文檔上所附帶的sample code，這種sample code一般不會附帶任何干擾，簡潔得只是為了證明該技術而存在的。如果沒有這些東西，而只能從大項目源碼中找的話，你提前先了解了框架，能更快的查找和定位到表達該技術的文件。但是通常都會比較不幸，因為你為了明白這一技術，通常要先理解混入其中的另一技術。
最後談談怎樣才能閱讀到高質量的源代碼。何謂高質量？是指演算法出人一表（比如某種o(1)的排序法）？還是採用了極端深奧的語言特性將某實現完美表達（比如模板的靈活運用）？無論是哪種，最好的來源是書，如《STL詳解》，或者《inside XX》這樣的東西。書的作者通常就是這些高質量代碼的作者，他會帶領你探索這些源碼背後的真相。

Ⅶ 如何正確的閱讀源代碼

除了閱讀代碼以外, 沒有更好的方法. 7.在尋找bug時, 請從問題的表現形式到問題的根源來分析代碼. 不要沿著不相關的路徑(誤入歧途). 8.我們要充分利用調試器|編譯器給出的警告或輸出的符號代碼|系統調用跟蹤器|資料庫結構化查詢語言的日誌機制|包轉儲工具和Windows的消息偵查程序,
定出的bug的位置. 9.對於那些大型且組織良好的系統, 您只需要最低限度地了解它的全部功能, 就能夠對它做出修改. 10.當向系統中增加新功能時, 首先的任務就是找到實現類似特性的代碼, 將它作為待實現功能的模板. 11.從特性的功能描述到代碼的實現, 可以按照字元串消息, 或使用關鍵詞來搜索代碼. 12.在移植代碼或修改介面時, 您可以通過編譯器直接定位出問題涉及的范圍, 從而減少代碼閱讀的工作量. 13.進行重構時, 您從一個能夠正常工作的系統開始做起, 希望確保結束時系統能夠正常工作. 一套恰當的測試用例(test
case)可以幫助您滿足此項約束. 14.閱讀代碼尋找重構機會時, 先從系統的構架開始, 然後逐步細化, 能夠獲得最大的效益. 15.代碼的可重用性是一個很誘人, 但難以理解與分離, 可以試著尋找粒度更大一些的包, 甚至其他代碼. 16.在復查軟體系統時, 要注意, 系統是由很多部分組成的, 不僅僅只是執行語句. 還要注意分析以下內容:
文件和目錄結構|生成和配置過程|用戶界面和系統的文檔. 18.可以將軟體復查作為一個學習|講授|援之以手和接受幫助的機會. ++++++++++++++++++++ 第二章: 基本編程元素 ++++++++++++++++++++ 19.第一次分析一個程序時, main是一個好的起始點. 20.層疊if-else if-…-else序列可以看作是由互斥選擇項組成的選擇結構. 21.有時, 要想了解程序在某一方面的功能, 運行它可能比閱讀源代碼更為恰當. 22.在分析重要的程序時, 最好首先識別出重要的組成部分. 23.了解局部的命名約定, 利用它們來猜測變數和函數的功能用途. 24.當基於猜測修改代碼時, 您應該設計能夠驗證最初假設的過程. 這個過程可能包括用編譯器進行檢查|引入斷言|或者執行適當的測試用例. 25.理解了代碼的某一部分, 可能幫助你理解餘下的代碼. 26.解決困難的代碼要從容易的部分入手. 27.要養成遇到庫元素就去閱讀相關文檔的習慣; 這將會增強您閱讀和編寫代碼的能力. 28.代碼閱讀有許多可選擇的策略: 自底向上和自頂向下的分析|應用試探法和檢查注釋和外部文檔, 應該依據問題的需要嘗試所有這些方法. 29.for (i=0; i 30.涉及兩項不等測試(其中一項包括相等條件)的比較表達式可以看作是區間成員測試. 31.我們經常可以將表達式應用在樣本數據上, 藉以了解它的含義. 32.使用De Morgan法則簡化復雜的邏輯表達式. 33.在閱讀邏輯乘表達式時, 問題可以認為正在分析的表達式以左的表達式均為true; 在閱讀邏輯和表達式時, 類似地,

Ⅷ 大家第一個閱讀的開源代碼是什麼

我們知道，很多作家出名不容易，很多作家成名之前都閱讀過大量的優秀文學作品，經過長期的閱讀和寫作積累，慢慢的沉澱，日積月累我，慢慢的才有可能寫出一些優秀的作品。 作為程序員與此類似，很多程序員也需要不斷積累，不斷學習，而且需要閱讀大量的優秀程序或產品，經過不斷閱讀和實踐積累，或是通過其他能夠讓自己在這條道路成長的各種途徑不斷磨練，重現，重組學習，不斷超越，然後可能寫出好的程序或產品。

好的代碼應該是實用的、高效的和穩定的。最重要的是，最好的選擇必須符合要求，讓讀者感到非常舒服，並能在第一時間找到他們想看的東西！！

3.我對讀的建議就是：代碼只讀最優秀的。不優秀的代碼，要麼原樣使用，要麼小修小補使用，要麼乾脆重寫。

總之，我覺得閱讀代碼，要讀就讀laravel這樣的。什麼時候讀、怎麼讀呢？最好是逼到有什麼非讀不可的需求的時候再讀，讀的時候一切以完成需求為目標，效率杠杠的。