⑴ 如何閱讀源代碼
一個大項目的源代碼，不要過份詳細的閱讀。大項目，其代碼量基本上是可以嚇死人的。過份的關注細節，常常會拘泥於細節，而忽略了整體框架。當你能夠看清框架的時候，亦花費了太多的時間。
因此，閱讀一個大項目的源代碼，其目的不在於欣賞代碼細節，而在於迅速看清項目整體框架的大概面貌：都有那些模塊，這些模塊是幹嘛的（不關心具體怎麼干），模塊之間的通訊機制大概是怎樣的，然後在考慮子模塊，通常只要掌握兩級子模塊就夠了。花上1，2天的時間掌握這一切，就達到了閱讀大項目源碼的目的。因為一旦你掌握了框架，你就可以按照這個框架實現這個項目，雖然和原項目全然不同，但是完成的需求卻是一樣的。
在軟體中，架構才是本質。
也許你指望詳細閱讀大項目源代碼能看到高質量的代碼，但是，大項目通常都是團隊的勞動成果，每個人的不同水平造就了代碼質量的高高低低，一個人在不同時間不同環境的代碼質量也是不同的。要指望在大片源碼面前找到高質量，簡直是天方夜譚。
也許你要從閱讀源碼中掌握某項技術細節，比如bsp，又或者換裝，那麼，最好的建議是查找相關的技術文檔以及文檔上所附帶的sample code，這種sample code一般不會附帶任何干擾，簡潔得只是為了證明該技術而存在的。如果沒有這些東西，而只能從大項目源碼中找的話，你提前先了解了框架，能更快的查找和定位到表達該技術的文件。但是通常都會比較不幸，因為你為了明白這一技術，通常要先理解混入其中的另一技術。
最後談談怎樣才能閱讀到高質量的源代碼。何謂高質量？是指演算法出人一表（比如某種o(1)的排序法）？還是採用了極端深奧的語言特性將某實現完美表達（比如模板的靈活運用）？無論是哪種，最好的來源是書，如《STL詳解》，或者《inside XX》這樣的東西。書的作者通常就是這些高質量代碼的作者，他會帶領你探索這些源碼背後的真相。
⑵ 一開始學習java有必要看源代碼嗎諸如Arraylist，Linkedlist的這些源代碼
你好，看源碼是可以幫助你以後寫代碼的。如果你是剛開始學，就沒有必要看那些東西。但是你要是有能力的話，看看還是很有幫助的，你說的那幾個類，等你學習到了，最好還是看看，可以加深你對他們的理解。
⑶ 大牛們是怎麼閱讀 android 系統源碼的
如果只是想看看一些常用類的實現, 在Android包管理器里把源碼下載下來, 隨便一個IDE配好Source Code的path看就行.
但如果想深入的了解Android系統, 那麼可以看下我的一些簡單的總結.
知識
Java
Java是AOSP的主要語言之一. 沒得說, 必需熟練掌握.
熟練的Android App開發
Linux
Android基於Linux的, 並且AOSP的推薦編譯環境是Ubuntu 12.04. 所以熟練的使用並了解Linux這個系統是必不可少的. 如果你想了解偏底層的代碼, 那麼必需了解基本的Linux環境下的程序開發. 如果再深入到驅動層, 那麼Kernel相關的知識也要具備.
Make
AOSP使用Make系統進行編譯. 了解基本的Makefile編寫會讓你更清晰了解AOSP這個龐大的項目是如何構建起來的.
Git
AOSP使用git+repo進行源碼管理. 這應該是程序員必備技能吧.
C++
Android系統的一些性能敏感模塊及第三方庫是用C++實現的, 比如: Input系統, Chromium項目(WebView的底層實現).
硬體
流暢的國際網路
AOSP代碼下載需要你擁有一個流暢的國際網路. 如果在下載代碼這一步就失去耐心的話, 那你肯定沒有耐心去看那亂糟糟的AOSP代碼. 另外, 好程序員應該都會需要一個流暢的Google.
一台運行Ubuntu 12.04的PC.
如果只是閱讀源碼而不做太多修改的話, 其實不需要太高的配置.
一台Nexus設備
AOSP項目默認只支持Nexus系列設備. 沒有也沒關系, 你依然可以讀代碼. 但如果你想在大牛之路走的更遠, 還是改改代碼, 然後刷機調試看看吧.
高品質USB線
要刷機時線壞了, 沒有更窩心的事兒了.
軟體
Ubuntu 12.04
官方推薦, 沒得選.
Oracle Java 1.6
注意不要用OpenJDK. 這是個坑, 官方文檔雖然有寫, 但還是單獨提一下.
安裝:
sudo apt-get install python-software-properties
sudo add-apt-repository ppa:webupd8team/java
sudo apt-get update
sudo apt-get install oracle-java6-installer
sudo apt-get install oracle-java6-set-default
Eclipse
估計會有不少人吐槽, 為什麼要用這個老古董. 其實原因很簡單, 合適. 剛開始搞AOSP時, 為了找到效率最優的工具, 我嘗試過Eclipse, IntelliJ IDEA, Vim+Ctags, Sublime Text+Ctags. 最終結果還是Eclipse. 主要優點有:
有語法分析 (快速准確的類, 方法跳轉).
支持C++ (IntelliJ的C++支持做的太慢了).
嵌入了DDMS, View Hierarchy等調試工具.
為了提高效率, 花5分鍾背下常用快捷鍵非常非常值得.
調整好你的classpath, 不要導入無用的代碼. 因為AOSP項目代碼實在是太多了. 當你還不需要看C++代碼時, 不要為項目添加C++支持, 建索引過程會讓你崩潰.
Intellij IDEA
開發App必備. 當你要調試系統的某個功能是, 常常需要迅速寫出一個調試用App, 這個時候老舊的Eclipse就不好用了. Itellij IDEA的xml自動補全非常給力.
巨人的肩膀
AOSP項目官方: https://source.android.com/source/index.html
這個一定要先讀. 項目介紹, 代碼下載, 環境搭建, 刷機方法, Eclipse配置都在這里. 這是一切的基礎.
Android官方Training: https://developer.android.com/training/index.html
這個其實是給App開發者看的. 但是裡面也有不少關於系統機制的介紹, 值得細讀.
老羅的Android之旅: http://blog.csdn.net/luoshengyang
此老羅非彼老羅. 羅升陽老師的博客非常有營養, 基本可以作為指引你開始閱讀AOSP源碼的教程. 你可以按照博客的時間順序一篇篇挑需要的看.但這個系列的博客有些問題:
早期的博客是基於舊版本的Android;
大量的代碼流程追蹤. 讀文章時你一定要清楚你在看的東西在整個系統處於什麼樣的位置.
Innost的專欄: http://blog.csdn.net/innost
鄧凡平老師也是為Android大牛, 博客同樣很有營養. 但是不像羅升陽老師的那麼系統. 更多的是一些技術點的深入探討.
Android Issues: http://code.google.com/p/android/issues/list
Android官方Issue列表. 我在開發過程中發現過一些奇怪的bug, 最後發現這里基本都有記錄. 當然你可以提一些新的, 有沒有人改就是另外一回事了.
Google: https://www.google.com
一定要能流暢的使用這個工具. 大量的相關知識是沒有人系統的總結的, 你需要自己搞定.
其它
代碼組織
AOSP的編譯單元不是和git項目一一對應的, 而是和Android.mk文件一一對應的. 善用mmm命令進行模塊編譯將節省你大量的時間.
Binder
這是Android最基礎的進程間通訊. 在Application和System services之間大量使用. 你不僅要知道AIDL如何使用, 也要知道如何手寫Binder介面. 這對你理解Android的Application和System services如何交互有非常重要的作用. Binder如何實現的倒不必著急看.
HAL
除非你對硬體特別感興趣或者想去方案公司上班, 否則別花太多時間在這一層.
CyanogenMod
這是一個基於AOSP的第三方Rom. 從這個項目的wiki里你能學到很多AOSP官方沒有告訴你的東西. 比如如何支持Nexus以外的設備.
DIA
這是一個Linux下畫UML的工具, 能夠幫你梳理看過的代碼.
XDA
http://www.xda-developers.com/
這里有最新資訊和最有趣的論壇.
⑷ 知道源代碼有什麼好處要源代碼用了干什麼
一、源代碼用途：
生成目標代碼，即計算機可以識別的代碼。
對軟體進行說明，即對軟體的編寫進行說明。為數不少的初學者，甚至少數有經驗的程序員都忽視軟體說明的編寫，因為這部分雖然不會在生成的程序中直接顯示，也不參與編譯。但是說明對軟體的學習、分享、維護和軟體復用都有巨大的好處。因此，書寫軟體說明在業界被認為是能創造優秀程序的良好習慣，一些公司也硬性規定必須書寫。
需要指出的是，源代碼的修改不能改變已經生成的目標代碼。如果需要目標代碼做出相應的修改，必須重新編譯。
二、源代碼好處：
1、它們能降低企業部署網路和各種服務的成本，如果採用開源方案，你只需要一台伺服器，其他的都可以免費，而用windows，你必須花錢購買操作系統(假設沒有盜版)。
2、可以在源代碼的基礎上進行二次開發，完善或豐富現有系統功能。
3、參考學習。通過分析源代碼，可以學習開發、了解開發者的思路，學習開發者如何通過巧妙的方式、演算法解決業務問題，閱讀源代碼是提高開發水平的快捷方式。
4、擁有源代碼，可以占據主動權。如果開發方在後期對運維或增加功能方面，報價遠超市場價，委託方有源代碼的話，可以考慮更換開發方，而不會因此造成整套軟體重寫。
⑸ 怎麼閱讀spring源碼
從HttpServletBean的init()進入，再到initWebApplicationContext()，再到refresh()，再到refreshBeanFactory()，再到finishRefresh()，直到伺服器啟動成功。不知道讀了多少遍，
但是源碼的東西實在的太多了，想要完全讀懂，完全理清頭緒，還差很遠啊。所以我只重點關注了兩塊內容，就是bean的定位載入解析注冊、bean的實例化兩大塊內容，其他地方稍作了解，沒有太過深入。
整個容器的啟動流程，都在AbstractApplicationContext的refresh()的模板方法中了。
復制代碼
1 public void refresh() throws BeansException, IllegalStateException {
2 synchronized (this.startupShutdownMonitor) {
3 // Prepare this context for refreshing.
4 prepareRefresh();
5
6 // Tell the subclass to refresh the internal bean factory.
7 beanFactory = obtainFreshBeanFactory();
8
9 // Prepare the bean factory for use in this context.
10 prepareBeanFactory(beanFactory);
11
12 try {
13 // Allows post-processing of the bean factory in context subclasses.
14 postProcessBeanFactory(beanFactory);
15
16 // Invoke factory processors registered as beans in the context.
17 (beanFactory);
18
19 // Register bean processors that intercept bean creation.
20 registerBeanPostProcessors(beanFactory);
21
22 // Initialize message source for this context.
23 initMessageSource();
24
25 // Initialize event multicaster for this context.
26 ();
27
28 // Initialize other special beans in specific context subclasses.
29 onRefresh();
30
31 // Check for listener beans and register them.
32 registerListeners();
33
34 // Instantiate all remaining (non-lazy-init) singletons.
35 (beanFactory);
36
37 // Last step: publish corresponding event.
38 finishRefresh();
39 }
40
41 catch (BeansException ex) {
42 // Destroy already created singletons to avoid dangling resources.
43 destroyBeans();
44
45 // Reset 'active' flag.
46 cancelRefresh(ex);
47
48 // Propagate exception to caller.
49 throw ex;
50 }
51 }
52 }
其實，我並沒有上來就看源碼，而是先從看書開始，稍微了解，知道了一些關鍵點，關鍵流程，自己產生了一堆疑問，然後帶著疑問去讀源碼，讀著讀著，發現有些疑問就這么解決了。
⑹ python的源碼值得去讀嗎
python的源碼值得去讀！
1.無論是有沒有其他語言的經驗，入門Python都很簡單。Python擁有簡單直觀的語法，方便的語法糖，以及豐富的第三方庫。只要一個基礎的Python教程，大家基本上都能無障礙的入門。
2.在入門之後，很多人對於進一步學習的建議都是「做項目」、「看源碼」，然而這樣的建議實際是較難實現的，自己執行的效率會很低。
3.對於初學者而言，Python入門很簡單。入門之後只靠基礎語法也完全可以做到平時寫寫腳本，解決自己工作、生活上的重復性勞動。想要什麼功能，基本上都能找到方便的庫。在只求應用，不求理解的情況下，很快就能實現日常表格處理、文件下載、郵件發送等功能。甚至像圖像處理、OCR這樣「高端」的功能也有對應的工具庫可以使用。
4.但是做到這種程度只是小打小鬧，想要真正的在開發工作中使用Python語言，或者是在GitHub上貢獻開源代碼，都是遠遠不夠的。這時候，初學者的常見問題主要集中在以下四點：
4.1學會了語法，但是不會應用。
仍然是用其他語言的邏輯在寫Python代碼，不是Pythonic的代碼。
4.2Python項目結構不合理。
缺少對更深入主題的研究，例如裝飾器、異常處理、多進程多線程、設計模式等。
5.傳統建議的解決方案
5.1對於初學者而言，應聘到一個使用Python語言做開發的團隊顯然是不現實的。那麼基本上項目的來源就是自己找的練手課題或者在GitHub上參與開源項目。
5.2自己找個項目進行練手可以說是效果最差的方式了。它實際上還是摸著石頭過河，接觸不到優秀的源碼和實現方法，也沒有人指導。最終也只是實現了功能而已，不論是代碼設計還是項目結構，都是閉門造車，提升有限。最大的作用也就是提高對語法、基本數據結構和標准庫的熟練程度。
⑺ 怎樣開始閱讀scikit-learn的源碼是否值得讀
作為scikit-learn的一個小contributor，來簡單說下個人看法吧。
首先，我認為這取決於題主本身在Python、機器學習方面的水平。因為題主沒有提供這方面信息，我也只能簡單介紹一下scikit-learn的現狀，讓題主自行判斷。
如果你理論基礎不錯，Python基礎也扎實，只是想看看那些機器學習演算法比較靠譜的實現，那讀scikit-learn的代碼應該是沒錯的。雖然不少常用演算法，比如decision tree用了cython，svm直接wrap了libsvm，但後期的代碼基本原則都是優先Python實現，只有Python實在太慢的時候才會考慮用cython加速。
另，如果真是初學者為了學機器學習的話，與其看別人代碼不如自己嘗試實現，不一定要效率高，但至少得能用。這樣比你一知半解的看完scikit-learn都有用。
⑻ 為什麼我們需要閱讀優秀開源軟體代碼
所幸的是，有相當多這類程序都開放了源代碼——它們也正是因此才得以在眾多聰明頭腦的協作下逐步達到今天的高度。開放源代碼，這意味著我們可以拆開每一顆螺釘，走近每一個零件，觀察每一個動作，觸摸每一根鏈條，轉動每一個齒輪（閱讀代碼，運行，調試）。我們可以像孩子一樣拆散它們，然後再拼到一起，可以擺弄它們的位置（修改）。在清楚一些時，我們可以把其中的一些零件用自己製作的替換掉（實驗），還可以把零件卸下來安在自己的機器里（復用）。
當然，最初我們很可能會被慎密而復雜的結構搞暈，但一旦開始漸漸理清它們的關系，我們會首先為那些按高品質行業標准打造的標准零件的規范贊不絕口（代碼規范，軟體包構建，介面設計），接著為那特殊零件賞心悅目的精湛工藝而驚嘆（語言技巧，數據結構/演算法的設計、選擇和實現，細節處理），然後為它們各司其職的明確分工和合理的安排而心服口服（模塊化設計，介面設計，代碼組織結構），其間我們會不斷得到零件上友好簡潔的標注的幫助（注釋和可讀性）。我們甚至會偶然為匠人們的幽默而捧服。有時我們會感到，那些聰明的傢伙在對我們微笑，用帶著一點挑釁卻又友好的語氣說道："嘿，怎麼樣？我的代碼寫得不錯吧？你能寫得更好么？"
後來，我們會發現諸多不完美，其中有些被證明是我們理解的問題，但有些確實需要改進，那麼就動手吧，這時，我們可以恭喜一下自己——我們已經跟上了這些聰明黑客的節奏，並且開始融入其中。
如果我們對歷史版本進行考古，會有更多發現，我們會看到今天我們面前的強壯青年經歷過怎樣的幼稚，看到他的成長軌跡。這時將會明白，羅馬不是一天建成的，更不是一個人建成的，那些代碼中包含的是大量黑客多年積累的努力和智慧，每一次修改和重構都吸取了上一版本的教訓。今天宏偉光鮮的羅馬城下，壓著無數舊代碼的屍體，而大師們也是在經歷這些風雨後才成為大師。所以，優秀的開源軟體代碼所示範的手段，是歷史之浪淘出的黃金（也有些帶有古董的痕跡，但不影響代碼的質量）。如果我們不去吸取這些血淚澆灌的營養，或許就免不了重流前人流過的血淚了。
總結一下，通過閱讀優秀的開源軟體代碼，我們能夠
可以修改、重寫後通過運行、調試進行實驗
找到可復用的代碼用在自己的項目中
學到代碼編寫、軟體包構建等工程規范
學到語言技巧，數據結構/演算法的設計、選擇和實現，以及細節處理方法
學到模塊化設計方法和良好規范的代碼組織方法
學到良好的編程風格和注釋規范
理解編程理論和原則
了解軟體發展規律，吸取前人經驗教訓
對它們進行改進當然，還有最不重要，也是最重要的：滿足好奇心
⑼ 為什麼以及如何閱讀源碼
對於這些問題，說到底主要是因為經驗不夠，而經驗主要從項目實踐中積累，所以招聘單位一般都會限定工作時間大於 3 年，因為這些人的項目經驗相對較豐富，項目中遇到的場景相對較多。
工作經驗的積累來自於年限與實踐，然而看源碼可以擴展我們的思路，這是變相增加我們經驗的不錯方法。雖然不能短時間內通過時間積累經驗，但是可以通過學習開源框架、開源項目來獲取。
另外進職場後一般都要先熟悉現有系統，如果有文檔還好，沒文檔的話就得自己去翻代碼研究。如果大家之前對閱讀源碼有經驗，那麼在研究新系統的代碼邏輯時就不會那麼費勁了。