第2条：在网上确切地查询你所遇到的问题，以寻求解决问题的灵感
现在很少有哪个工作场所不能上网，如果在一个无法上网的地方开发程序，那我的效率会很低。遇到代码错误的时候，我们应该上网搜索，或者与同事一起寻找解决办法。
有一个相当有效的搜索技巧，是把由第三方组件所给出的错误消息打上双引号，并将其粘贴到浏览器的搜索框里面。把待搜索的内容放在一对双引号中，意思是要告诉搜索引擎：只搜索与该内容精确匹配的页面。这样做可以使搜索结果更加准确。还有一个很有用的技巧，是把与错误有关的程序库或中间件的名称、对应的类名或方法名，以及所返回的错误代码，也一并放在搜索框里面。要查找的函数名称越罕见，搜索到的结果也就越确切，例如，搜寻PlgBlt所得到的结果，要比搜寻BitBlt好得多。此外，我们也应该试着搜索意思相近的词，例如，除了搜索“hangs”（挂起），还可以搜索“freezes”（冻结），除了搜索“disabled”（禁用），还可以搜索“grayed”（变灰）。
要想解决一些与API调用有关的难题，我们通常可以观察其他人是如何使用这些API的。我们可以看看开源软件如何使用某个函数，如何对传给该函数的参数进行初始化，以及如何解读函数所传回的结果。在这种情况下，专门用来搜索代码的引擎（如Black Duck Open Hub Code Search），要比Google那样的通用引擎更好。例如，如果在这个搜索引擎里面查找mktime，并且只看与某个项目有关的代码，而过滤掉程序库的声明及定义，那我们就会发现下面这样的代码片段：
通过上述代码片段，我们可以看出：mktime函数与localtime函数有所不同，它要求传入的年份必须是完整的数值，而不是距离1900年的偏移量，而且它的月份是从1开始计算的。这两个地方经常会出错，对于那些没有仔细阅读函数文档的人来说，更是容易在调用时传入错误的参数。
在查看由搜索引擎所给出的结果时，我们要注意这些结果是从哪个网站抓取到的。StackExchange旗下的网站（如Stack Overflow）通过很多措施来鼓励用户进行有效的交流，因此，在由搜索引擎所给出的结果中，有很多比较切题的讨论及答案都来自这个系列的网站。在浏览Stack Overflow上面的答案时，不仅要看提问者所接受的那个回答，而且还要看看其他那些赞同数量比较高的回答。除了答案的正文，我们还可以关注答案下面的评论，因为很多人都会通过评论的方式来给出新的消息，例如，有人会在评论中告诉大家，自己发现了一个可以避免错误的新办法。
如果你把自己精心构造的关键词放入搜索引擎之后，并没有得到有用的结果，那么或许意味着你找错了目标。对于常见的程序库与软件来说，你不太可能成为第一个遭遇某问题的人，因此，如果在网上找不到类似的描述，那可能说明你对问题的判断发生了偏差。例如，你本来以为程序崩溃的原因是某个API函数的实现有bug，但实际上却是传入的日期有误。
如果网上找不到答案，那你可以在Stack Overflow网站提问，把自己所面对的问题描述出来，然而，这需要花一定的时间来构建一个简单、自足且正确的范例（SSCCE）。凡是在论坛发问，都应该遵循该SSCCE原则，也就是要给出一个其他人可以直接复制、粘贴并编译的例子，使得他们能够看到你所经历的问题（参见第10条）。对于某些编程语言来说，甚至可以把范例代码嵌入SourceLair或JSFiddle这样的在线IDE，令大家能够在网上直接看到运行效果。sscce.org网站详细解释了应该怎样针对具体的语言和技术来构造良好的范例。Eric Raymond所写的文章《How To Ask Questions The Smart Way》也与这个话题有关，值得一读。
笔者发现：只要我能够恰当地描述问题，并且附上合适的范例，那么该问题的解决方案通常就会自然地浮现出来。就算我自己找不到答案，这样的问题也可以吸引一些懂行的人过来进行试验，他们或许能找到办法。
如果你所遇到的问题在某种程度上与开源的软件库或程序有关，而且你认为它们的代码中很可能有bug，那么可以联系其开发者。常见的做法应该是访问那个开源项目的bug追踪系统，并在上面提交一项事务。提交的时候，也应该首先确保其他人没有报告过类似的bug，并且要把重现该问题的详细步骤准确地写进去。如果那款软件没有bug追踪系统，那你可以给它的作者发邮件，邮件要写得相当谨慎，措辞要得体、语气要谦和，因为大部分开源软件的开发者都不是你的雇工。
要点
- 把错误消息打上双引号，以便在网上准确地进行搜索。
- 认真查看StackExchange系列网站上面的回答。
- 如果上述两种办法都不见效，那你可以自己提问或提交事务。