阅读源码前一定要明确的四个问题 & 实战: 向 VSCode 发起一个 Pull Request_哔哩哔哩_bilibili

四个问题：

• 为什么要读源码？
• 什么时候应该读源码？
• 项目能否读懂？
• 具体如何读源码？

为什么大家都推崇读源码

对于新手小白而言，想找到较好的学习资源，或者是获得大佬指导，成本较高。所以去读经典代码，使用近乎于逆向工程的形式，揣摩其设计理念，是在所有可行的选择中，相对较好的一种学习方式。但一定要意识到：读源码基本上是最后的手段！ 只要有更好的方式，就不要轻易尝试这种出力不讨好的手段。

什么时候应该读源码

首先先拆解一下软件项目的类型。项目通常分为两类：

• 学术性项目
  学术性项目更接近于计算机科学技术课程，比如操作系统、数据结构之类；对于这类项目，不建议直接阅读源码，因为已经有大量教科书或者论文作为资料，这些自然语言编写成的资料，通常比源码要更好理解；而且好的教科书通常也会有代码示例，结合文章理解代码的设计理念会比阅读源码要更好理解。

• 应用型项目
  应用类项目又能分为两种类型：

  • 框架工具
    如果说只是为了学习框架如何使用，而不是开发框架，那么也不建议阅读框架的源码。如果为了学习一个框架的使用需要通过阅读源码来学习，那么说明这个框架的抽象设计或者文档是存在问题的，此时更好的策略是不要选择这个框架。
  • 完整的产品应用
    首先要确定项目本身的质量。产品的成功和架构的成功是两回事，并不是说一个项目的名气大，就一定代码质量好。
    那么如何分析一个项目的质量呢？首先要看项目最近的更新频率。随着人们对软件工程领率的不断探索，项目的最佳实践也在不断变化，尤其是在应用开发的领域。时间相隔三五年，同一个功能的写法可能完全不一样。如果一个项目过于老旧，那就得质疑其代码质量。
    另外，要看项目中文档的质量。项目文档翔实，既能表明项目开发者对项目的重视，也能作为我们开发时的参考资料，降低阅读源码时的理解成本。

选择符合我们能力的仓库来阅读

在阅读源码前，我们需要做出一些基础的判断，让自己对这个项目的难度有个大概的预估。此外在我们了解一个新的项目时，最好不要预先设立一个太过宏大的目标，比如看懂项目架构设计之类。在没有通过对一些简单的功能修改验证自己的思路是否正确之时，贸然尝试对项目进行解读是非常危险的，我们这时并没有一个反馈的机制来验证自己的想法是对是错，一旦误入歧途，可能很久都无法将错误纠正过来。

一个更好的方式是从一些简单的功能修改入手，完成一次对项目的 Pull Request，由维护者完成code review，进而验证我们对项目的理解是否正确。

想要更简单一点的话，不妨我们去寻找那些社区中有一定讨论，甚至存在 PR 合并的功能。通过社区中的讨论，以及 PR 中具体的 code review，来获取当前需求下较为完整的上下文。在此之后，结合自己的认识，分析功能中是否还有可以优化的补充能力，以此作为我们第一次对此项目的功能修改。这样的方法，既保证了我们自己的参与度，同时也让项目的上手难度降到了最低。

具体如何阅读源码

首先，我们需要找到一些合适的切入点来分析项目。复杂的项目通常不是按顺序执行的脚本逻辑，其拥有大量的切面，因此我们很难通过顺序阅读代码来理解项目。此时快速定位逻辑、实现位置的能力是至关重要的。

对于后端项目而言，我们通常要修改的，都是某个API的实现。所以一个很直观的方法是从路由层入手，看看哪个 Controller 对应了 API。如果没有思路，甚至可以在项目中直接字符串搜索，找到那些与 API 名称相关的内容，以此作为切入点。

对于前端的项目，往往可以通过 F12 打开控制台，查看想要修改的元素以及对应的类名，以此为基础找到对应 UI 功能的实现。当然，如果我们能找到一个相关的社区 PR，就可以省区这些定位流程，直接确定相关功能的实现文件。这也是为什么上文中我们强调要紧跟社区PR 的原因。

然后则是最为重要的一步，将项目运行起来。只有运行起来后，我们才能使用断点调试的功能，或者通过修改代码，验证功能变更的结果，进而分析我们对项目的理解是否正确。如果只是看代码的话，即使对项目的理解出现了偏差，我们也很难察觉。

不必过度关注最终的效果是否符合预期，重点应该放在培养对项目运行逻辑的直觉上，面对庞大的项目，我们无法逐行理解其逻辑，因而通过这四种类似黑盒调试的方法，让我们对项目的执行流程有一个大致的估计，进而的以确定具体的代码修改方案。

接下来则是具体的开发策略设计，这部分流程则会因人因项目而异。

文章开头的视频后半部分举了一个例子，演示了如何修改程序以满足自己的需求，同时如何在github上向 VS Code 官方发起一个 Pull Request。