如何作为 dev 提出精彩的问题（不因 Imposter Syndrome 而崩溃）

Source: Dev.to

我也经历过。相信我，我真的经历过。 在钢筋混凝土的丛林里。 与穿西装的怪兽们一起。（好吧，其实是连帽衫。永远是连帽衫。）

我讨厌提问——承认自己有不懂的东西是我刚加入时的噩梦。所以我深知这有多难，尤其是当你身边的每个人看起来像是出生就懂 Docker、Git，以及 == 与 === 区别的人。

无论你是刚起步还是已经在行业里混了一段时间，有一点是不可避免的：你会有不懂的东西。你会卡住。你把这些问题一直藏在脑子里，冒名顶替综合症的怪兽就会越长越大。

它会开始低声呢喃诸如：

• “其他人都懂。”
• “你只是笨，配不上这里。”
• “如果你问，他们就会知道你是个骗子。”
• “只要盯着 bug 看得更久，它会自己修好。”（不会的。）

什么是好问题？

在我们讨论 如何 提出好问题之前，让我们先定义一下好问题到底是什么。

好问题就是……一个问题。任何你真诚想问的问题都是好问题——只要它出于好奇心和努力，而不是懒惰。

Good questions:

• 帮助你更快获得更好的答案
• 表明你在乎理解，而不仅仅是解除自己的卡住
• 随着时间的推移建立可信度
• 强化你的问题解决能力

坏问题并不是听起来“太基础”的问题。坏问题是指在提问之前根本没有任何努力的情况。

完成作业（是的，这很重要）

在提问之前，先快速进行现实检查：

• 你是否已经 在 Google 上搜索？
• 查看过 Stack Overflow？
• 阅读过文档（至少 略读 过）？
• 亲自尝试过调试？
• 搜索过是否已有相同的问题被提出？

换句话说：先自行提问，看看能收集到多少信息。你不需要完全解决它——只要尝试即可。努力是显而易见的，努力也会受到尊重。

如何组织你的提问（让别人真的想帮忙）

1. 提供上下文

先说明你想要做什么，而不是仅仅说哪里坏了。若不了解整体情况，别人很难帮忙。

错误示例：“这根本不工作。”
正确示例：“我想在登录后获取用户数据并把它渲染到表格中。”

2. 展示你已经尝试的办法

没有什么比说“这是我已经尝试过的”更能赢得好感的了。列出你的尝试以及出现的结果，即使它们是错误的。

3. 包含相关细节（不要写你的生活史）

• 你的运行环境（操作系统、语言版本、框架版本）
• 准确的错误信息（复制粘贴）
• 能复现问题的最小代码片段
• 你期望的结果与实际发生的结果

排除：整个代码库、400 行的文件，或是不愿意学习的态度。

4. 要具体

不要说“我的代码不好用”，可以改成：

“我的 React 组件在 API 数据请求未完成前渲染时抛出 Cannot read property ‘map’ of undefined 错误。”

具体的问题会得到具体的答案。

5. 让帮助变得容易

你不仅是在求助——你在合作。

• 正确格式化代码
• 保持示例简洁
• 去除干扰因素

如果帮助感觉像是布置作业，大家会悄悄退场。

Source: …

问题模板（偷来使用）

调试帮助

我正在尝试 [目标]，但出现了 [实际情况]。

以下是我的代码：**[最小示例]**

错误信息：**[完整错误]**

我已经尝试过：**[尝试列表]**

环境：**[相关版本]**

概念性问题

我正在学习 [主题]，并试图理解 [具体概念]。

截至目前我的理解是：**[你当前的理解]**。

我困惑的地方：**[具体的疑惑]**。

背景：**[这对你为何重要]**。

最佳实践 / 设计决策

我需要 [完成任务]。

我在考虑 **[方案 A]** 与 **[方案 B]**。

我的约束条件是：**[限制条件]**。

这里有哪些权衡取舍？

什么不要做（请）

• “我可以问个问题吗？” — 直接问吧。
• “这可能是个蠢问题” — 不要贬低自己。
• 期待别人调试你的整个代码库。
• 在一条信息里提五个不相关的问题。
• 获得帮助后消失。

获得答案后

做这些事。它们比你想象的更重要：

• 说声谢谢。
• 分享哪些方法有效。
• 如果你后来自己解决了，发布解决方案。
• 有能力时回馈帮助他人。

今天困惑的开发者，明天就会成为在 Teams 上凌晨 11 点回答问题的高级工程师。

Remember

每个人曾经都是新手。提问并不会让你能力变低——它会让你成为（更）好的学习者。最优秀的开发者并不是凭空知道一切；他们只是变得非常、非常擅长提出好问题。而现在，你也可以做到。