如何快速閱讀代碼
如何快速閱讀代碼
程序員在做程序的時候需要敲打大量的代碼，這就需要程序員要有快速閱讀代碼的能力。那么，要怎么快速閱讀這些代碼呢?接下來學習啦小編來為你講講快速閱讀hadoop代碼的方法。
快速閱讀hadoop代碼的方法
一、學習hadoop基本使用和基本原理
這是第一個階段，你開始嘗試使用hadoop，從應用層面，對hadoop有一定了解，一旦你對hadoop的基本使用方法比較熟悉了，接下來可以嘗試了解它的內部原理，注意，不需要通過閱讀源代碼了解內部原理，只需看一些博客，書籍，比如《Hadoop權威指南》，對于HDFS而言，你應該知道它的基本架構以及各個模塊的功能;對于MapReduce而言，你應該知道其具體的工作流程，知道partition，shuffle，sort等工作原理，可以自己在紙上完整個畫完mapreduce的流程，越詳細越好。
在這個階段，建議你多看一些知名博客，多讀讀《hadoop權威指南》。如果你有實際項目驅動，那是再好不過了，理論聯(lián)系實際是最好的hadoop學習方法。
二、開始閱讀hadoop源代碼
這個階段是最困苦和漫長的，尤其對于那些沒有任何分布式經驗的人。 很多人這個階段沒有走完，就放棄了，最后停留在hadoop應用層面。
這個階段，第一件要做的事情是，選擇一個hadoop組件。如果你對分布式存儲感興趣，那么你可以選擇HDFS，如果你讀分布式計算感興趣，你可以選擇MapReduce，如果你對資源管理系統(tǒng)感興趣，你可以選擇YARN。
選擇好系統(tǒng)后，接下來的經歷是最困苦的。當你把hadoop源代碼導入eclipse或intellij idea，沏上一杯茶，開始準備優(yōu)哉游哉地看hadoop源代碼時，你懵逼了：你展開那數(shù)不盡的package和class，覺得無從下手，好不容易找到了入口點，然后你屁顛屁顛地通過eclipse的查找引用功能，順著類的調用關系一層層找下去，最后迷失在了代碼的海洋中，如同你在不盡的壓棧，最后棧溢出了，忘記在最初的位置。
如果你正在經歷這個過程，我的經驗如下：首先，你要摸清hadoop的代碼模塊，知道client，master，slave各自對應的模塊，并在閱讀源代碼過程中，時刻謹記你當前閱讀的代碼屬于哪一個模塊，會在哪個組件中執(zhí)行;之后你需要摸清各個組件的交互協(xié)議，也就是分布式中的RPC，這是hadoop自己實現(xiàn)的，你需要對hadoop RPC的使用方式有所了解，然后看各模塊間的RPC protocol，到此，你把握了系統(tǒng)的骨架，這是接下來閱讀源代碼的基礎;接著，你要選擇一個模塊開始閱讀，我一般會選擇Client，這個模塊相對簡單些，會給自己增加信心，為了在閱讀代碼過程中，不至于迷失自己，建議在紙上畫出類的調用關系，邊看邊畫，我記得我閱讀hadoop源代碼時，花了一疊紙。
在這個階段，建議大家多看一些源代碼分析博客和書籍。借助這些博客和書籍，你可以在前人的幫助下，更快地學習hadoop源代碼，節(jié)省大量時間。
這個階段最終達到的目的，是對hadoop源代碼整體架構和局部的很多細節(jié)，有了一定的了解。這個階段完成后，當你遇到問題或者困惑點時，可以迅速地在Hadoop源代碼中定位相關的類和具體的函數(shù)，通過閱讀源代碼解決問題，這時候，hadoop源代碼變成了你解決問題的參考書。
三、根據(jù)需求，修改源代碼。
這個階段，是驗證你閱讀源代碼成效的時候。你根據(jù)leader給你的需求，修改相關代碼完成功能模塊的開發(fā)。在修改源代碼過程中，你發(fā)現(xiàn)之前閱讀源代碼仍過于粗糙，這時候你再進一步深入閱讀相關代碼，彌補第二個階段中薄弱的部分。
當然，很多人不需要經歷第三個階段，僅僅第二階段就夠了：一來能夠通過閱讀代碼解決自己長久以來的技術困惑，滿足自己的好奇心，二來從根源上解決解決自己遇到的各種問題。 這個階段，沒有太多的參考書籍或者博客，多跟周圍的同事交流，通過代碼review和測試，證明自己的正確性。
7個提高代碼質量的個技巧
1.測試驅動開發(fā)(TDD)
如果說要找一個最能提高代碼質量同時還要減少bug的實踐練習恐怕就非TDD莫屬了。它的優(yōu)點是適用于任何類型的項目和敏捷開發(fā)。其歷史可以追溯到很早以前，但是直到XP的普及它才漸漸為人所知。當作為能自動化構建和測試實踐的持續(xù)集成周期的一部分運作的時候，它被稱為單元測試。
很多開發(fā)人員并不知道該怎么提高這方面的能力，這需要培訓和教育。而且這是一個學習和積累的過程，不要想著能一夜吃成個胖子。
2.驗收測試驅動開發(fā)(ATDD)
這是基于TDD單元測試之后的一個新的水平。這不但表明了驗收標準，而且還能在開發(fā)工作開始之前自動執(zhí)行開發(fā)需求。在很多情況下，需要專業(yè)測試人員和客戶攜手共同參與到測試中去。
3.持續(xù)集成(CI)
這能確保新代碼不會干擾到已經存在的代碼。如果再加上TDD和ATDD一起創(chuàng)建一個自動化、可重復的的測試套件，將會大幅度提高其使用價值。
4.結對編程
有關于結對編程的爭論似乎已經偃旗息鼓了，同樣的人們實際應用的例子也越來越少。這不可謂不是一個遺憾。因為在即時的代碼審查上，兩個腦袋總比一個管用。它也允許開發(fā)人員將注意力全部灌注到手頭的工作上——不必分心于電話、郵件、短信等等，因為我們的partner會搞定。
5.代碼審查
如果沒辦法結對編程，那么退而求其次，至少得進行一次代碼審查。最好代碼一寫好就能落實到位一個輕量級流程的代碼審查。我們在學校里學的那種又大又正規(guī)的流程其實并不實際——只有NASA( 美國宇航局)這種不差錢的土豪才買得起。所以換個輕量級的流程，意味著只需20%的成本就能享受80%的相同效果。
6.靜態(tài)分析工具
以前人人都不看好所謂的靜態(tài)分析工具?，F(xiàn)在則好了很多，雖然它們仍然并不能真正替代代碼審查，但是其使用成本比較低。當然可能需要購買許可證，但是一旦將它們設置進系統(tǒng)中之后，以后每一次我們輸入代碼，它們都會一絲不茍兢兢業(yè)業(yè)地檢查并且快速提示發(fā)現(xiàn)的所有錯誤。
7.編碼標準
老實說我并不怎么喜歡編碼標準。從我的經驗來看，很多團隊在討論編碼標準上面浪費了太多的時間，而且一旦確定了某種標準，這往往會損害一部分開發(fā)人員的利益。不過如果我們能克服這些問題，那么絕對會有意想不到的效果。
首先建立一個討論小組——應該以一種面對面的形式，不要通過電子郵件和電話——討論出編碼標準里應該包含哪些內容。找到需要討論的地方，規(guī)分為不同的類別：少許定位為必選項目，推薦項目的數(shù)量可以較前者多點，候選項目則可以更多。在候選組里的需要經過深思熟慮之后才能放到推薦組和必選組中。剩下的第四組則是明確不能成為編程標準的內容。
每隔三至四個月檢查一下這些標準，看看有沒有需要從候選組提升到推薦組，或者從推薦組放到必選組的，要是發(fā)現(xiàn)什么已經不適應當前工作的項目，那就盡快刪除或者降級。
此外，我們不應該將編碼標準當做代碼審查的一部分，而是兩手都要抓，兩手都要硬，萬一不得不遺漏其中之一，可以借助自動化工具，例如運行靜態(tài)分析工具，自動執(zhí)行代碼標準來檢查代碼。
快速閱讀代碼相關文章：
5.如何做到快速閱讀