五个提高提问效率的技巧

作为开发者，我们都会遇到难题。遇到这种情况时，我们会开始在Google上搜索解决方案，或者在Stack Overflow、Swift 论坛、iOS 开发者 Slack 社区或其他地方提问。过去几年，我一直积极帮助人们解决他们遇到的问题，在这个过程中，我发现提出好问题并非易事。今天的“快速技巧”栏目，我想分享五个我认为对提高提问技巧至关重要的建议，这些技巧最终将有助于你获得更好的答案。

1. 提供背景信息

当你向别人提问时，他们的思维方式往往与你不同。无论是负责不同功能的同事，还是远在世界另一端、从未听说过你或你的项目的人，你都需要让他们了解你的情况。我见过有人问“为什么我的通知没有弹出？”或者“如何修复布局错误？”之类的问题，在没有任何背景信息的情况下，很难回答这类问题。一个简短的介绍，说明你想要实现的目标或你正在进行的工作，会大有帮助。例如，与其问以下问题：

为什么我的通知没有触发？

你可以这样写：

我正在开发一个应用，需要实现定期本地通知功能。我已经请求用户授予通知权限，并且也确认用户在设置中已授予权限，但是当我尝试安排通知发送时间时，通知却始终无法送达。请问可能是什么原因导致的？

后一种提问方式提供的信息比前一种多得多，而且任何想帮助你的人现在都能和你处于相同的思路中。对于任何试图帮你解决那个棘手bug的人来说，提供一些背景信息都大有裨益。

2. 解释一下你已经尝试过哪些方法。

我经常看到有人提出问题，问题本身问得不错，但之后却因为尝试过某些方法就直接否定了别人提出的想法或解决方案。在编程中，从 A 点到 B 点通常不止一种方法，所以当你遇到问题或提出疑问时，分享你已经尝试过的方法非常重要。这能为帮助你的人节省大量时间，因为他们不必重复那些他们已经知道对你无效的想法。此外，你尝试过的方法可能方向正确，你的问题可能与你尝试过的某个解决方案有关，而不是与你试图解决的问题本身有关。

设想这样一种情况：你尝试解码一个 JSON 响应，但始终无法成功。如果你只问以下问题，不太可能得到满意的答案：

我正在从网络获取数据，并尝试将这些数据解码成一个结构体。我可以正常获取数据，但是如何解码JSON呢？

毕竟，你已经尝试解读过这个回复了！不妨换个角度，问问以下问题：

我正在从网络获取数据，并尝试将其解码成结构体。我可以正常获取数据，但似乎无法解码 JSON。我已经尝试编写自定义编码键，但仍然出现解码错误。

这个问题仍然缺少一些信息，我将在下一个技巧中解决，但这里重要的是，任何阅读这个问题的人都知道提问者了解 ` JSONDecoderand` 和 ` CodingKeys。换句话说，他们知道应该扮演“帮助你调试 JSON 解码”的角色，而不是“教你如何解码 JSON”的角色。

3. 分享你的错误

提供背景信息和您尝试过的解决方案固然很好，但在很多情况下，即使有人想帮助您，他们仍然会遗漏一个关键信息：错误信息。如果帮助您的人不知道您遇到了什么错误（如果有的话），就很难帮您调试问题。同样地，如果您没有遇到错误，而是出现了意料之外的结果，那么分享这个意料之外的结果也同样重要。请思考以下问题：

我尝试将一些 JSON 数据解码成结构体，但遇到了错误。有什么解决办法吗？

任何愿意帮助你的人都会接着问你一个反问句：

错误是什么？

为了简化获取帮助的流程，并提高潜在答案的质量，请在问题中直接包含错误信息：

我尝试将一些 JSON 数据解码成结构体，但遇到了以下错误：

Swift.DecodingError.dataCorrupted(Swift.DecodingError.Context(codingPath: [], debugDescription: "给定的数据不是有效的 JSON。", underlyingError: Optional(Error Domain=NSCocoaErrorDomain Code=3840 "字符 0 周围的值无效。" UserInfo={NSDebugDescription=字符 0 周围的值无效。})))

有什么解决办法吗？

现在，看到这个问题的人立刻就能明白，你的问题不在于 JSON 解析逻辑，而在于你试图解码的数据。当你帮助别人解决问题时，这条信息极其宝贵。Xcode 控制台中的错误信息通常包含关键线索，能够帮助你找到问题的根本原因。

4. 请用文字形式展示一些代码。

这条建议并非总是适用，但通常情况下确实有效。如果您遇到的错误、疑问或问题涉及您已编写的代码，那么在提问时分享这些代码会很有帮助。请记住，阅读您问题的人并不想为了弄明白您的问题而浏览您的整个代码库。与其分享所有代码，不如将代码精简到相关的部分。理想情况下，您甚至可以用尽可能少的代码重现问题。有时，将问题简化到足以揭示问题所需的最少代码量，反而有助于您自行解决问题。

分享代码时，如果觉得某些名称会泄露你的工作内容，可以替换掉它们。但务必选择合理的名称。像 `a` Foo、Bar`b` 和`c` 这样的名称Baz在示例代码中很常见，但读起来很糟糕，而且会让很多人感到困惑。另外，尽量不要以图片形式分享代码。分享代码时，阅读者通常会想要复制粘贴到编辑器中进行测试、修改或其他尝试。分享代码截图会阻止阅读者进行这些（必要的）实验，并可能导致他们放弃进一步阅读你的问题。

5. 直奔主题

如果你遵循以上所有建议，你的问题就很好。但如果你做得过火，你的问题就会冗长繁琐，充斥着细节和背景信息。提问时，务必确保问题易于阅读，尽可能简洁明了，同时又不遗漏任何信息。请参考以下示例：

我从设计师那里拿到了一份设计稿，其中包含一些奇怪的用户界面组件。如果您查看附件图片，您会看到一个导航栏、一张图片、一个按钮和一些文本。当我点击按钮时，文本应该淡出，然后出现下一页。导航栏也应该向上移动。流畅运行至关重要。我该如何处理按钮点击事件并触发设计师编写的过渡效果？

这个例子可能看起来有些夸张，但我确实见过这样的提问方式。与其像上面那样提问，不如像这样提问，这样更有价值：

我的设计师为我编写了一个动画，我需要在按钮被点击时触发这个动画。我有一个在按钮被点击时调用的函数，但我不太确定如何在函数内部启动动画。我已经附上了动画代码和按钮事件处理程序。

改写后的问题切中要点，清晰地向读者传达了你的诉求，并提供了足够的细节，让他们能够理解你的出发点和目标。

总之

提问可能很难，尤其对于母语非英语的人来说更是如此。不过，我认为本文分享的五条建议对所有提问者都很有帮助。你越用心写好问题，就越有可能得到好的答案，而且找到答案的速度也会更快。有些情况下，这五条建议可能并不适用于所有问题，但我发现大多数情况下，你都能以某种方式将它们运用到你的问题中。

你还有什么提问技巧吗？或者有什么反馈意见想给我？欢迎在推特上关注我！我很乐意收到你的留言。