大家有什麼讀代碼的習慣？

12-29

想了解大家都代碼有沒有什麼習慣。我是個編程純新手，目前在研究obj-c和cocos2d，在培養自己養成習慣看程序畫一個parent-children關係圖（cocos2d里的）、一個類繼承圖；因為我發現有些程序看的很懂，過一段時間回頭看，結構就有一點混亂了，如果有這兩個圖的幫助，比較一目了然，自己編程的時候也不會搞得太暈。想請教各位前輩有沒有什麼可以借鑒的習慣、方法。
啊！！！寫到這裡胳膊被iPhone電了一下=_=

其實，除了類圖這類描述靜態結構的圖以外，你還需要的使用的另一項工具，那就是序列圖，就像下面這種：

序列圖和類圖相比最大的好處就是，它描述的時程序運行時的動態過程。它能夠清記錄下來一個重要流程的運行細節，裡面有哪些模塊參與了，分別起了什麼作用。

類圖和序列圖，一靜一動，同時使用性價比很高的。

有的時候也不需要畫特別正規的序列圖，太費時間，可以弄個簡易版本的，使用文本就行，比如下面這個例子：

main

a.b1()

b1.c()

a.b2()
a.b3()
...

通過這種嵌套列表的方式，同樣能夠記錄下來重要流程的運行細節。

還有個問題，無法清楚的判斷運行流程的細節怎麼辦。如果你已經了解了代碼的大致結構，最好是使用 debug 工具，通過單步調試的方式檢查程序的運行流程。

1.理清整體框架，從類層次入手

2.單個模塊突破，從數據結構看

3.模塊之間的交互

大一的時候就思考如何讀一份陌生的代碼。最近有一些想法。

從github上獲得原代碼。

看git歷史

拖進source tree，查看提交代碼的歷史更改。

一定要跑起來

想辦法運行。不運行起來的代碼，並不能看懂。

找合適的代碼

找到合適的代碼。如果直接看nginx應該看不懂，如果看一個幾十行的http server，卻是可以看懂的，是可以讓人理解的。最重要的一點是理解代碼的歷史，理解代碼的發展過程，從小到大的過程，理解功能為什麼一步一步的添加。

代碼指紋，聯繫作者

代碼指紋，代碼不是憑空變出來的，寫代碼的人會在博客和書上留下痕迹，留下思路，留下的論文。聯繫方式，其實解決很多疑惑的辦法是直接聯繫作者。

一定要會調試

單步調試，調試列印變數。寫python，寫Objective-C很重要的一點是調試好。

畫UML

UML圖不只是沒用的圖，他們是告訴你代碼如何分析的方面，畫UML類圖。動態圖，靜態圖，類圖，部署圖，用例圖。。。。。。。。

唯物主義辯證法

唯物主義辯證法分析法。聯繫的觀點看代碼，發展的觀點看代碼，矛盾的主要方面的看代碼。詳細見唯物主義辯證法。

仿寫

這個耗費時間比較長。但是照著寫一遍，一步一步是最有益處的。

上班法

學生黨應該找個地方上班去，去找自己想做的東西的公司。

買書

知識比錢知值錢，時間比錢值錢。書可以節約很多時間。

通過運行的程序了解程序運行的流程，並在此基礎上理解代碼。針對複雜的函數調用，找到源頭，從整體上畫出函數調用關係，最後再細緻到每行代碼的意義。針對好的代碼（比如看函數名就知道函數作用），邊猜邊理解，效率最高。

之前寫過一篇不正規的文章，可以給你參考下。

如何去閱讀開源代碼

為什麼要去閱讀開源代碼

學習到一些小技巧
借鑒別人的實現思路
更深入地了解有助於更好地發現使用中的問題
針對自己的項目對開源代碼進行友好地改進
閱讀開源代碼可以提升自己代碼質量

在閱讀之前需要做什麼

了解該代碼解決什麼問題
了解如何使用該代碼
對相關的技術知識有一定的了解

如何去閱讀

1. 選擇正確的版本閱讀，

開源代碼經過多年的積累，作者從單一功能開始做起，後來往往包含了太多的功能和使用的小技巧，如果你一開始不是很熟悉的話，你可能第一眼就會很懵逼，而如果你從最初的發行版代碼或者你能夠看懂的發行版開始閱讀，並以此向後版本閱讀，你會有種原來造個輪子也不是那麼困難。特別推薦這篇文章，我在一開始閱讀的過程中也參考了該文章中的方式。

如何以「正確的姿勢」閱讀開源軟體代碼

2. 結合demo，在恰當的時候log一下

Demo

