怎样快速浏览代码.docx

《怎样快速浏览代码.docx》由会员分享，可在线阅读，更多相关《怎样快速浏览代码.docx（7页珍藏版）》请在淘文阁 - 分享文档赚钱的网站上搜索。

1、怎样快速浏览代码怎样快速浏览代码程序员在做程序的时候需要敲打大量的代码，这就需要程序员要有快速浏览代码的能力。那么，要怎么快速浏览这些代码呢?接下来学习啦我来为你说说快速浏览hadoop代码的方法。快速浏览hadoop代码的方法一、学习hadoop基本使用和基本原理这是第一个阶段，你开场尝试使用hadoop，从应用层面，对hadoop有一定了解，一旦你对hadoop的基本使用方法比拟熟悉了，接下来能够尝试了解它的内部原理，注意，不需要通过浏览源代码了解内部原理，只需看一些博客，书籍，比方（Hadoop权威指南），对于HDFS而言，你应该知道它的基本架构以及各个模块的功能;对于MapReduce

2、而言，你应该知道其详细的工作流程，知道partition，shuffle，sort等工作原理，能够本人在纸上完好个画完mapreduce的流程，越具体越好。在这个阶段，建议你多看一些知名博客，多读读（hadoop权威指南）。假如你有实际项目驱动，那是再好不过了，理论联络实际是最好的hadoop学习方法。二、开场浏览hadoop源代码这个阶段是最困苦和漫长的，尤其对于那些没有任何分布式经历的人。很多人这个阶段没有走完，就放弃了，最后停留在hadoop应用层面。这个阶段，第一件要做的事情是，选择一个hadoop组件。假如你对分布式存储感兴趣，那么你能够选择HDFS，假如你读分布式计算感兴趣，你能够

3、选择MapReduce，假如你对资源管理系统感兴趣，你能够选择YARN。选择好系统后，接下来的经历是最困苦的。当你把hadoop源代码导入eclipse或intellijidea，沏上一杯茶，开场准备优哉游哉地看hadoop源代码时，你懵逼了：你展开那数不尽的package和class，觉得无从下手，好不容易找到了入口点，然后你屁颠屁颠地通过eclipse的查找引用功能，顺着类的调用关系一层层找下去，最后迷失在了代码的海洋中，好像你在不尽的压栈，最后栈溢出了，忘记在最初的位置。假如你正在经历这个经过，我的经历如下：首先，你要摸清hadoop的代码模块，知道client，master，slave

4、各自对应的模块，并在浏览源代码经过中，时刻谨记你当前浏览的代码属于哪一个模块，会在哪个组件中执行;之后你需要摸清各个组件的交互协议，也就是分布式中的RPC，这是hadoop本人实现的，你需要对hadoopRPC的使用方式有所了解，然后看各模块间的RPCprotocol，到此，你把握了系统的骨架，这是接下来浏览源代码的基础;接着，你要选择一个模块开场浏览，我一般会选择Client，这个模块相对简单些，会给本人增加自信心，为了在浏览代码经过中，不至于迷失本人，建议在纸上画出类的调用关系，边看边画，我记得我浏览hadoop源代码时，花了一叠纸。在这个阶段，建议大家多看一些源代码分析博客和书籍。借助这

5、些博客和书籍，你能够在前人的帮助下，更快地学习hadoop源代码，节省大量时间。这个阶段最终到达的目的，是对hadoop源代码整体架构和局部的很多细节，有了一定的了解。这个阶段完成后，当你碰到问题或者困惑点时，能够迅速地在Hadoop源代码中定位相关的类和详细的函数，通过浏览源代码解决问题，这时候，hadoop源代码变成了你解决问题的参考书。三、根据需求，修改源代码。这个阶段，是验证你浏览源代码成效的时候。你根据leader给你的需求，修改相关代码完成功能模块的开发。在修改源代码经过中，你发现之前浏览源代码仍过于粗糙，这时候你再进一步深化浏览相关代码，弥补第二个阶段中薄弱的部分。当然，很多人不

6、需要经历第三个阶段，仅仅第二阶段就够了：一来能够通过浏览代码解决本人长久以来的技术困惑，知足本人的好奇心，二来从根源上解决解决本人碰到的各种问题。这个阶段，没有过多的参考书籍或者博客，多跟周围的同事沟通，通过代码review和测试，证实本人的正确性。7个提高代码质量的个技巧1.测试驱动开发(TDD)假如讲要找一个最能提高代码质量同时还要减少bug的实践练习恐怕就非TDD莫属了。它的优点是适用于任何类型的项目和敏捷开发。其历史能够追溯到很早以前，但是直到XP的普及它才渐渐为人所知。当作为能自动化构建和测试实践的持续集成周期的一部分运作的时候，它被称为单元测试。很多开发人员并不知道该怎么提高这方面

7、的能力，这需要培训和教育。而且这是一个学习和积累的经过，不要想着能一夜吃成个胖子。2.验收测试驱动开发(ATDD)这是基于TDD单元测试之后的一个新的水平。这不但表明了验收标准，而且还能在开发工作开场之前自动执行开发需求。在很多情况下，需要专业测试人员和客户携手共同介入到测试中去。3.持续集成(CI)这能确保新代码不会干扰到已经存在的代码。假如再加上TDD和ATDD一起创立一个自动化、可重复的的测试套件，将会大幅度提高其使用价值。4.结对编程有关于结对编程的争论似乎已经偃旗息鼓了，同样的人们实际应用的例子也越来越少。这不可谓不是一个遗憾。由于在即时的代码审查上，两个脑袋总比一个管用。它也允许开

8、发人员将注意力全部灌注到手头的工作上不必分心于、邮件、短信等等，由于我们的partner会搞定。5.代码审查假如没办法结对编程，那么退而求其次，至少得进行一次代码审查。最好代码一写好就能落实到位一个轻量级流程的代码审查。我们在学校里学的那种又大又正规的流程其实并不实际只要NASA(美国宇航局)这种不差钱的土豪才买得起。所以换个轻量级的流程，意味着只需20%的成本就能享受80%的一样效果。6.静态分析工具以前人人都不看好所谓的静态分析工具。如今则好了很多，固然它们仍然并不能真正替代代码审查，但是其使用成本比拟低。当然可能需要购买许可证，但是一旦将它们设置进系统中之后，以后每一次我们输入代码，它们

9、都会一丝不苟兢兢业业地检查并且快速提示发现的所有错误。7.编码标准老实讲我并不怎么喜欢编码标准。从我的经历来看，很多团队在讨论编码标准上面浪费了过多的时间，而且一旦确定了某种标准，这往往会损害一部分开发人员的利益。不过假如我们能克制这些问题，那么绝对会有意想不到的效果。首先建立一个讨论小组应该以一种面对面的形式，不要通过电子邮件和讨论出编码标准里应该包含哪些内容。找到需要讨论的地方，规分为不同的类别：少许定位为必选项目，推荐项目的数量能够较前者多点，候选项目则能够更多。在候选组里的需要经过深思熟虑之后才能放到推荐组和必选组中。剩下的第四组则是明确不能成为编程标准的内容。每隔三至四个月检查一下这些标准，看看有没有需要从候选组提升到推荐组，或者从推荐组放到必选组的，要是发现什么已经不适应当前工作的项目，那就尽快删除或者降级。此外，我们不应该将编码标准当做代码审查的一部分，而是两手都要抓，两手都要硬，万一不得不遗漏其中之一，能够借助自动化工具，例如运行静态分析工具，自动执行代码标准来检查代码。快速浏览代码