如何探索大型开源软件库( 三 ) ：如何探索大型开源软件库作

充分使用问题描述
在许多情况下，你可以省去探查工作，因为项目的维护者通常已经明确了修复将涉及代码库的哪些区域，并且在问题描述中提供了这些信息。
从头开始是没有意义的，所以确保你已经查看了问题描述中提供的所有信息。
不要试图遍历整个代码库
在刚开始的时候，你可能会试图去理解所有的东西。这不仅不必要，而且还会严重损害你的贡献能力，因为十有八九你会感到更加困惑。
大多数存储库已经存在了很长一段时间，多个人对代码库做贡献和扩展，使它发展到现在的样子。在大多数情况下，理解每一行代码是不可能的，你应该试着策略性地处理这个问题。
大多数优秀的开源项目结构都非常好，文件夹层次结构和文件名大多都一目了然。通常，这些层次结构遵循自顶向下的方法：较大的子系统文件夹包含它们的子部件。沿着文件夹的层次结构向下，逐步进入你需要处理的子系统，最终，你的工作范围会缩小到项目的几个文件，这就是你解决这个问题时的工作空间。
如果你是在修复一个Bug ，那么问题可能起源于系统中的其他地方，但是，你所选择的文件是一个很好的起点，你可以尝试从这里出发跟踪问题的来源。当然，探索代码库的一小部分比试图掌握所有正在发生的事情要容易得多。
切纸原理
如果项目是你创建的，你会知道它的来龙去脉。但对于别人的项目，如何才能掌握到同样的程度？
如前所述，我们不可能在很短的时间内掌握一个重要的代码库。不过，你应该知道“切纸原理” ，其理念是，当你处理完代码库中的几个小问题时，你对代码库的基本理解会得到改善，直到你对代码库中所有东西的工作原理都有了一些了解。这就是“局外人”熟悉代码的方式，随着时间的推移一小部分一小部分地熟悉代码。
弄清楚你那一部分在其中扮演的角色
既然你已经确定了修复范围，那么你应该将其他所有东西都视为黑盒。明确你那部分代码将获得何种类型的输入，如何使用它们，以及预期有什么输出。
所有这些看起来都很抽象，但其基本思想是，如果要添加新内容，你不需要了解所有其他内容是如何实现的。你只需要假设其他一切都符合项目规范，然后尝试探索你所关注的一小部分代码。
当然，对于每个更改，可能都需要查看代码库的多个不同的部分，其中许多都有Bug 。不过，这只是因为你遇到了一个糟糕的软件，通常，你只需要关注成熟代码库中一个明确定义的方面。
重现问题
如果你的工作是消除漏洞，那么在计划修复之前，你第一步首先要做的无疑是重现问题。在这个过程中，你要搭建项目，确保它可以运行，且所有配置都正确，然后最终重现问题。
有一种简单的方法来重现问题可以在很多方面带来帮助。它有助于加速开发，你可以（而且应该）更进一步，尝试编写一个捕捉这种行为的测试。这样，你不仅可以快速运行测试，而且还可以确保在项目的未来版本中，这个问题不会再次意外出现。
结构化理论
你已经研究了这个问题，缩小了关注范围，现在可以着手解决问题了。如果你发现了错误的根本原因，那么你可以继续进行下一步的工作，做一个解决方案，但如果你被卡住了，有一件事也许可以帮助你摆脱困境，那就是创造性地思考导致问题的潜在原因，并设法验证每个原因是否真得存在。
当你试图想出一个解决方案时，围绕解决问题的多种方法进行集体讨论是有帮助的，因为你可以比较和对比几种方法，并锁定最优的一种。
在巨大的代码库中编辑文件时，你可能会陷入分析瘫痪的状态。可能会有很多想法在你的脑海中浮现，但往往，出于对代码质量的担忧，你只是停在原地，而不是继续前进。
这就是为什么必须分两个阶段进行。第一步是让它可以工作，这会儿还是在你的机器上。有些东西可能是硬编码的，有些部分可能还可以优化，但重要的是你有一些可以工作的东西。将它从一个可工作的状态提升到一个健壮的状态，比试图在第一次就把一切都做好要容易得多。
领会迭代的精神，不要害怕修改代码。一旦概念验证完成，你就可以继续完善它了。
编码和指南
来自导师和维护人员的反馈
另一种有效的（调试）技术是向其他人解释你的代码。通常，你会向自己解释这个Bug 。有时几句话之后，你就会尴尬地说， “没关系，我知道怎么回事了。很抱歉打扰你。 ”这非常有效；你甚至可以让非程序员作为倾听者。有一所大学的计算机中心在服务台附近放了一只泰迪熊。学生们先向这只熊解释，然后才能与人类顾问交谈。