有很多次，我一直在调试一个复杂的问题。更多的时候，是我做了一些疯狂的事情，而且在当时看来是一个好主意。无论是一个无休止的递归循环，还是代码中的一个好的错误。

我们都有自己的调试方法，有时它们真的很有效。然而，其他时候，他们只是熟悉，所以那是我们的第一选择武器。熟悉的东西并不意味着它就有效。有时，由于最初的学习曲线，分支和尝试新的东西可能并不高效。

然而，本文将采用两种最可能熟悉的技术，并将它们组合成一种简单、易记且强大的调试技术。前段时间，Aaron Patterson曾写过一篇关于Puts调试的文章，读起来很有感觉。根据我们的应用和错误的复杂性，这可能是不够的。

Tail

在几乎所有的*nix系统（Ubuntu、Centos、MacOS等）中，都有一个命令可以显示文件的最后比特。在应用程序目录下的终端，你可以运行这个命令来查看文件的最后100行。

tail -100 log/development.log

很酷吧？当你在一个单独的终端上运行你的应用程序时，你可以使用这个命令来查看它们发生的日志。

tail -f log/development.log

这对于查看可能发生的错误和其他问题真的很强大。任何类型的成功请求或失败都会被记录在这里，因为在我们的`config/environments/development.rb`中，我们默认设置了以下内容。

config.log_level = :debug

如果你没有这个设置，默认情况下，它将是:debug 。

Grep

Grep是另一个流行的命令，我一直在使用。当解析一个文件以找出特定的东西时，它使生活变得非常容易。为了简单起见，我可以在grep 一个文件的输出，它将只显示相关信息。

> cat Gemfile | grep source source 'rubygems.org'

因此，我们可以调用类似cat Gemfile ，这将在终端显示我们Gemfile的全部内容。将其与管道（|）和grep ，再加上我们的搜索词，就会返回相关的结果。真的很酷!

Tail+Grep

虽然一旦你熟悉了输出，并且知道你在寻找什么，阅读开发日志是相当直接的，但如果有大量的信息在一个请求中被返回，它仍然是很麻烦的。有时，它并不像阅读相关部分那么简单，因为中间有一堆分散注意力的信息。

因此，当我在调试一个问题时，无论是一个愚蠢的后台工作不能正常运行还是其他一些细微的差别，我都会在我的代码中抛出这样的东西来测试。

这给了日志一些分离的机会，也给了我一个很好的小包装来尝试和查看发生了什么。然而，在复杂的查询或请求中，这可能还是会被埋没在其他的日志中。相反，我们可以简单地在相关的代码位中做这样的事情。

Rails.logger.info "DEBUG::some_var::#{some_var}。

在我的终端中，我将用这样的命令来尾随日志和grepDEBUG 。

tail -f log/development.log | grep DEBUG

现在，我不仅没有被污染我终端的其他日志所困扰，而且我可以清楚地看到这段代码是什么时候运行的，也可以看到输出结果，而不需要试图从一堆日志中挑选。

调试愉快!