打开引擎盖

比方说，我们有一个错误，似乎来自我们不拥有或不知道的代码。例如，公司范围内的React <Button>组件。它是由另一个团队编写和拥有的。

假设我们已经尝试了基本的方法（谷歌搜索，在Slack上搜索，最小的重现，询问Alexa），而错误仍然存在，我们现在有两个选择。

问别人--导师或其他团队的值班人员。由于我们不拥有或不了解发生故障的那一层的内部情况，让我们去问那些知道的人。
打开引擎盖，看一看。阅读源代码，了解失败的代码的相关部分。

总是值得先尝试选项2。如果有漏油，不要把车直接开到车库--打开引擎盖，看看油是如何流经发动机的。也许你可以自己感觉到问题出在哪里 :)

(这并不意味着我们应该花上几天或几周的时间来进行孤立的调试--划分时间范围是一个很好的策略）。)

为了理解堆栈跟踪，我们必须阅读产生它的源代码。在大多数情况下，我们可以在某个地方搜索到它--无论是在node_modules里面，还是在公司的GitHub上，还是在公共的GitHub上等等。

因此，如果错误来自<Button>组件--你可以阅读它的源代码! 也许错误是在更深的地方--在一个共享的React钩子，或一个状态管理库--甚至可能是React本身？你可以继续阅读源代码，一直往下看。

更广泛地说，我们可以通过查看源代码（以及任何可用的文档）来了解一个应用程序是如何工作的，以了解它打算做什么。

比如说。

为了调试堆栈跟踪，我们可以阅读源代码，了解哪些嵌套函数正在被调用，以确定坏的那行代码要找到一个端点存在的原因以及它的定义，我们可以使用SourceGraph或git grep来搜索这个字符串，并寻找它的定义如果一个Docker容器由于卷中缺少文件而无法启动，我们可以查看Dockerfile和.dockerignore文件，看看它是用什么构建的如果没有找到预期的环境变量，我们可以查看构建配置或相关的bash脚本来检查定义了哪些变量等等...。你通常可以通过查看某个地方的代码来发现为什么事情是这样的。只要不断地揭开引擎盖

其他工程师没有超能力。我们所做的就是打开引擎盖。

值得一提的是，每当你问一个随叫随到的渠道或导师，而他们不知道答案的时候--他们很可能只是经历一个类似于上述的过程。就像你或任何人都可以做的那样 :D

调试的机制

互联网上有很多教程和解释，引导你了解调试的机制，这里有一些我喜欢的。

摘要

拥有潜入不熟悉的代码的信心和能力是至关重要的--不仅是为了疏通自己，也是为了。

与公司里没有人知道的遗留系统一起工作时在指导或与队友结对子研究他们的新代码时有时，问题的根源在信息库的某处，你需要调试Linux的东西 😬 tl;dr: 有一个奇怪的错误信息？继续打开引擎盖，找出原因!

附录。对于时间管理来说；要补习，不要学习。

这篇文章并不意味着我们都应该花无限的时间来学习每一个工具的一切。

我认为值得花更多的时间去深入了解我们的日常工具--而逐渐减少对其他事物的了解。

我们的目标不是要成为所有东西的专家。那是不合理的。我们的目标是让自己感觉足够舒适，可以潜入任何工具中，以便你能找到问题的根源。你做的次数越多，下次就越容易！这有点像补习班。

这有点像考试前夜的补习。你只需要阅读足够的内容来通过考试，而你可能在一周后就不记得你所学的任何内容了你要培养的真正技能是如何快速消化和理解信息。对于学校来说，这可能不是最好的方法，但我想说，对于软件工程师来说，这是一个很好的技能 :P

[Code翻译]要了解任何事情，都要不断弹出引擎盖。

打开引擎盖

其他工程师没有超能力。我们所做的就是打开引擎盖。

调试的机制

摘要

附录。对于时间管理来说；要补习，不要学习。