每一個開源項目應該都會提供Demo的，裡面通常包含一些常見用法，或者一些用法的簡單介紹；結合Demo你至少可以再一次認識該項目以及其使用和解決了什麼問題。而或許有些demo還跑不起來，這個時候就需要你去用已有知識解決問題，往往在這個解決問題的過程中你會有些額外的發現與認識。

Log

Log是你在測試或者調試代碼過程中的一些列印標記，而把log和斷點結合起來，會讓你對代碼執行時長和代碼執行順序有個準確的了解。log告訴你什麼時候調用，斷點可以看到斷點處以後接著調用哪些函數，了解了這些調用時機就可以輔助我們理解代碼。

3. 第一次閱讀不要太糾結細節

很多時候你會糾結代碼中細微巧妙的實現，然後在糾結過程中耽誤了很多時間，這樣往往會導致效率低下，而且容易引起閱讀疲勞，所以更好的做法就是第一遍閱讀大致了解下就可以，能夠了解到整體的構架或者框架設計更好，如果能夠畫出輔助圖也更好，沒有必要去深究具體的細節。

4. 在了解了整體架構的情況下看具體實現

熟能生巧，想要一遍閱讀就弄明白整個開源項目，除非你有過人的代碼天賦，在上一點的基礎之上還要再來一遍，這一遍最好認真些，然後對照自己畫過的輔助圖去看看具體實現。

5. 把大模塊拆成小模塊

其實大部分開源代碼都有一個共同特點，模塊化，一個小模塊往往只實現一兩個功能，所以這樣分成小模塊看起來更快速理解，也更容易讓你清晰認識。而如果你總是以一個整體去看代碼，以一個系統的眼光去看的話你往往會混亂你的大腦，結果只是效率低下，很快又忘了。

6. 在閱讀的同時自己動手去寫相關的實現

好記性不如爛筆頭，如果僅僅是看懂的話你會很快忘記，而且閱讀開源代碼也不是一時半刻能夠全部弄懂。這個時候就需要你在自己理解的基礎上實現它。或者你能夠換一種思路來實現，這樣更好。

7. 不要太相信網上別人寫的代碼解析一類的

很多別人的代碼解析文章，都很不錯，不過這些可能都是別人消化過之後的東西，他能夠理解多少你我都說不清楚，可能很深，也可能很淺，也可能會有理解偏差，如果你盲目相信而自己不去深究，可能你對該代碼也有錯誤的認識，再加上你從該作者那裡吸收消化了又少了一點，所以最後導致你還是似懂非懂，可能別人和別人交流的時候你能夠說出來個四四五五，但終究還是理解不深。

8. 善用搜索

你在閱讀的過程中難免遇到難題，那就直接去搜索吧。Google一下，你所有的難題可能都能夠搜索到，實在搜索不到，你還是可以給作者發郵件的。

一些方法

對源代碼寫一點註解。
看issues，可能幫助你快速理解作者為什麼這麼設計。
和別人交流，這可能是檢驗你消化了多少代碼的最佳方式。
畫流程圖，閱讀的時候畫一畫圖還是很有幫助的

關於Readme

大部分開源代碼都是放在Github上的，一份開源代碼你最先接觸它的就是readme，通常readme中會告訴你怎麼去安裝、怎麼去使用、以及一些其他的信息。我個人覺得可以看下這篇文章，他告訴我們如何去寫一個開源項目的readme，如何編寫開源項目的 README 文檔明白了如何去寫，那麼閱讀起來就可以直接略過次要，直接跳躍到主要信息。

一點建議

不鼓勵額外造輪子
建議提issues或者pull request
對作者懷有感恩
有更好的想法建議聯繫作者
懷著好奇心

在閱讀一個開源項目之後寫一篇文章，記錄下自己的理解與體會，不久後你可以再翻開看看，或許自己有了新的理解，對自己的知識體系也會有所完善。這裡也就解釋了為什麼那麼多人喜歡寫文章，或者並不是特意寫出來，而是記錄自己的學習的過程，或許對一些新手有一點指導和幫助，不過更多的是自己以後看到時有個對比。

額外話

學習是一個漫長的過程，過程就需要堅持，閱讀開源代碼也是一樣，一旦你完成了第一份代碼的閱讀，並從中學到一些東西以後你會發現第二份、第三份會越來越順暢。不過前提是你全面認識，並深刻理解了。希望對大家技術提高有一點點幫助，我也是算是總結下經驗，畢竟自己也正在閱讀代碼中，真心從開源代碼學到很多東西。而且自己也有計劃寫一些代碼解析，希望對你有用。

追本溯源，從頭開始