高效讀代碼，就是一個不錯的辦法。閱讀代碼，可能和寫代碼一樣重要！
  為什么要會讀代碼？
  考慮這樣一些場景：
  Case 1:你還在讀書，照著教程，照著例子，學習編程。剛開始，大概率是先讀別人的代碼，理解別人的代碼，而非一上來，就開始寫。
  Case 2:一個職場新人，一進企業(yè)，就加入一個項目組，那項目代碼真是海了去了！然后老大可能給你一個小小的活，在現(xiàn)有基礎(chǔ)上，添加一個小功能。項目經(jīng)驗少的童鞋，一下就傻眼了，特么的，這代碼這么多行，文件幾百上千！該從何入手呢？別說改了，看都看不懂！完了，試用期是不是就要被干掉？！
  Case 3:你進了一個小企業(yè)，技術(shù)管理混亂，前任已閃人，你受命接任一個一坨翔一樣的項目，那代碼寫的真是云里霧里，工期又緊，老板又逼著出貨，怎么辦？閃人？可是下家會更好么？跳槽往往是從一個坑里，跳到另一個坑里。所以讀吧，總是要讀的。。。
  Case n:......
  學校往往教授的是如何寫代碼，可能從沒有教如何讀代碼。
  然而，理想很豐滿，現(xiàn)實很骨感！工作中，你寫代碼的時間可能只占工作時間很少很少的一部分，大部分時間你可能都是在閱讀已有的代碼，當然除非這個項目從0到1都是你一個人干，可即便是自己寫代碼，也是漸進增長、不斷迭代的，也需要不斷反復閱讀自己寫的代碼。
  再者，編程與寫文章，有異曲同工之處。編程與寫作相似之處，都是用語言表達寫作者的想法。
  對于如何提升寫作，古人曾講：熟讀唐詩三百首，不會作詩也會吟。回想學生時代，老師也常說：讀書破萬卷，下筆如有神！強調(diào)寫作需要大量閱讀，讀的多了，寫作能力也會相應提升。閱讀之于寫作，相輔相成，互為促進。
  那么大量閱讀別人的代碼，也能提升自己的編程水平。閱讀代碼，個人覺得會有這樣些好處：
  博采眾長
  優(yōu)秀的源碼，就如傳世佳作一樣，值得反復揣摩，細細品味。其編寫技巧、設(shè)計范式、架構(gòu)思想，都具有極大的學習借鑒價值。比如一些優(yōu)秀的開源項目：Linux內(nèi)核、lwIP、u-boot等等。這些作品都匯集了全球優(yōu)秀程序員的思想智慧。都是非常優(yōu)秀的作品，廣為流傳，廣為應用。如果能花些時間去閱讀理解一下其代碼，一定是大有裨益的。
  正如牛頓所說：如果我能比別人看的更遠，只因為我站在巨人的肩上。
  解決難題
  編程生涯中，總會遇到一些感動束手無策的場景。github，搜索都已無能為力的時候。如果說還沒遇到，那一定是機緣未到～
  比如做Linux編程的時候，遇到某個API出錯，或許在網(wǎng)上查找半天，都找不到答案。實在找不到答案了，嘗試讀一讀內(nèi)核底層相關(guān)代碼，有時候就能發(fā)現(xiàn)問題的原因。
  開闊視野
  很多時候，日常工作內(nèi)容或許只是很小的領(lǐng)域，修復一些小的bug，修改一些小的功能等。如果只專注這些小的點，個人成長一定會受到局限。
  如果能善于發(fā)現(xiàn)一些新的感興趣的領(lǐng)域，并去閱讀相關(guān)的代碼，則一定會提升自己的編程能力的。
  所以為什么要讀代碼呢？
  找bug
  review別人的代碼
  學習
  維護等
  如何閱讀代碼呢？
  這里聊聊我的一些體會，也未必都對，也未必適合其他的朋友。分享以作交流，如有其他想法，也歡迎大家留言交流。
  先粗后細
  我一般拿到一份別人的代碼，會先去找這個項目的入口，先梳理個大概的脈絡(luò)。如單片機程序，一般會從下面幾個角度先掃一遍：
  main在哪里？
  開了幾個任務？
  哪些是關(guān)鍵任務，主要功能鏈是怎么樣的？
  任務間如何協(xié)作的？任務的執(zhí)行周期是如何安排的？
  使用哪些硬件外設(shè)？
  使用了哪些中斷？中斷與哪些任務發(fā)生了交互？
  從軟件角度看，大致有哪些子系統(tǒng)？
  是否有關(guān)鍵算法？
  是否使用開源組件？
  ......
  先不關(guān)心很細的函數(shù)具體怎么寫，數(shù)據(jù)結(jié)構(gòu)是如何設(shè)計的？這樣，我大致能先有一個總體認識，然后在對自己感興趣的進行細讀。當然如果是review別人的代碼則就另當別論了。
  如果是Linux應用程序，或者C++應用程序，我也大致采用差不多的思路，先讀個大概，然后再細讀。比如對一個Linux應用程序，會先了解這些方面的概要信息：
  入口在哪個文件？一般都是main函數(shù)。
  是否支持命令行傳啟動參數(shù)？
  是否是守護進程？
  開了哪些線程？
  大致有哪些子系統(tǒng)？
  使用了哪些開源組件？
  是否使用驅(qū)動，是否有通訊等？
  ......
  如果項目采用cmake或者makefile進行組織的，那么先閱讀下makefile也會是了解項目概要信息的一個比較好的切入點。
  善做筆記
  在閱讀代碼的概要信息的時候，我比較喜歡做做筆記，畫畫圖。在閱讀代碼的時候，我比較喜歡先去研究代碼中的數(shù)據(jù)結(jié)構(gòu)。數(shù)據(jù)結(jié)構(gòu)往往會體現(xiàn)作者抽象問題、對問題建模的一些思路，并使用UML圖畫出來，剛開始可能都不去看每個函數(shù)是怎么實現(xiàn)的，只關(guān)心與這些數(shù)據(jù)結(jié)構(gòu)相關(guān)有哪些函數(shù)以及數(shù)據(jù)結(jié)構(gòu)間關(guān)系。
  “Bad programmers worry about the code.Good programmers worry about data structures and their relationships.”
  —Linus Torvalds
  或許，有的朋友會說，UML不會。不會沒關(guān)系，用你習慣自己能看懂的方式都可以，而且即便是用UML也不必過分糾結(jié)繪制的圖是否嚴謹。甚至拿支筆在筆記上手繪也可以。不過個人更建議，盡量寫電子筆記，更容易保存和查閱。
  閱讀某一個具體函數(shù)時，如果函數(shù)內(nèi)或者模塊內(nèi)具有狀態(tài)機，如果這部分是需要仔細理解的時候，我就會將其狀態(tài)機圖，先繪制出來。
  這樣做有個好處，邊繪圖邊去理解代碼，就會加速對代碼的理解，對我來說，我如果只用兩只眼睛盯著看，和一邊看一比畫圖效率會低很多。
  這樣做還有一個好處，可以將理解以圖的形式記錄下來，如果光用圖還不能表達清楚的時候，我還會再加點文字描述。時間過了很久之后，再來看代碼，可能之前的理解全忘了，可是如果有這樣一份圖文并茂的筆記，我就會很快找回記憶。
  善用工具
  比如source insght,vs code等工具，都是提高閱讀代碼效率的好工具。盡量熟悉如何使用鍵盤控制閱讀跳轉(zhuǎn)，用熟了，效率倍增。
  另外，還有些工具，可以自動將代碼轉(zhuǎn)化成類圖等，比如visual studio，可以自動繪制類圖，Enterprise Architect也具有根據(jù)代碼生成類圖的功能。具有此類功能的軟件還有很多。有興趣可以搜索一下。
  多多調(diào)試
  如果遇到有的代碼，怎么看也理解不了。這時候可以試著加些打印日志，運行調(diào)試一下，也可以使用調(diào)試工具進行斷點、單步調(diào)試，觀察程序運行的軌跡，數(shù)據(jù)的變化情況，可能就找到了突破口。
  或者嘗試對原有的代碼，做些小的修改，來印證理解，也是不錯的方法。
  一個經(jīng)常調(diào)試的程序猿，鍵盤上F10,F11這些鍵大都壞的比較快。
  總結(jié)一下
  把自己閱讀代碼的一些體會分享一下，每個人都會有適合自己的方法。利用適合自己的方法，高效的閱讀代碼，是提升編程的一個行之有效的辦法。