对于HBase而言，相比于远程Debug，本地Debug似乎更难以理解了，因为我们所熟知的HBase部署形态就是分布式的，要对运行时的HBase集群进行Debug，自然采用远程Debug模式了。
其实，Debug也可以针对HBase提供的测试用例，大部分用例都是基于一个本地模拟的Mini Cluster运行的，这个Mini Cluster运行在一个进程中，使用线程模拟HBase的关键进程。
这个过程中，也可以动手小改一下源码，验证自己的想法，或者观察因为改动所带来的行为变化。
重视阅读测试用例源码很多人并不习惯于阅读HBase的测试用例源码，其实，阅读测试用例的源码，可以帮你理解一些正确的行为应该是怎样的。
因为每一个被定义的正确行为，都以具体的测试用例固化下来了。
重视实际遇到的每一个Bug，每一个Bug都可以讲一个完整的故事阅读源码过程中，自己提出的疑问，往往还不是最深刻的。最深刻的点，往往存在于所遇到的每一个Bug中。
对于Bug，很多人的态度往往是，能规避则规避之，集群只要能恢复正常，就不再有任何兴致去探究根因。
Bug往往是一些未考虑充足的边界场景，如果想探究Bug的根因，必然需要先摸清与之相关的所有流程，而后结合问题现象进行相关推理。一个Bug的前因后果，通常可以讲一个完整的故事。只有经过一个个Bug的历练，才能逐步成长为内核专家。
能力进阶：开始关注社区动态，或尝试为社区贡献Patch关注社区动态，可以及时获知一些重要的Bugs或社区正在开发的大的Features。关注的方式包括但不限于：
订阅社区的Mail List
关注社区的问题单
如果感觉自己已经很好的掌握了源码，而且发现了部分设计不合理，或者是部分能力不完善（结合实际的业务需求），也可以主动为社区贡献Patch，对于大部分开源项目而言，都是非常鼓励大家贡献Patch的。
总结本文主要从方法论的角度探讨了阅读开源项目源码的一些建议，供大家参考。这是第一个版本的内容，欢迎大家在评论中贡献自己的优秀实践方法，我可以继续完善它的内容，期望能够为更多人带来有价值的指导信息。