Check translation of 7 steps for hunting down Python code bugs.

translated/tech/20190208 7 steps for hunting down Python code bugs.md

@@ -16,7 +16,7 @@
 
 结果这些日志被转移到了你获取不到的地方，但他们正在导到一个网页应用中——所以你将可以用这个漂亮的应用来检索日志，但是，这个应用现在还没完成。这个应用预计会在几天内完成。我知道，这完全不符合实际情况，对吧？然而并不是，日志或者日志消息似乎经常在错误的时间出现缺失。在我们开始查错前，一个忠告：经常检查你的日志以确保他们在你认为它们应该在的地方并记录你认为它们应该记的东西。当你不检查的时候，这些东西往往会发生令人惊讶的变化。
 
-好的，你找到了日志或者尝试了呼叫运维人员，而客户确实发现了一个错误。甚至你可能认为你知道错误在哪儿。
+好的，你找到了日志或者尝试了呼叫运维人员，而客户确实发现了一个错误。甚至你可能认为你已经知道错误在哪儿。
 
 你立即打开你认为可能有问题的文件并开始查错。
 
@@ -48,23 +48,23 @@
 
 如果对错误看起来很迷惑，你下一步行动可能是用 Google 搜索它。如果你搜索的内容不包含你的代码的相关信息，如变量名、文件等，那你将获得更好的搜索结果。如果你使用的是 Python 3（你应该使用它），那么搜索内容包含 Python 3 是有帮助的，否则 Python 2 的解决方案往往会占据大多数。
 
-很久以前，开发者需要在没有搜索引擎的帮助下解决问题。这是一段黑暗的时光。充分利用你可以使用的所有工具。
+很久以前，开发者需要在没有搜索引擎的帮助下解决问题。那是一段黑暗的时光。充分利用你可以使用的所有工具。
 
 不幸的是，有时候问题发生得比较早但只有在调用栈底部执行的地方才变得明显。就像当蛋糕没有膨胀时，忘记加发酵粉的事才被发现。
 
-那就该检查整个调用栈。问题很可能在于你的代码而不算 Python 核心或者第三方包，所以先检查调用栈内你的代码。另外，在你的代码中放置断点通常会更容易检查代码。在调用栈的代码中放置断点然后看看周围是否如你预期。
+那就该检查整个调用栈。问题更可能在你的代码而不是 Python 标准库或者第三方包，所以先检查调用栈内你的代码。另外，在你的代码中放置断点通常会更容易检查代码。在调用栈的代码中放置断点然后看看周围是否如你预期。
 
 “但是，玛丽，”我听到你说，“如果我有一个调用栈，那这些都是有帮助的，但我只有一个失败的测试。我该从哪里开始？”
 
 Pdb, 一个 Python 调试器。
 
-找到你代码里会被这个调用命中的地方。你应该能至少找到一个这样的地方。在那里打上一个 pdb 的断点。
+找到你代码里会被这个调用命中的地方。你应该能够找到至少一个这样的地方。在那里打上一个 pdb 的断点。
 
 #### 一句题外话
 
-为什么不使用 print 语句呢？我曾经依赖于 print 语句。他们有时候仍然派得上用场。但当我开始处理复杂的代码库，尤其是有网络调用的代码库，print 语句就变得太慢了。我最终得到所有打印出来的数据，但我没法追踪他们的位置和原因，而且他们变得复杂了。但是主要使用 pdb 还有一个更重要的原因。假设你添加一条 print 语句去发现错误问题，而且 print 语句必须早于错误出现的地方。但是，看看你放 print 语句的函数，你不知道你是怎么调用它的。查看代码是寻找的好方法，但看你以前写的代码是恐怖的。是的，我会用 grep 处理我的代码库以寻找调用函数的地方，但这会变得乏味而且匹配一个通用函数时不能缩小范围。Pdb 就变得非常有用。
+为什么不使用 print 语句呢？我曾经依赖于 print 语句。有时候，他们仍然派得上用场。但当我开始处理复杂的代码库，尤其是有网络调用的代码库，print 语句就变得太慢了。我最终得到所有打印出来的数据，但我没法追踪他们的位置和原因，而且他们变得复杂了。但是主要使用 pdb 还有一个更重要的原因。假设你添加一条 print 语句去发现错误问题，而且 print 语句必须早于错误出现的地方。但是，看看你放 print 语句的函数，你不知道你的代码是怎么执行到那个位置的。查看代码是寻找调用路径的好方法，但看你以前写的代码是恐怖的。是的，我会用 grep 处理我的代码库以寻找调用函数的地方，但这会变得乏味，而且搜索一个通用函数时并不能缩小搜索范围。Pdb 就变得非常有用。
 
-你遵循我的建议，打上 pdb 断点并运行你的测试。然后测试再次失败，但是没有任何一个断点被打到。保留你的断点，并运行测试套件中一个同这个失败的测试非常相似的测试。如果你有个不错的测试，你应该能够找到一个测试。它会击中了你认为你的失败测试应该击中的代码。运行这个测试，然后当它打到你的断点，按下 `w` 并检查调用栈。如果你不知道如何查看因为其他调用而变得混乱的调用栈，那么在调用栈的中间找到属于你的代码，并在其中堆栈中代码的上一行放置一个断点。再试一次新的测试。如果仍然没打到断点，那么继续，向上追踪调用栈并找出你的调用在哪里脱轨了。如果你一直没有打到断点，最后到了追踪的顶部，那么恭喜你，你发现了问题：你的应用程序拼写错了。没有经验，没有经验，一点都没有经验。
+你遵循我的建议，打上 pdb 断点并运行你的测试。然而测试再次失败，但是没有任何一个断点被打到。保留你的断点，并运行测试套件中一个同这个失败的测试非常相似的测试。如果你有个不错的测试，你应该能够找到一个测试。它会击中了你认为你的失败测试应该击中的代码。运行这个测试，然后当它打到你的断点，按下 `w` 并检查调用栈。如果你不知道如何查看因为其他调用而变得混乱的调用栈，那么在调用栈的中间找到属于你的代码，并在其中堆栈中代码的上一行放置一个断点。再试一次新的测试。如果仍然没打到断点，那么继续，向上追踪调用栈并找出你的调用在哪里脱轨了。如果你一直没有打到断点，最后到了追踪的顶部，那么恭喜你，你发现了问题：你的应用程序拼写错了。没有经验，没有经验，一点都没有经验。
 
 ### 4. 修改代码
 
@@ -87,7 +87,7 @@ Pdb, 一个 Python 调试器。
 
 ### 7. 寻求帮助
 
-我经常发现写下所以信息会引发我对还没尝试过的东西的思考。当然，有时候我在点击提交按钮后立刻意识到问题是是什么。无论如何，当你在写下所有东西仍一无所获，那就试着向他人发邮件。首先是你的同事或者其他参与你的项目的人，然后是项目的邮件列表。不要害怕向人求助。大多数人都是友善和乐于助人的，我发现在 Python 社区里尤其如此。
+我经常发现写下所有信息能够启迪我想到还没尝试过的东西。当然，有时候我在点击提交按钮后立刻意识到问题是是什么。无论如何，当你在写下所有东西仍一无所获，那就试试向他人发邮件求助。首先是你的同事或者其他参与你的项目的人，然后是项目的邮件列表。不要害怕向人求助。大多数人都是友善和乐于助人的，我发现在 Python 社区里尤其如此。
 
 Maria McKinley 将在 [PyCascades 2019][4] 发表[代码查错][3]，二月 23-24，于西雅图。