计算机一定会百分之百、毫无失误地按照你告诉它们的方式去执行操作。但真正难点在于让它们去做你希望它们做的事情。
你命令计算机执行的操作与你期望它完成的动作之间的差距，正是漏洞产生的根源所在。
作为freeCodeCamp Discord的版主，我经常看到有人发帖说：“我明明一切都做得完全正确，但代码就是无法正常运行！”这些人其实很清楚自己希望代码达到什么效果，但他们并没有正确地告诉计算机该怎么做。
要想解决这些问题，就必须让自己的需求——也就是自己对代码行为的预期——与实际编写的代码保持一致。那些错误的假设正是导致这种差距存在的根源。
假设带来的问题
比如说，我正在制作一个网页，想把某个元素的背景颜色设置成蓝色，但结果却变成了文本的颜色。
我向同事求助，对她说：“我明明告诉计算机要把背景颜色设为蓝色，但它却改成了文本颜色！”
问题在于，我实际上并没有使用正确的属性来设置背景颜色。我错误地使用了color这个属性，而应该使用background-color才对。我的同事根本不知道我在使用错误的属性，因此她也就无法帮助我解决问题。
一个高质量问题的构成要素
寻求帮助需要付出一定的努力。你越是认真地去寻找帮助，就越有可能得到所需的帮助。根据我的经验，在需要技术支持时，一个高质量的问题应该包含以下三个要素。真正优质的问题一定具备这些要素。
-
包含问题的代码片段
-
你遇到的任何错误信息
-
对问题情况的详细描述，其中必须包括：
-
重现问题的具体步骤
-
预期的结果
-
实际得到的结果
-
下面我会详细解释这些要素，这样你在寻求帮助时就能知道该提供哪些信息。
包含问题的代码片段
这其实比听起来要复杂得多。很多时候，我无法自己解决某个问题，就是因为我在错误的地方查找原因。也许我应该查看错误的函数、文件，甚至整个项目！如果我只向同事提供我认为存在问题的那段代码，她可能就无法帮助我。
因此，提供尽可能多的背景信息是非常重要的。这样，帮你解决问题的人就能获得他们所需的所有信息，从而更容易找到解决问题的方法。
即使拥有数十年的编程经验，我仍然经常会对某些代码的行为产生疑虑。能够运行这些代码并进行实验（添加日志记录、使用调试工具、尝试不同的输入数据等等）是我进行开发工作的重要环节。
有很多方法可以将你的代码分享给他人以寻求帮助。以下是一些例子：
对于大型项目
如果你在处理一个大型项目时遇到困难（比如该项目包含多个文件或数百行代码），那么最好的办法是创建一个包含所有代码的GitHub仓库并分享出来。
或者，你可以尝试创建一个“最小化重现环境”。如果能在少量代码中复现问题，那么就可以直接分享这些代码。这样就能大大减少他人帮助你所需的工作量，从而增加你获得所需解决方案的概率。
注意：在为客户或雇主开发项目时，由于无法共享相关代码，你可能无法从外部获取帮助。除非得到明确许可，否则切勿公开分享雇主或客户的代码！
对于单文件项目
如果你的项目只包含一两个文件，或者你可以用少量代码来复现问题，那么可以直接在聊天消息中嵌入代码，或者创建一个包含相关代码的GitHub Gist。
另外，你也可以使用CodePen或StackBlitz等工具来快速生成问题重现环境。
对于freeCodeCamp的学习课程
我在freeCodeCamp的Discord平台上收到的很多问题都与学习平台中的课程内容有关。在提问时，请务必提供以下信息：
-
编辑器面板中所有的代码（也就是你编写或修改过的所有代码）
-
相关教学步骤的链接
如果没有这些信息，别人就很难为你提供帮助。
错误信息
对于初学者来说，错误信息可能会让人感到非常困惑。你之所以会忽略这些信息，是因为它们看起来毫无意义，而且你也不清楚该如何利用它们来解决问题。
仔细阅读错误信息是成为更优秀的程序员的第一步。即使你不明白这些信息的含义，在寻求帮助时，也请务必让有经验的人有机会查看这些信息。如果你的控制台或终端中出现了错误信息，请将它们完整地复制粘贴到你的求助帖中。
问题描述
在寻求帮助时，您应该考虑到向他人求助时，他们可能并不了解您的具体情况。因此，您有责任向他们提供所需的背景信息。为确保自己已经提供了这些信息，请务必包含以下内容：
重现问题的步骤
具体来说，您做了哪些操作才导致了当前的问题？请尽可能详细地描述这些步骤。例如：“我点击了‘提交’按钮”，或者“我在浏览器中打开了https://www.example.com”。
预期结果
我：“我的文本应该是蓝色的！”
同事：“那挺好的。”
我的同事并不是在忽视我的问题，她只是不明白这是否真的算是一个问题。也许我是希望文本变成蓝色的，又或许蓝色文本与我的问题并无关联，甚至可能只有在特定情况下文本才会显示为蓝色。
如果我当时告诉同事我希望背景颜色是蓝色而不是文字本身是蓝色，她很可能就能迅速理解我哪里做错了，并给出解决问题的建议。
实际结果
我：“我希望背景变成蓝色的！”
同事：“那挺好的。”
如果忘记提供实际结果，那么这个问题的描述就几乎毫无意义了。代码的预期结果和实际结果对于一份完整、清晰的问题描述来说都是非常重要的。
在分享实际结果时，截图或视频会非常有用。不过，请确保不要过分依赖这些视觉材料，而忽略了问题描述中其他重要的信息。
示例问题
以下是一个将所有建议结合起来的示例：
我尝试输入了这段代码：
for (iterator; condition; iteration) { }我原本以为这段代码能够正常运行，但实际上却出现了如下错误：
ReferenceError: iterator is not defined有人能帮我看看哪里出问题了吗？这是相关步骤的截图以及出现的错误信息：
这个问题的描述虽然不长，但确实包含了本文所提到的所有要素：它提供了出现问题的代码（包括freeCodeCamp网站上的步骤链接）、显示的错误信息，以及预期的结果和实际发生的结果。此外，还附有有助于理解问题情况的截图。
结语
看来这确实需要花费不少精力。我只不过是想解决自己的问题而已，真的有必要做所有这些事情吗？？？
简短的回答是：有必要。不过，之所以要这么做，是因为这样比与那些试图帮助你的人进行长时间的来回沟通、让他们去收集这些信息要省力得多。不仅如此，如果你按照这些步骤去做并收集到所需的信息，说不定最终你自己就能解决问题，而无需寻求他人的帮助。
这个过程一开始可能会让人觉得繁琐，但就像生活中的很多事情一样，只要坚持定期练习，就会变得容易起来。
你一定可以做到的。😎