如何修复错误¶
确保你理解需要做什么¶
如果你不太确定，请在错误报告中添加评论请求更多信息。通过其他方式（例如 IRC、电子邮件、办公室茶水间等）与他人沟通也是完全可以的，但最好返回到错误报告并添加额外信息，以防你某个时候停止处理该错误，而其他人需要在你离开的地方继续工作。
找出需要修改的文件¶
在理想情况下，错误报告从一开始就包含这些信息，但很多时候并非如此。
如果你还不熟悉代码库，文件和目录概述 可能有助于你找到文件的位置。
如果你知道你在找什么（例如，需要更正的错别字字符串或需要修改的函数名称），可以使用源代码搜索引擎
建议你添加智能关键字搜索 用于 DXR 以更快地搜索。
你也可以使用操作系统的命令行。例如，让我们搜索代码库中 TODO 的所有出现位置。
在命令行提示符中，使用 cd 命令切换到 devtools 目录
cd ~/mozilla-central/devtools # use your actual folder name!
grep -r 'TODO' .
这将列出 DevTools 代码中包含 TODO 字符串的所有位置。如果实例太多，你可以将上述命令与 less 命令结合使用，以滚动和分页 grep 命令的输出
grep -r 'TODO' . | less
按 q 退出。
如果经过所有这些操作后你仍然无法找到方向，请在错误报告中添加评论请求更多信息。
如何确定你找到了你正在寻找的内容？¶
有一些方法可以确认你找到了正确的文件
如果这是关于更改字符串...¶
编辑文件，并更改字符串（例如，更正错别字）。重新构建并再次运行
./mach build
./mach run
然后转到显示你想要更改的字符串的面板。
错别字是否仍然存在？或者字符串现在是否显示正确？
如果这是关于更改 JavaScript 代码...¶
如果你认为你找到了要编辑的正确文件，请在代码中可能执行的位置添加一些日志语句（例如，在类构造函数中）
// For front-end code
console.log('hello friends\n');
// Sometimes it's hard to spot your output. Emojis can help here really well.
console.log('👗👗👗', 'This is your logged output!');
或者...
// For server code
dump('hello friends\n');
提示：是否使用其中一种取决于你正在处理的错误类型，但如果你刚刚开始使用 DevTools，你很可能会首先遇到前端错误。
然后重新构建并再次运行
./mach build
./mach run
转到面板或启动可能导致代码执行的操作，并密切注意控制台中的输出。
你能看到 hello friends 吗？那么你找到了你正在寻找的文件。
你可能会收到许多你现在不关心的其他消息，但我们可以使用 grep 进行过滤
./mach run | grep hello friends
这只会显示包含 hello friends 的行。如果你在尝试执行代码后得到空输出，也许这不是正确的文件，或者你没有触发操作。
这意味着是时候在错误报告中或向你的同事寻求更多信息了。告诉他们你尝试了什么，这样他们就不必自己去弄清楚（节省每个人的时间！）。
如果这是关于更改 CSS 代码...¶
如果你认为你找到了正确的文件和正确的 CSS 选择器，你可以尝试编辑文件以插入一些非常醒目的彩色规则（例如，一条非常粗的亮蓝色边框）。
border: 4px solid blue;
通过重新构建本地更改检查更改是否显示。
./mach build faster
./mach run
下一步：执行必要的操作¶
这始终取决于你正在处理的特定错误，因此很难在这里提供指导。
这里关键的一点是，如果你有任何疑问，不要犹豫，提出问题。询问你的导师、你的经理或联系我们。**你绝对不应该卡住**。
有些人发现很难识别甚至承认自己处于这种情况，因此描述“卡住”的一些方式可能是
你尝试了你能想到的所有方法，但没有任何效果，并且不知道该怎么办。
你有一些可以执行的操作的想法，但不知道该选择哪一个。
在过去一两天里，你没有学到任何关于该问题的新知识。
你开始考虑放弃这个错误并改做其他事情。
你不知道该怎么办，但害怕寻求帮助。
如果你认为上述任何一种情况描述了你，请寻求帮助！
如果你担心浪费别人的时间，可以使用另一个技巧：时间盒。例如，给自己 2 个小时来调查。如果在这段时间结束后你仍然无法弄清楚任何事情，请停止并寻求帮助。可能是你需要的关键信息在错误描述中缺失，或者你误解了一些内容，或者甚至是你发现了一个错误，这就是为什么即使应该工作但也没有工作的原因！这就是为什么越早寻求帮助越好。
有用参考¶
编码规范¶
如果这是你第一次贡献代码，关于编码规范 的文档可能包含诸如使用哪种代码风格、如何命名新文件（如果你需要添加任何文件）、我们用于运行自动化检查的工具等问题的答案。
专业指南¶
我们还有一些指南解释了如何处理特定类型的问题，例如：调查性能问题 或编写高效的 React 代码。请查看侧边栏或使用侧边栏顶部的搜索框查看是否有关于你正在处理的错误类型的说明。
如果没有，也许你可以在修复错误的同时也贡献一份力量！
MDN¶
MDN Web 文档（也称为 *MDN*）包含大量关于 HTML、CSS、JS、DOM、Web API、Gecko 特定 API 等的信息。
运行测试¶
我们在开发时使用多种类型的自动化测试来帮助我们。
有些，比如 linting 测试，解决代码风格问题；其他则解决功能问题，例如单元测试和集成测试。此页面提供了有关测试类型以及如何运行测试的更多详细信息。
你可能希望经常运行单元测试和集成测试，以确认你没有破坏其他任何东西。根据你的操作，甚至可以只运行一个解决你正在实施的特定更改的测试文件
./mach test devtools/path/to/test.js
有时你可能希望运行一些与你正在修复的错误相关的测试
./mach test devtools/path/to/test-thing-*.js
一开始，你很可能不知道你正在处理的测试在哪里。请寻求帮助！你最终会找到解决方法。
在请求代码审查之前，确保本地测试通过是一个良好的习惯。这包括 linting 测试。要运行它们，请配置你的系统以运行 ESlint，然后你可以执行
./mach eslint devtools/path/to/files/you/changed
我们的代码审查工具也会自动运行 linter，但是如果你在本地运行它，你将获得即时反馈，并避免不得不再次发送更新的提交。
进行代码审查¶
当你认为你已经修复了错误时，首先让我们庆祝一下！耶！干得好 😀
现在是时候进行代码审查 了。