如何快速閱讀代碼

來源：查字典速讀網  發布時間： 2017-04-17

  程序員在做程序的時候需要敲打大量的代碼，這就需要程序員要有快速閱讀代碼的能力。那么，要怎么快速閱讀這些代碼呢?接下來小編來為你講講快速閱讀hadoop代碼的方法。

  一、學習hadoop基本使用和基本原理

  這是第一個階段，你開始嘗試使用hadoop，從應用層面，對hadoop有一定了解，一旦你對hadoop的基本使用方法比較熟悉了，接下來可以嘗試了解它的內部原理，注意，不需要通過閱讀源代碼了解內部原理，只需看一些博客，書籍，比如《Hadoop權威指南》，對于HDFS而言，你應該知道它的基本架構以及各個模塊的功能;對于MapReduce而言，你應該知道其具體的工作流程，知道partition，shuffle，sort等工作原理，可以自己在紙上完整個畫完mapreduce的流程，越詳細越好。

  在這個階段，建議你多看一些知名博客，多讀讀《hadoop權威指南》。如果你有實際項目驅動，那是再好不過了，理論聯系實際是最好的hadoop學習方法。

  二、開始閱讀hadoop源代碼

  這個階段是最困苦和漫長的，尤其對于那些沒有任何分布式經驗的人。 很多人這個階段沒有走完，就放棄了，最后停留在hadoop應用層面。

  這個階段，第一件要做的事情是，選擇一個hadoop組件。如果你對分布式存儲感興趣，那么你可以選擇HDFS，如果你讀分布式計算感興趣，你可以選擇MapReduce，如果你對資源管理系統感興趣，你可以選擇YARN。

  選擇好系統后，接下來的經歷是最困苦的。當你把hadoop源代碼導入eclipse或intellij idea，沏上一杯茶，開始準備優哉游哉地看hadoop源代碼時，你懵逼了：你展開那數不盡的package和class，覺得無從下手，好不容易找到了入口點，然后你屁顛屁顛地通過eclipse的查找引用功能，順著類的調用關系一層層找下去，最后迷失在了代碼的海洋中，如同你在不盡的壓棧，最后棧溢出了，忘記在最初的位置。

  如果你正在經歷這個過程，我的經驗如下：首先，你要摸清hadoop的代碼模塊，知道client，master，slave各自對應的模塊，并在閱讀源代碼過程中，時刻謹記你當前閱讀的代碼屬于哪一個模塊，會在哪個組件中執行;之后你需要摸清各個組件的交互協議，也就是分布式中的RPC，這是hadoop自己實現的，你需要對hadoop RPC的使用方式有所了解，然后看各模塊間的RPC protocol，到此，你把握了系統的骨架，這是接下來閱讀源代碼的基礎;接著，你要選擇一個模塊開始閱讀，我一般會選擇Client，這個模塊相對簡單些，會給自己增加信心，為了在閱讀代碼過程中，不至于迷失自己，建議在紙上畫出類的調用關系，邊看邊畫，我記得我閱讀hadoop源代碼時，花了一疊紙。

  在這個階段，建議大家多看一些源代碼分析博客和書籍。借助這些博客和書籍，你可以在前人的幫助下，更快地學習hadoop源代碼，節省大量時間。

  這個階段最終達到的目的，是對hadoop源代碼整體架構和局部的很多細節，有了一定的了解。這個階段完成后，當你遇到問題或者困惑點時，可以迅速地在Hadoop源代碼中定位相關的類和具體的函數，通過閱讀源代碼解決問題，這時候，hadoop源代碼變成了你解決問題的參考書。

  三、根據需求，修改源代碼。

  這個階段，是驗證你閱讀源代碼成效的時候。你根據leader給你的需求，修改相關代碼完成功能模塊的開發。在修改源代碼過程中，你發現之前閱讀源代碼仍過于粗糙，這時候你再進一步深入閱讀相關代碼，彌補第二個階段中薄弱的部分。

  當然，很多人不需要經歷第三個階段，僅僅第二階段就夠了：一來能夠通過閱讀代碼解決自己長久以來的技術困惑，滿足自己的好奇心，二來從根源上解決解決自己遇到的各種問題。 這個階段，沒有太多的參考書籍或者博客，多跟周圍的同事交流，通過代碼review和測試，證明自己的正確性。

  1.測試驅動開發(TDD)

  如果說要找一個最能提高代碼質量同時還要減少bug的實踐練習恐怕就非TDD莫屬了。它的優點是適用于任何類型的項目和敏捷開發。其歷史可以追溯到很早以前，但是直到XP的普及它才漸漸為人所知。當作為能自動化構建和測試實踐的持續集成周期的一部分運作的時候，它被稱為單元測試。

  很多開發人員并不知道該怎么提高這方面的能力，這需要培訓和教育。而且這是一個學習和積累的過程，不要想著能一夜吃成個胖子。

  2.驗收測試驅動開發(ATDD)

  這是基于TDD單元測試之后的一個新的水平。這不但表明了驗收標準，而且還能在開發工作開始之前自動執行開發需求。在很多情況下，需要專業測試人員和客戶攜手共同參與到測試中去。

  3.持續集成(CI)

  這能確保新代碼不會干擾到已經存在的代碼。如果再加上TDD和ATDD一起創建一個自動化、可重復的的測試套件，將會大幅度提高其使用價值。

  4.結對編程

  有關于結對編程的爭論似乎已經偃旗息鼓了，同樣的人們實際應用的例子也越來越少。這不可謂不是一個遺憾。因為在即時的代碼審查上，兩個腦袋總比一個管用。它也允許開發人員將注意力全部灌注到手頭的工作上不必分心于電話、郵件、短信等等，因為我們的partner會搞定。

  5.代碼審查

  如果沒辦法結對編程，那么退而求其次，至少得進行一次代碼審查。最好代碼一寫好就能落實到位一個輕量級流程的代碼審查。我們在學校里學的那種又大又正規的流程其實并不實際只有NASA( 美國宇航局)這種不差錢的土豪才買得起。所以換個輕量級的流程，意味著只需20%的成本就能享受80%的相同效果。

  6.靜態分析工具

  以前人人都不看好所謂的靜態分析工具。現在則好了很多，雖然它們仍然并不能真正替代代碼審查，但是其使用成本比較低。當然可能需要購買許可證，但是一旦將它們設置進系統中之后，以后每一次我們輸入代碼，它們都會一絲不茍兢兢業業地檢查并且快速提示發現的所有錯誤。

  7.編碼標準

  老實說我并不怎么喜歡編碼標準。從我的經驗來看，很多團隊在討論編碼標準上面浪費了太多的時間，而且一旦確定了某種標準，這往往會損害一部分開發人員的利益。不過如果我們能克服這些問題，那么絕對會有意想不到的效果。

  首先建立一個討論小組應該以一種面對面的形式，不要通過電子郵件和電話討論出編碼標準里應該包含哪些內容。找到需要討論的地方，規分為不同的類別：少許定位為必選項目，推薦項目的數量可以較前者多點，候選項目則可以更多。在候選組里的需要經過深思熟慮之后才能放到推薦組和必選組中。剩下的第四組則是明確不能成為編程標準的內容。

  每隔三至四個月檢查一下這些標準，看看有沒有需要從候選組提升到推薦組，或者從推薦組放到必選組的，要是發現什么已經不適應當前工作的項目，那就盡快刪除或者降級。

  此外，我們不應該將編碼標準當做代碼審查的一部分，而是兩手都要抓，兩手都要硬，萬一不得不遺漏其中之一，可以借助自動化工具，例如運行靜態分析工具，自動執行代碼標準來檢查代碼。