程序员在做程序的时候需要敲打大量的代码，这就需要程序员要有快速阅读代码的能力。那么，要怎么快速阅读这些代码呢?接下来51自学小编来为你讲讲快速阅读hadoop代码的方法。

　　快速阅读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和测试，证明自己的正确性。

　　7个提高代码质量的个技巧

　　1.测试驱动开发(TDD)

　　如果说要找一个最能提高代码质量同时还要减少bug的实践练习恐怕就非TDD莫属了。它的优点是适用于任何类型的项目和敏捷开发。其历史可以追溯到很早以前，但是直到XP的普及它才渐渐为人所知。当作为能自动化构建和测试实践的持续集成周期的一部分运作的时候，它被称为单元测试。

　　很多开发人员并不知道该怎么提高这方面的能力，这需要培训和教育。而且这是一个学习和积累的过程，不要想着能一夜吃成个胖子。

　　2.验收测试驱动开发(ATDD)

　　这是基于TDD单元测试之后的一个新的水平。这不但表明了验收标准，而且还能在开发工作开始之前自动执行开发需求。在很多情况下，需要专业测试人员和客户携手共同参与到测试中去。

　　3.持续集成(CI)

　　这能确保新代码不会干扰到已经存在的代码。如果再加上TDD和ATDD一起创建一个自动化、可重复的的测试套件，将会大幅度提高其使用价值。

　　4.结对编程

　　有关于结对编程的争论似乎已经偃旗息鼓了，同样的人们实际应用的例子也越来越少。这不可谓不是一个遗憾。因为在即时的代码审查上，两个脑袋总比一个管用。它也允许开发人员将注意力全部灌注到手头的工作上——不必分心于电话、邮件、短信等等，因为我们的partner会搞定。

　　5.代码审查

　　如果没办法结对编程，那么退而求其次，至少得进行一次代码审查。最好代码一写好就能落实到位一个轻量级流程的代码审查。我们在学校里学的那种又大又正规的流程其实并不实际——只有NASA( 美国宇航局)这种不差钱的土豪才买得起。所以换个轻量级的流程，意味着只需20%的成本就能享受80%的相同效果。

　　6.静态分析工具

　　以前人人都不看好所谓的静态分析工具。现在则好了很多，虽然它们仍然并不能真正替代代码审查，但是其使用成本比较低。当然可能需要购买许可证，但是一旦将它们设置进系统中之后，以后每一次我们输入代码，它们都会一丝不苟兢兢业业地检查并且快速提示发现的所有错误。

　　7.编码标准

　　老实说我并不怎么喜欢编码标准。从我的经验来看，很多团队在讨论编码标准上面浪费了太多的时间，而且一旦确定了某种标准，这往往会损害一部分开发人员的利益。不过如果我们能克服这些问题，那么绝对会有意想不到的效果。

　　首先建立一个讨论小组——应该以一种面对面的形式，不要通过电子邮件和电话——讨论出编码标准里应该包含哪些内容。找到需要讨论的地方，规分为不同的类别：少许定位为必选项目，推荐项目的数量可以较前者多点，候选项目则可以更多。在候选组里的需要经过深思熟虑之后才能放到推荐组和必选组中。剩下的第四组则是明确不能成为编程标准的内容。

　　每隔三至四个月检查一下这些标准，看看有没有需要从候选组提升到推荐组，或者从推荐组放到必选组的，要是发现什么已经不适应当前工作的项目，那就尽快删除或者降级。

　　此外，我们不应该将编码标准当做代码审查的一部分，而是两手都要抓，两手都要硬，万一不得不遗漏其中之一，可以借助自动化工具，例如运行静态分析工具，自动执行代码标准来检查代码。
快速阅读代码相关文章：

1.如何快速阅读源代码

2.如何做到一目十行快速阅读

3.快速阅读技巧:几个简单的速读技巧

4.如何快速阅读并记忆

5.如何做到快速阅读

6.如何快速阅读的技巧