如何使用google解决问题

本文介绍了使用google解决难题的一些高级技术，重点讲述了如何选择关键字，如何分析过滤信息等等。

Table of Contents 1. 声明 2. 本文所面向的读者 3. 如何使用google解决各种问题

3.1. 不可能完成的任务 3.2. 如何快速解决具体技术问题 3.3. 如何解决复杂抽象的问题4. 如何提高自己的搜索能力 4.1. 态度决定一切 4.2. 疯狂搜索法 4.3. 如何提高“搜索素养”

1. 声明

请读者不要使用本文所介绍的技巧从事违法、不道德的事情。我对于本文所导致的任何后果概不负责。

2. 本文所面向的读者

本文介绍了使用google解决难题的一些高级技术，重点讲述了如何选择关键字，如何分析过滤信息等等。通过阅读本文，你会明白在极大的时间压力下快速解决高难度问题的技巧。你也能了解如何对一些复杂的问题进行调查并给方案。任何对解决问题有兴趣的人都适合阅读本文，只要：

你不相信“软件蓝领”的说法。你相信解决问题的能力是人的本能。你相信任何问题的本质都是一样的。你相信解决问题需要的能力是想象力和举一反三的能力。

说的明白一点，我希望读者是有职业荣誉感的工程师，或者是能够理解这种荣誉感的人。有些人害怕自己即将被技术的进步所淘汰，于是试图通过贬低技术人员的地位来获得安全感。由于他们不能否认技术所取得的伟大成就，于是使用一些政治手腕来间接地达到目的。最常用的手段就是虽然技术是伟大，但是工程师是分等级的（是不是封建残余思想作怪？），低级的工程师就是蓝领，而中国需要的是大量的蓝领，等等。这种有封建残余思想的人是不可能学习新东西的，当然也不可能理解本文，因为要成为google高手，就必须具备开放的头脑和丰富的想象力。

3. 如何使用google解决各种问题3.1. 不可能完成的任务

一个中国公司的项目组的主要工作是测试一个日本的项目组用C语言开发的系统（调试器为gdb）。一次日本程序员遇到了一个奇怪的问题，当他们用gdb调试时，程序会突然退出。这些程序员研究了两天两夜，不能找出原因。于是他们把退出前调试器上显示的一段错误信息email给中国小组。要求这个小组找出原因。

这个组的组长要我帮忙。我看了错误信息，用到了我不熟悉的进程间通信技术。我首先要求重现错误。“无法重现，因为不知道程序是在哪崩溃的，而我们这也没有运行环境”，回答的斩钉截铁。我要求看源代码。组长告诉我，可以给我看的都是旧代码，出问题的代码早更新过几个版本了，中方暂时还拿不到新代码。说白了，就是没代码。我告诉组长，在这种条件下要解决问题是不可能的。但是领导的意思是利用手头的信息，争取当天解决。

让我小结一下。无法重现错误，没有源代码，不了解相关技术，无法定位bug的大概位置，开发者自己花了两天两夜也无法找出bug原因。而我只有一小段错误信息，除此之外连系统干什么的都不清楚，并被告知不要指望进一步的帮助了。我该如何解决这个问题？

在读者解答这个问题前，我给点提示，日本程序员都是有经验的，他们肯定已将错误信息用google翻了个遍。

给出这个问题的答案花了我15分钟时间。这15分钟时间内我没有读任何文档或者代码。在说明答案前，让我先试着给出思路。我猜日本人已经查过相关的技术手册了，所以我没有必要读手册。给我的信息有限，是因为日方只能提供这些线索。现在看看给我们的一段错误信息是什么？无非是程序退出时，调试器gdb打印的一些信息。例如退出的进程收到了什么信号，该信号是哪个进程发送的等等。我的下一个假设就是日方已经google过这些信息，所以我也不能从这些信息中挖出什么东西了。

要解决问题，就必须发挥想象力，做日本人“没有做过的事情”。日本人没有做过什么？我猜没有做过一件事情，那就是google一下冗余信息。gdb显示错误信息的时候，会以一定的格式显示，比如若干个空格加个冒号什么的。现在我将这些错误信息随机取出一行，这一行既包括了有用的信息，也包括了冗余的信息。我在这一行的内容前后加上双引号，以告诉google尽可能严格匹配该行。然后以此作为关键字google到了答案。答案来自于gdb的一个mailing list，gdb的开发者解释说这是gdb的一个bug，该bug在特定条件下使用特定版本的gdb调试才会发生。

事实上当时我根本没有做如上的分析，接到任务后我做的第一件事就是google冗余信息。这是我的习惯。冗余信息和有意义的信息一起检索的好处是可以快速定位到有同样问题的人。缺点排除了一些有用信息。例如我现在检索gdb的冗余信息，就排除了使用别的调试器的人。好在internet上信息实在是太丰富，过滤掉有用信息不是问题。真正的的问题是从无用信息中快速定位有用信息！

3.2. 如何快速解决具体技术问题

[1] [2] [3] [4]

一些“聪明人”相信，只要有某种“伟大、正确”的思想（比如某种“大法”）的指导，任何难题都可以摆平（摆平的方法就是背诵一下伟大思想中的某些特别棒的词）。没有这种信仰的人，只是愚昧无知的小爬虫。“聪明人”解决问题很简单，对问题大面上讲一讲，再念一下咒语。本文是由我，小爬虫中的一条写的，小爬虫不能理解伟大的思想。我解决问题采用和“聪明人”相反的方法。就是从不起眼的细节入手，发挥想象力，举一反三。这个过程中“伟大、正确”的思想连影子也没有出现。

最近我接到了一个任务，要求实现一个扫描给定目录下的文件的模块。问题的难点是这个模块作为一个共享模块（shared ojbect），必须知道自己的物理路径。由于运行平台是Linux，并没有直接支持这种功能的API函数（和Linux应用程序的部署规范有关系）。现在如果我必须实现该功能，该使用什么关键字搜索？

最直接的想法就是google“get shared object path linux”。得到的都是如何在Linux下开发共享模块的文章。增加其他关键字，例如“shared library”，“physical path”，结果也差不多。这个问题的难点不在于选择足够多的关键字以过滤出需要的信息，而是根本就没有信息可以过滤。之所以没有信息可以过滤，是因为Linux有自己的应用程序部署规范（例如配置文件应该放在/etc目录下，可执行文件放在/usr/local/bin目录下等）。如果遵循了这种规范，就没有必要知道共享模块的物理路径了。通常获得共享模块的物理路径是为了由该路径推算配置文件的路径。

最终问题还是被我解决了。我使用了什么关键字？答案很简单，既然正面攻击无效，就旁敲侧击。想一想，如果运行平台是Windows，如何实现该功能？Windows下通常用“GetModuleFileName”API实现。如果有些程序员要把Window的程序移植到Linux下，他（她）该拿GetModuleFileName怎么办呢？答案出来了，google“GetModuleFileName linux”。搜索结果第一条标题是“Qt-interest Archive - location of the program i am running”，就是关于如何获得一个可执行文件的路径的。分析一下google第一页的搜索结果，发觉有一些干扰信息（如何判断干扰信息我将在后文说明）。这说明我们需要稍微修正一下关键字。google“GetModuleFileName +linux”（这里的加号表示linux作为关键字必须出现在搜索结果中）。搜索结果第17条标题为“Guide to Making Relocatable Applications :: autopackage”，这就是标准答案了。

< …… 此处隐藏：3300字，全部文档内容请下载后查看。喜欢就下载吧 ……