2022年如何快速阅读代码.docx

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

1、2022年如何快速阅读代码快速阅读hadoop代码的方法 一、学习hadoop基本运用和基本原理 这是第一个阶段，你起先尝试运用hadoop，从应用层面，对hadoop有肯定了解，一旦你对hadoop的基本运用方法比较熟识了，接下来可以尝试了解它的内部原理，留意，不须要通过阅读源代码了解内部原理，只需看一些博客，书籍，比如Hadoop权威指南，对于HDFS而言，你应当知道它的基本架构以及各个模块的功能;对于MapReduce而言，你应当知道其详细的工作流程，知道partition，shuffle，sort等工作原理，可以自己在纸上完整个画完mapreduce的流程，越具体越好。 在这个阶段，建

2、议你多看一些知名博客，多读读hadoop权威指南。假如你有实际项目驱动，那是再好不过了，理论联系实际是最好的hadoop学习方法。 二、起先阅读hadoop源代码 这个阶段是最困苦和漫长的，尤其对于那些没有任何分布式阅历的人。 许多人这个阶段没有走完，就放弃了，最终停留在hadoop应用层面。 这个阶段，第一件要做的事情是，选择一个hadoop组件。假如你对分布式存储感爱好，那么你可以选择HDFS，假如你读分布式计算感爱好，你可以选择MapReduce，假如你对资源管理系统感爱好，你可以选择YARN。 选择好系统后，接下来的经验是最困苦的。当你把hadoop源代码导入eclipse或intel

3、lij idea，沏上一杯茶，起先打算优哉游哉地看hadoop源代码时，你懵逼了：你绽开那数不尽的package和class，觉得无从下手，好不简单找到了入口点，然后你屁颠屁颠地通过eclipse的查找引用功能，顺着类的调用关系一层层找下去，最终迷失在了代码的海洋中，犹如你在不尽的压栈，最终栈溢出了，遗忘在最初的位置。 假如你正在经验这个过程，我的阅历如下：首先，你要摸清hadoop的代码模块，知道client，master，slave各自对应的模块，并在阅读源代码过程中，时刻谨记你当前阅读的代码属于哪一个模块，会在哪个组件中执行;之后你须要摸清各个组件的交互协议，也就是分布式中的RPC，这是

4、hadoop自己实现的，你须要对hadoop RPC的运用方式有所了解，然后看各模块间的RPC protocol，到此，你把握了系统的骨架，这是接下来阅读源代码的基础;接着，你要选择一个模块起先阅读，我一般会选择Client，这个模块相对简洁些，会给自己增加信念，为了在阅读代码过程中，不至于迷失自己，建议在纸上画出类的调用关系，边看边画，我记得我阅读hadoop源代码时，花了一叠纸。 在这个阶段，建议大家多看一些源代码分析博客和书籍。借助这些博客和书籍，你可以在前人的帮助下，更快地学习hadoop源代码，节约大量时间。 这个阶段最终达到的目的，是对hadoop源代码整体架构和局部的许多细微环节

5、，有了肯定的了解。这个阶段完成后，当你遇到问题或者困惑点时，可以快速地在Hadoop源代码中定位相关的类和详细的函数，通过阅读源代码解决问题，这时候，hadoop源代码变成了你解决问题的参考书。 三、依据需求，修改源代码。 这个阶段，是验证你阅读源代码成效的时候。你依据leader给你的需求，修改相关代码完胜利能模块的开发。在修改源代码过程中，你发觉之前阅读源代码仍过于粗糙，这时候你再进一步深化阅读相关代码，弥补其次个阶段中薄弱的部分。 当然，许多人不须要经验第三个阶段，仅仅其次阶段就够了：一来能够通过阅读代码解决自己许久以来的技术困惑，满意自己的新奇心，二来从根源上解决解决自己遇到的各种问题

6、。 这个阶段，没有太多的参考书籍或者博客，多跟四周的同事沟通，通过代码review和测试，证明自己的正确性。 7个提高代码质量的个技巧 1.测试驱动开发(TDD) 假如说要找一个最能提高代码质量同时还要削减bug的实践练习唯恐就非TDD莫属了。它的优点是适用于任何类型的项目和灵敏开发。其历史可以追溯到很早以前，但是直到XP的普及它才慢慢为人所知。当作为能自动化构建和测试实践的持续集成周期的一部分运作的时候，它被称为单元测试。 许多开发人员并不知道该怎么提高这方面的实力，这须要培训和教化。而且这是一个学习和积累的过程，不要想着能一夜吃成个胖子。 2.验收测试驱动开发(ATDD) 这是基于TDD单

7、元测试之后的一个新的水平。这不但表明白验收标准，而且还能在开发工作起先之前自动执行开发需求。在许多状况下，须要专业测试人员和客户携手共同参加到测试中去。 3.持续集成(CI) 这能确保新代码不会干扰到已经存在的代码。假如再加上TDD和ATDD一起创建一个自动化、可重复的的测试套件，将会大幅度提高其运用价值。 4.结对编程 有关于结对编程的争辩好像已经偃旗息鼓了，同样的人们实际应用的例子也越来越少。这不行谓不是一个缺憾。因为在即时的代码审查上，两个脑袋总比一个管用。它也允许开发人员将留意力全部灌注到手头的工作上不必分心于电话、邮件、短信等等，因为我们的partner会搞定。 5.代码审查 假如没

8、方法结对编程，那么退而求其次，至少得进行一次代码审查。最好代码一写好就能落实到位一个轻量级流程的代码审查。我们在学校里学的那种又大又正规的流程其实并不实际只有NASA( 美国宇航局)这种不差钱的土豪才买得起。所以换个轻量级的流程，意味着只需20%的成本就能享受80%的相同效果。 6.静态分析工具 以前人人都不看好所谓的静态分析工具。现在则好了许多，虽然它们仍旧并不能真正替代代码审查，但是其运用成本比较低。当然可能须要购买许可证，但是一旦将它们设置进系统中之后，以后每一次我们输入代码，它们都会一丝不苟兢兢业业地检查并且快速提示发觉的全部错误。 7.编码标准 醇厚说我并不怎么喜爱编码标准。从我的阅

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