随着技术的“革命性”发展，以及市场的竞争所需，技能的提升比以往任何时候都显得尤为重要。作为技术人员，若要提升自身的综合能力，“源码”这一道关是不可逾越的鸿沟。俗语云：不入虎穴，焉得虎子。只有深入本质，才能够抓住核心要素，毕竟，源码是所有技术框架的灵魂，只有对灵魂进行“革命性”洗礼，才能快速掌握其各路经脉，打通任督，从而建立此类技术相关体系。
通常，从本质上来讲，阅读源代码是软件技术人员，尤其是开发/架构人员的必经之路。然而，对于大部分人而言，这种经历是极其痛苦的。不是每个人都愿意接受阅读别人代码这件所谓没有“营养”的事情，也不是每个人都有能力去阅读，毕竟，至少大部分人认为阅读源码是一件无聊的、浪费时间的事情，因为有时阅读源码时会令人感到沮丧。有些情况下当我们尝试开始阅读别人的代码时，但最终会得到一种痛苦的感觉，因为我们有时候无法理解它，或者代码没有很好地去描述以及给予相关注释。毕竟，在实际的业务开发活动过程中，我们中的大多数开发人员希望专注于编码而非阅读别人的源码，而不是意识到阅读代码也是具有重要的技能。
然而，基于某种特定场景，阅读源码对我们的技术提升有着潜在的益处。其回报是巨大的。通常，为了能够编写好的代码，我们必须阅读更多的源码以帮助我们能够实现业务框架所需的逻辑处理。基于此场景，我们可以了解其他开发人员如何思考以及如何解决特定问题以及他们所欠缺的地方。例如，当我们的应用程序调用底层框架（Java 虚拟机）或者操作系统内核时，若我们通过当前的技术无法解决某一问题时，可能需要去通过代码追溯等方式进行层层分析，此时，通过对所调用的框架或内核源码进行阅读分析，进一步排障，直至将问题 Fix 掉。除此之外，通过阅读不同风格的源码，可以培养我们养成不同的思维模式，建立不同的技术体系。从阅读其他人的代码，使得我们的技能视野得到进一步的扩大。
那么，在日常的开发过程中，如何能够高效的阅读源码呢？在本篇文章中，笔者将以自己的浅薄经验进行简要阐述，具体可基于以下几种方法进行：
1、基于工具
其实，在实际的场景中，有各种各样的工具基于可视化的形式可以帮助我们进行源码分析，通过不同插件将源码中的相互调用呈现出来。例如，IntelliJ IDEA 具有导航源代码的功能，允许我们按单词，甚至缩写进行模糊检索，使得我们可以快速地从源代码的一部分跳转到另一个部分。比如，我们需要了解某一类的相关调用展示，可以基于工具进行操作，右键选择所需要查看的类，然后选择 Diagrams > Show Diagram... 可以打开类的继承图，具体使用可参考如下示意图：
2、源码调试
通常意义上来讲，调试源码是迈向读取代码的第一步必经之路。虽然，基于此种方式可能不会为我们提供有关该项目的更多细节，然而，对于我们而言，能够有助于去了解或熟悉如何构建及运行它，并且基于对其的原理的学习，使得我们更能深刻地理解其库、框架以及其应用场景等，这也是提高对特定项目的理解的最佳实践方法。例如，基本上每本关于技术原理或底层分析的书籍中，都会涉及有关源码编译的相关讲解，尤其是底层框架。举个简单的示例，在 Java 虚拟机的相关书籍中，都会涉及到 JDK 编译的相关实践：获取源代码，构建编译环境，进行编译以及在 IDE 工具中进行源码调试等。因为，只有基于此种场景，我们才能够进一步迈进框架的底层、最本质的地方，才能有利于了解其周边生态环境，进而提升我们的排除及解决问题能力。
3、实践 Demo
随着开源技术的传播，越来越多的技术狂热者喜欢进行自我“释放”，将自己所实践的场景分享与整个组织或者技术社区，一方面对自己技术经验的沉淀，另一方面希望能够获得大牛的“指点”，进而能够获得最佳声望提升，有利于后期的个人发展。因此，作为技术小白，在我们遇到某一特定场景疑问时，我们可以通过 Clone 别人的 Demo 进行学习及实践，基于别人的思路，然后拓展自己的技能，这或许也是最快、最佳的提升途径。通过调试别人的源码进行对比学习，优劣互补，从而提升自身技能。通常来讲，实践的 Demo 途径较为广泛，例如，产品官网 Demo、GitHub、Gittee以及各种开源社区等等，都是获取最佳实践 Demo 的窗口。
4、代码评审
软件项目开发是一种非常需要合作、协同的活动。没有人可以单独构建大型或重要的软件系统。每个软件由团队构建，在一个团队中，每个人都有助于塑造一个项目。在一天结束时，每个人的贡献都被合并并成为一个很好的成果，对客户具有真正的价值。然而，从质量保证角度而言，除了进行实际编码、自测外，还有另一种活动是不可或缺的，即，代码审核，针对彼此代码的审查、学习及优化改进。基于此种模式，我们不仅仅获得了一种质量保证的手段，同时，也有利于构建代码库的知识共享，使得整个团队能够共同进步、共同成长，从而提升整个团队的整体开发水平。笔者刚参加工作不久时，特喜欢参加这种所谓没有“意义”的评审会，毕竟，看着大牛吹牛逼也是件非常荣幸的事情，毕竟，没有人跟技术“有仇”。
5、官网文献
其实，官网很多时候往往能够给予我们相关提示，当我们在阅读源码的过程中。我还是喜欢阅读官网的文章，无论是 Demo 或者指导书，毕竟，最原始的味道是最好的。我这人有个特点：1、不喜欢甚者不会去买翻译过来的技术书籍阅读，2、不怎么去看别人的视频。笔者不是装逼，因为只有经过实践，才能说明一切，毕竟，每一个人人所处的场景不同，不能生搬硬套，即所谓的“因地制宜”。我不能说翻译过来的没有用，毕竟每个人的理解还是有差异，“原汁原味”的信息更能走进作者的视野、体会作者的思路。举一个简单的示例，Redis 在 6.x之前是基于单线程的吗？还有，Java 虚拟机的内存到底包不包括持久代？所有的这一连窜问题，官网其实已经给予我们相关答案了，只是大家的认知有限，思维体系尚未成熟而已，此处仅针对技术层面而言。
当然，除上述方法之外，也存在其他的技巧，毕竟每个人的能力是分等级的，技术风格也不尽相同，故此不能一概而论，上述的解析仅供参考，具体以大家的实际情况断定。只要能够借助阅读源码解决大家的技术痛点，无论基于那种策略都不为过，毕竟，所有的技术拷问都是为业务而生、业务而死。
综上所述，基于如何进行高效阅读源码的相关解析，本文到此为止，大家有任何问题或建议，可以随时留言、沟通。
