新手程序员，必看！！ 提问的智慧
原文链接
新手程序员的上分之路！
我自己就是新人，刚刚接触工作，发现什么什么都看不懂，什么都想问，也不管别人听到是什么想法，自己没有意识到你问的表达清楚了吗？您有自己去思考吗？你有去查找资料吗？别人是否有时间去回答你？
今天我们来读一读提问的智慧，前人的总结，字字珠玑，引人深思。
引言
技术提问的解答情况，很大程度上取决于提问的方式与解决此问题的难度，本文将教你如何提问才更有可能得到满意的答复。
首先需要明白的事是程序员都喜欢难题和激发思考的好问题。如果你能提出一个有趣的问题来让我们咀嚼玩味，我们会感激你的。好问题是种激励与礼物，帮助我们扩展认知，揭示我们没有注意或想到的问题。『好问题！』 是非常热烈而真挚的赞许。
资深程序员还有遇到简单问题就表现出敌视或傲慢的态度。有时，这看起来是对新手条件反射式性的无礼，但事情并不真是这样。
提问前
在通过论坛提技术问题以前，做以下事情：
尝试在你准备提问的论坛中搜索答案 ；
尝试搜索互联网以找到答案；
尝试阅读官方文档以找到答案；
尝试阅读 “常见问题文档”（FAQ）以找到答案；
尝试自己检查或试验以找到答案；
尝试请教懂行的朋友以找到答案；
尝试阅读源代码以找到答案。
提问时，请先表明你已做了上述事情，这将有助于建立你不希望浪费别人时间的印象。最好再表述你从中学到的东西 ，我们喜欢回答那些表现出能从答案中学习的人。
轻率的提问只能得到轻率的回答，或者压根没有。在提问时，你越是表现出在此前做过思考与努力去解决自己的问题，你越有可能得到真正的帮助。
注意别提错问题。如果提问基于错误的假设，资深的程序员多半会一边想 “愚蠢的问题……”，一边按将错就错的答案回复你，并且希望这种只是得到你自己 “问的问题” 而非真正所需的解答以给你一个教训。
永远不要假设你有资格得到解答。你没有这种资格，毕竟你没有为此服务付费。
提问时
仔细挑选论坛
要对在哪提问留心，如果你做了下述事情，多半会被一笔勾销或被看成 “失败者”：
张贴与论坛主题无关的问题
在面向高级技术问题的论坛上张贴肤浅的问题，或者反之。
在多个不同的论坛中同时张贴
给既非熟人也没有义务解决你问题的人发送私信
为保护通信的渠道不被无关的东西淹没，资深程序员会默认过滤掉那些没有找对地方的问题，你不会想让这种事落到自己头上的。
不要假设一个内容丰富的作者会想充当你的免费顾问，不要对你的问题是否会受到欢迎做太乐观的估计 ── 如果你不确定，到别处发或者压根别发。
老练的程序员和一些流行软件的作者，他们正在承受过多的不当消息。就像那根最后压垮骆驼背的稻草一样，你的加入也有可能使情况走向极端 ── 已经好几次了，一些流行软件的作者退出了对自己软件的支持，就是因为涌入其私人邮箱的垃圾邮件变得无法忍受。
使用有意义且明确的标题
标题是你在五十个或更少的字以内吸引有资格专家注意的黄金机会，不要用诸如 “请帮我” ，这种主题的消息会被条件反射式地删掉）之类的唠叨浪费机会。不要用你痛苦的深度来打动我们，相反，要在这点空间中使用超级简明扼要的问题描述。
愚蠢：
救命啊！我的笔记本视频工作不正常！
明智：
Laravel 8 下安装 xxx 扩展包无法正常使用！
更明智：
Laravel 8 下安装 xx 版本的 xxx 扩展包无法正常使用，开发环境是 Win！
用清晰、语法、拼写正确的语句书写
经验告诉我们，粗心与草率的作者通常也粗心与草率地思考和编程（我敢打赌）。为这些粗心与草率的思考者回答问题没有什么好处，我们宁可将时间花在其它地方。
清楚、良好地表达你的问题非常重要。如果你觉得这样做麻烦，我们也觉得注意（你的问题）麻烦。花点额外的精力斟酌一下字句，用不着太僵硬与正式 ── 事实上，黑客文化很看重能准确地使用非正式、俚语和幽默的语句。但它必须很准确，而且有迹像表明你是在思考和关注问题。
如果你写得像个半文盲似的傻子，代码也没高亮，多半得不到理睬。更糟的是，如果像个小孩似地鬼画桃符那绝对是在找死，可以肯定没人会理你（或者最多是给你一大堆指责与挖苦）。
尽量不要用互联网词汇，例如 YYDS，这会让人感觉你很轻浮，没有在认真提问。
描述问题应准确且有内容
仔细、清楚地描述问题的症状
描述问题发生的环境 (操作系统、应用程序版本、浏览器型号，任何相关的)，这些东西再具体都不为过。
描述提问前做过的研究及其理解。
描述提问前为确定问题而采取的诊断步骤。
描述最近对系统或软件配置的任何相关改变。
如果可能，提供在可控环境下重现问题的方法。
尽最大努力预测回答者会提到的问题，并提前备好答案。
如果你认为是代码有问题，向回答者提供在可控环境下重现问题的方法尤其重要。当你这么做时，得到有用且及时回复的可能性将大大增加。
量不在多，精炼则灵
你应该（写得）精炼且有内容，简单地将一大堆代码或数据罗列在求助消息中达不到目的。如果你有一个很大且复杂的测试样例让程序崩溃，尝试将其裁剪得越小越好。
至少有三个理由支持这点。
第一，让别人看到你在努力简化问题将使你更有可能得到回复。
第二，简化问题将使你更有可能得到有用的回复。
第三，在反馈 Bug 报告的过程中，你可能自己就找到了解决办法或权宜之计。
低声下气代替不了做自己的家庭作业
有些人明白他们不应该粗鲁或傲慢地行事并要求得到答复，但他们退到相反的低声下气的极端：“我知道我只是个可怜的小菜鸟，一个失败者，但……”。这给人带来消极的情绪，也没有用，当伴随着对实际问题含糊的描述时还特别令人反感。
别用低级灵长类动物的办法浪费你我的时间，相反，自信地尽可能清楚地描述背景情况和问题，比低声下气更好地摆正了你的位置。
描述问题症状而不是猜测
在问题中书写是什么导致了问题是没用的（如果你的诊断理论是了不起的东西，你还会向别人咨询求助吗？）。所以，确保只是告诉他们问题的原始症状，而不是你的解释和理论，让他们来解释和诊断。如果你认为陈述自己的猜测很重要，应清楚地说明这只是你的猜测并描述为什么它们不起作用。
愚蠢：
我在编译 Go 程序时遇到错误，怀疑是环境变量的问题，如何定位问题？
明智：
我在编译 Go 程序时候遇到 xxx 提示错误（错误代码附后面），我怀疑是 xxx 环境变量的原因，因为最近我的系统做了 xxx 的修改。我已经做了这些和那些操作，但是仍然不起作用。
按时间先后罗列问题症状
出问题之前发生的事情通常包含有解决问题最有效的线索。
记录中应准确地描述你、系统和软件在崩溃前都做了什么。在命令行处理的情况下，有会话日志并引用相关的若干（如 20）行记录会非常有帮助。
如果崩溃的程序有诊断选项（如 - v 详述开关），试着选择这些能在记录中增加排错信息的选项。记住，“多” 不等于 “好”。
如果你的记录很长（如超过四段），在开头简述问题随后按时间先后罗列详细过程也许更有用。这样，大神在读你的记录时就知道该注意哪些内容了。
描述目标而不是过程
如果你想弄清楚如何做某事（而不是报告一个 Bug），在开头就描述你的目标，然后才陈述遇到问题的特定步骤。
经常出现这种情况，寻求技术帮助的人在脑袋里有个更高层次的目标，他们在自以为能达到目标的特定道路上被卡住了，然后跑来问该怎么走，但没有意识到这条路本身有问题，结果要费很大的劲才能通过
愚蠢：
我怎样才能让某图形程序的颜色拾取器取得十六进制的 RGB 值？
明智：
我正试着用自己选定数值的颜色替换一幅图片的色表，我现在知道的唯一方法是编辑每个表槽，但却无法让某图形程序的颜色拾取器取得十六进制的 RGB 值。
第二种提法是明智的，它使得建议采用更合适的工具以完成任务的回复成为可能。
慎用私信
社区资深开发者认为问题的解决过程应该公开、透明，此过程中如果更有才能的人注意到不完整或者不当之处，最初的回复才能够、也应该被纠正。同时，作为回复者也因为能力和学识被其它同行看到而得到某种回报。
公开的回答，也可惠及后人，当别人遇到相同问题的时候，可以通过搜索进来而得到答案。论坛里再次出现类似的问题时，我们也可以引用此问答帖。
当你要求私下回复时，此过程和回报都被中止。别这样做，让回复者来决定是否私下回答 ── 如果他真这么做了，通常是因为他认为问题编写太差或者太肤浅，以至于对其它人毫无意义。
提问应明确
漫无边际的问题通常也被视为没有明确限制的时间无底洞。最有可能给你有用答案的人通常也是最忙的人（假如只是因为他们承担了太多工作的话），这些人对于没有止境的时间无底洞极其敏感，所以他们也倾向于讨厌那些漫无边际的问题。
如果你明确了想让回复者做的事（如指点方向、发送代码、检查补丁或其它），你更有可能得到有用的回复。（因为）这样可以让他们集中精力并间接地设定了他们为帮助你需要花费的时间和精力上限，这很好。
要想理解专家生活的世界，可以这样设想：那里有丰富的专长资源但稀缺的响应时间。你暗中要求他们奉献的时间越少，你越有可能从这些真正懂行也真正很忙的专家那里得到解答。
所以限定你的问题以使专家回答时需要付出的时间最少 ── 这通常与简化问题还不太一样。举个例，“请问可否指点一下哪有好一点的 X 解释？” 通常要比 “请解释一下 X” 明智。如果你的代码不运行了，通常请别人看看哪有问题比叫他们帮你改正更明智。
关于代码的问题
别要求他人给你出问题的代码排错而不提及应该从何入手。
张贴几百行的代码，然后说一声 “它不能运行” 会让你得不到理睬。精简下代码，只贴几十行代码，然后说一句 “在第七行以后，本应该显示
如果你只是想让别人帮忙审一下代码，在最开头就要说出来，并且一定要提到你认为哪一部分特别需要关注以及为什么。
删除无意义的要求
抵制这种诱惑，即在求助消息末尾加上诸如 “有人能帮我吗？” 或 “有没有答案？” 之类在语义上毫无意义的东西。
第一，如果问题描述还不完整，这些附加的东西最多也只能是多余的。
第二，因为它们是多余的，高手会认为这些东西烦人──就很有可能用逻辑上无误但打发人的回复，诸如 “是的，你可以得到帮助” 和 “不，没有给你的帮助”。
一般来说，避免提 “是或否” 类型的问题，除非你想得到 “是或否” 类型的回答。
不要把问题标记为 “紧急”， 即使对你而言的确如此
这是你的问题，不是我们的。
宣称 “紧急” 极有可能事与愿违：大多数回答者会直接略过这种消息，他们认为这是无礼和自私地企图得到即时与特殊的关照。而且 “紧急” 或其它有类似含义的主题有可能触发垃圾过滤规则，潜在的回复者可能永远看不到你的问题！
有一点点例外，如果你有期限压力，也很有礼貌地提到这点，人们也许会有足够的兴趣快一点回答。
礼貌总是有益的
礼貌一点，使用 “请” 和 “谢谢你的关注” 或者 “谢谢你的关照”，让别人明白你感谢他们无偿花时间帮助你。
这一点没有语法正确、文字清晰、准确、有内容和避免使用专用格式重要（同时也不能替代它们）。资深程序员一般宁可读有点唐突但技术鲜明的 Bug 报告，而不是那种有礼但含糊的报告。
然而，如果你已经讲清楚了技术问题，客气一点肯定会增加你得到有用回复的机会。
问题解决后追加一条简要说明
问题解决后向所有帮助过的人追加一条消息，让他们知道问题是如何解决的并再次感谢。如果问题得到广泛关注，追加回复尤为重要，这让大家知道你是有始有终的人，下次也更愿意帮你。
追加的消息用不着太长或太复杂，一句简单的 “原来是系统坏了！谢谢大家” 就比什么都没有要强。事实上，除非解决问题的技术真正高深，一条简短而亲切的总结比长篇大论要好。说明是什么行动解决了问题，用不着重演整个排错的故事。
除了有礼貌、有内容以外，这种类型的追帖将帮助遇到类似问题的其他人，共建互助的社区氛围。
最后，此类追帖还让每位参与协助的人因问题的解决而产生一种满足感。
如何解读回答
“多读读文档” 或者 “搜索一下就知道了”#
在论坛，你也可能被要求去搜索论坛的文档。事实上，有人甚至可能热心地为你提供以前解决此问题的线索。但不要依赖这种关照，提问前应先自行搜索一下文档。
通常，叫你搜索的人已经打开了能解决你问题的手册或网页，正在一边看一边敲键盘。这些回复意味着他认为：第一，你要的信息很容易找到。第二，自已找要比别人喂到嘴里能学得更多。
你不应该觉得这样就被冒犯了，按社区的标准，回复者没有不理你就是在向你表示某种尊敬，你反而应该感谢他热切地想帮助你。
如果还不明白……
如果你看不懂回答，不要马上回复一个要求说明的消息，先试试那些最初提问时用过的相同工具（如手册、FAQ、网页、懂行的朋友等）试着搞懂回答。如果还是需要说明，展现你已经明白的。
譬如，假如我告诉你：“看起来像是某个输入的参数有问题，你需要清除它”，接着是个不好的回帖：“什么参数？”。而这是一个很好的跟帖：“是的，我读了手册，某某输入项只在 -z 和 -p 开关中被提到，但都没有涉及到如何清除它们，你指的是哪一个还是我弄错了什么？”
对待无礼
有时候看似无礼的回复并不是存心冒犯。相反，它是直接了当、一针见血式的交流风格，这种风格对于更关注解决问题而不是使别人感觉舒服而混乱的人是很自然的。
如果你觉得被冒犯了，试着平静地反应。如果有人真的做了出格的事，论坛中的前辈多半会招呼他。
另一方面，你会偶而真的碰到无礼和无聊的言行。遇到这种情况，直接提交举报即可，社区管理员会酌情进行处置。
请记住，纠正无礼的言论与开始一场口水战仅一线之隔，而口水战毫无意义，不仅会影响你的情绪，还会影响工作效率，得不偿失，能避则必。提交举报是最好的处理方式，施暴者最终会得到相应的处理。
提问禁忌
下面是些典型的愚蠢问题和资深程序员不回答它们时的想法。
问：
我到哪可以找到某程序或 X 资源？
答：
在我找到它的同样地方，是傻的吗 ── 连搜索引擎都不知道怎么用吗？
问：
我怎样用 X 做 Y？
答：
如果你想解决的是 Y，提问时别给出可能并不恰当的方法。这种问题说明提问者不但对 X 完全无知，也对要解决的 Y 问题糊涂，还被特定形势禁锢了思维。等他们把问题弄好再说。
问：
如何配置我的 shell 提示？
答：
如果你有足够的智慧提这个问题，你也该有足够的智慧去 “读读该死的手册”，然后自己去找出来。
问：
我可以用 Bass-o-matic 文件转换工具将 AcmeCorp 文档转为 TeX 格式吗？
答：
试试不就知道了。如果你试过，你既知道了答案，又不用浪费我的时间了。
问：
我的 {程序、配置、SQL 语句} 不运行了
答：
这不是一个问题，我也没有兴趣去猜你有什么问题 ── 我有更要紧的事要做。看到这种东西，我的反应一般如下：
没有什么补充吗？需要花费多少次互答才能了解最终的原因，算了，太浪费时间了。
祝你好运。
这跟我究竟有什么关系？
问：
我的 Windows 电脑出问题了，你能帮忙吗？
答：
是的，把 Windows 垃圾删了，装个像 Linux 或 BSD 的开源操作系统吧。
注意：如果程序有官方的 Windows 版或者与 Windows 有交互 (如 Samba)，你 可以 问与 Windows 相关的问题，只是别对问题是由 Windows 操作系统而不是程序本身造成的回复感到惊讶，因为 Windows 一般来说太差，这种说法一般都成立。
问：
我的程序不运行了，我认为系统工具 X 有问题
答：
你完全有可能是第一个注意到被成千上万用户反复使用的系统调用与库文件有明显缺陷的人，更有可能的是你完全没有根据。不同凡响的说法需要不同凡响的证据，当你这样声称时，你必须有清楚而详尽的缺陷说明文档作后盾。
问：
我安装 Linux 或 X 遇到困难，你能帮忙吗？
答：
不行，我需要亲手操作你的电脑才能帮你排错，去向当地的 Linux 用户组寻求方便的帮助
注意：如果安装问题与某 Linux 发行版有关，在针对它的邮件列表、论坛或本地用户组织中提问也许是恰当的。此时，应描述问题的准确细节。在此之前，先用 “linux” 和 所有被怀疑的硬件 [作关键词] 仔细搜索。
问：
我如何才能破解超级用户口令 / 盗取通道操作员的特权 / 查看某人的电子邮件？
答：
想做这种事情说明你是个卑劣的家伙，想让黑客教你做这种事情说明你是个白痴。
好问题与坏问题
最后，我将通过举例来演示提问的智慧。同样的问题两种提法，一种愚蠢，另一种明智。
愚蠢：我在哪能找到关于 Foonly Flurbamatic 设备的东西？
这个问题在乞求得到 “搜搜该死的网络”（STFW） 式的回复。
明智： 我用谷歌搜索过 “Foonly Flurbamatic 2600”，但没有找到什么有用的，有谁知道在哪能找到这种设备的编程信息？
这个人已经搜索过网络了，而且听起来他可能真的遇到了问题。
* 愚蠢： * 我不能编译某项目的源代码，它为什么这么破？
提问者假设是别人搞砸了，太自大了。
明智： 某项目的源代码不能在某 Linux 6.2 版下编译。我读了常见问题文档，但其中没有与某 Linux 相关的内容。这是编译时的记录，我做错了什么吗？
提问者已经指明了运行环境，读了常见问题文档（FAQ），列出了错误，也没有假设问题是别人的过错，这家伙值得注意。
* 愚蠢： * 我的主板有问题，谁能帮我？
某黑客对此的反应可能是：“是的，还需要帮你拍背和换尿布吗？”，然后关闭网页。
* 明智： * 我在 S2464 主板上试过 X、Y 和 Z，当它们都失败后，又试了 A、B 和 C。注意我试 C 时的奇怪症状，显然某某东西正在做某某事情，这不是期望的行为。通常在 Athlon MP 主板上导致某某事情的原因是什么？有谁知道我还能再试点什么以确定问题？
相反地，这个人看来值得回答。他或她展现了解决问题的能力而不是坐等天上掉馅饼。
如果得不到回答
如果得不到回答，请不要认为我们不想帮你，有时只是因为的确不知道答案。没有回复不等于不被理睬，当然必须承认从外面很难看出两者的差别。
一般而言，直接将问题再张贴一次不好，这会被视为毫无意义的骚扰。耐心一点，知道你问题答案的人可能生活在不同的时区，有可能正在睡觉，也有可能你的问题一开始就没有组织好。
还有其它资源可以寻求帮助，通常是在一些面向新手的资源中。
有许多在线与本地的用户组织，虽然它们自己不编写任何软件，但是对软件很热心。这些用户组通常因互助和帮助新手而形成。
还有众多大小商业公司提供签约支持服务，别因为要付点钱才有支持就感到沮丧！毕竟，如果你车子的汽缸垫烧了，你多半还得花钱找个修理店把它弄好。即使软件没花你一分钱，你总不能指望服务支持都是免费的。
如何更好地回答
态度和善一点。问题带来的压力常使人显得无礼或愚蠢，其实并不是这样。
对初犯者可以私信回复。 对那些坦诚犯错之人没有必要当众羞辱，一个真正的新手也许连怎么搜索或在哪找 FAQ 都不知道。
如果你不确定，一定要说出来！ 一个听起来权威的错误回复比没有还要糟，别因为听起来像个专家好玩就给别人乱指路。要谦虚和诚实，给提问者与同行都树个好榜样。
如果帮不了忙，别妨碍。 不要在具体步骤上开玩笑，那样也许会毁了用户的安装 ── 有些可怜的呆瓜会把它当成真的指令。
探索性的反问以引出更多的细节。 如果你做得好，提问者可以学到点东西──你也可以。试试将很差的问题转变成好问题，别忘了我们都曾是新手。
尽管对那些懒虫报怨一声 “手册里有” 是正当的，但是指出文档的位置（即使只是建议做个谷歌关键词搜索）会更好。
如果你决意回答，给出好的答案。 当别人正在用错误的工具或方法时别建议笨拙的权宜之计，应推荐更好的工具，重新组织问题。
请回答真正的问题！如果提问者已经做了自己该做的研究，并且说明尝试过 X，Y，Z，A，B 与 C 都没有得到想要的結果，那么回复 “试试 A 或 B” 或者给出一个内容为 “试一下 X，Y，Z，A，B 或 C” 的链接将极其无益！
帮助壮大社区。当回复一个好问题时，问问自己 “如何修改相关文件或 FAQ 文档以免再次解答同样的问题？”，接着再向文档维护者发一份补丁。
如果你是在研究一番后才做出的回答，展现你的技巧而不是直接端出结果。毕竟 “授人以鱼，不如授人以渔”。