mirror of
https://github.com/LCTT/TranslateProject.git
synced 2025-01-25 23:11:02 +08:00
Merge pull request #12678 from LazyWolfLin/7-steps-for-hunting-down-Python-code-bugs
Translated 7 steps for hunting down python code bugs.
This commit is contained in:
Xingyu.Wang
GitHub
commit
1f27ac59fd
@ -1,114 +0,0 @@
|
||||
[#]: collector: (lujun9972)
|
||||
[#]: translator: (LazyWolfLin)
|
||||
[#]: reviewer: ( )
|
||||
[#]: publisher: ( )
|
||||
[#]: url: ( )
|
||||
[#]: subject: (7 steps for hunting down Python code bugs)
|
||||
[#]: via: (https://opensource.com/article/19/2/steps-hunting-code-python-bugs)
|
||||
[#]: author: (Maria Mckinley https://opensource.com/users/parody)
|
||||
|
||||
7 steps for hunting down Python code bugs
|
||||
======
|
||||
Learn some tricks to minimize the time you spend tracking down the reasons your code fails.
|
||||
|
||||
|
||||
It is 3 pm on a Friday afternoon. Why? Because it is always 3 pm on a Friday when things go down. You get a notification that a customer has found a bug in your software. After you get over your initial disbelief, you contact DevOps to find out what is happening with the logs for your app, because you remember receiving a notification that they were being moved.
|
||||
|
||||
Turns out they are somewhere you can't get to, but they are in the process of being moved to a web application—so you will have this nifty application for searching and reading them, but of course, it is not finished yet. It should be up in a couple of days. I know, totally unrealistic situation, right? Unfortunately not; it seems logs or log messages often come up missing at just the wrong time. Before we track down the bug, a public service announcement: Check your logs to make sure they are where you think they are and logging what you think they should log, regularly. Amazing how these things just change when you aren't looking.
|
||||
|
||||
OK, so you found the logs or tried the call, and indeed, the customer has found a bug. Maybe you even think you know where the bug is.
|
||||
|
||||
You immediately open the file you think might be the problem and start poking around.
|
||||
|
||||
### 1. Don't touch your code yet
|
||||
|
||||
Go ahead and look at it, maybe even come up with a hypothesis. But before you start mucking about in the code, take that call that creates the bug and turn it into a test. This will be an integration test because although you may have suspicions, you do not yet know exactly where the problem is.
|
||||
|
||||
Make sure this test fails. This is important because sometimes the test you make doesn't mimic the broken call; this is especially true if you are using a web or other framework that can obfuscate the tests. Many things may be stored in variables, and it is unfortunately not always obvious, just by looking at the test, what call you are making in the test. I'm not going to say that I have created a test that passed when I was trying to imitate a broken call, but, well, I have, and I don't think that is particularly unusual. Learn from my mistakes.
|
||||
|
||||
### 2. Write a failing test
|
||||
|
||||
Now that you have a failing test or maybe a test with an error, it is time to troubleshoot. But before you do that, let's do a review of the stack, as this makes troubleshooting easier.
|
||||
|
||||
The stack consists of all of the tasks you have started but not finished. So, if you are baking a cake and adding the flour to the batter, then your stack would be:
|
||||
|
||||
* Make cake
|
||||
* Make batter
|
||||
* Add flour
|
||||
|
||||
|
||||
|
||||
You have started making your cake, you have started making the batter, and you are adding the flour. Greasing the pan is not on the list since you already finished that, and making the frosting is not on the list because you have not started that.
|
||||
|
||||
If you are fuzzy on the stack, I highly recommend playing around on [Python Tutor][1], where you can watch the stack as you execute lines of code.
|
||||
|
||||
Now, if something goes wrong with your Python program, the interpreter helpfully prints out the stack for you. This means that whatever the program was doing at the moment it became apparent that something went wrong is on the bottom.
|
||||
|
||||
### 3. Always check the bottom of the stack first
|
||||
|
||||
Not only is the bottom of the stack where you can see which error occurred, but often the last line of the stack is where you can find the issue. If the bottom doesn't help, and your code has not been linted in a while, it is amazing how helpful it can be to run. I recommend pylint or flake8. More often than not, it points right to where there is an error that I have been overlooking.
|
||||
|
||||
If the error is something that seems obscure, your next move might just be to Google it. You will have better luck if you don't include information that is relevant only to your code, like the name of variables, files, etc. If you are using Python 3 (which you should be), it's helpful to include the 3 in the search; otherwise, Python 2 solutions tend to dominate the top.
|
||||
|
||||
Once upon a time, developers had to troubleshoot without the benefit of a search engine. This was a dark time. Take advantage of all the tools available to you.
|
||||
|
||||
Unfortunately, sometimes the problem occurred earlier and only became apparent during the line executed on the bottom of the stack. Think about how forgetting to add the baking powder becomes obvious when the cake doesn't rise.
|
||||
|
||||
It is time to look up the stack. Chances are quite good that the problem is in your code, and not Python core or even third-party packages, so scan the stack looking for lines in your code first. Plus it is usually much easier to put a breakpoint in your own code. Stick the breakpoint in your code a little further up the stack and look around to see if things look like they should.
|
||||
|
||||
"But Maria," I hear you say, "this is all helpful if I have a stack trace, but I just have a failing test. Where do I start?"
|
||||
|
||||
Pdb, the Python Debugger.
|
||||
|
||||
Find a place in your code where you know this call should hit. You should be able to find at least one place. Stick a pdb break in there.
|
||||
|
||||
#### A digression
|
||||
|
||||
Why not a print statement? I used to depend on print statements. They still come in handy sometimes. But once I started working with complicated code bases, and especially ones making network calls, print just became too slow. I ended up with print statements all over the place, I lost track of where they were and why, and it just got complicated. But there is a more important reason to mostly use pdb. Let's say you put a print statement in and discover that something is wrong—and must have gone wrong earlier. But looking at the function where you put the print statement, you have no idea how you got there. Looking at code is a great way to see where you are going, but it is terrible for learning where you've been. And yes, I have done a grep of my code base looking for where a function is called, but this can get tedious and doesn't narrow it down much with a popular function. Pdb can be very helpful.
|
||||
|
||||
You follow my advice, and put in a pdb break and run your test. And it whooshes on by and fails again, with no break at all. Leave your breakpoint in, and run a test already in your test suite that does something very similar to the broken test. If you have a decent test suite, you should be able to find a test that is hitting the same code you think your failed test should hit. Run that test, and when it gets to your breakpoint, do a `w` and look at the stack. If you have no idea by looking at the stack how/where the other call may have gone haywire, then go about halfway up the stack, find some code that belongs to you, and put a breakpoint in that file, one line above the one in the stack trace. Try again with the new test. Keep going back and forth, moving up the stack to figure out where your call went off the rails. If you get all the way up to the top of the trace without hitting a breakpoint, then congratulations, you have found the issue: Your app was spelled wrong. No experience here, nope, none at all.
|
||||
|
||||
### 4. Change things
|
||||
|
||||
If you still feel lost, try making a new test where you vary something slightly. Can you get the new test to work? What is different? What is the same? Try changing something else. Once you have your test, and maybe additional tests in place, it is safe to start changing things in the code to see if you can narrow down the problem. Remember to start troubleshooting with a fresh commit so you can easily back out changes that do not help. (This is a reference to version control, if you aren't using version control, it will change your life. Well, maybe it will just make coding easier. See "[A Visual Guide to Version Control][2]" for a nice introduction.)
|
||||
|
||||
### 5. Take a break
|
||||
|
||||
In all seriousness, when it stops feeling like a fun challenge or game and starts becoming really frustrating, your best course of action is to walk away from the problem. Take a break. I highly recommend going for a walk and trying to think about something else.
|
||||
|
||||
### 6. Write everything down
|
||||
|
||||
When you come back, if you aren't suddenly inspired to try something, write down any information you have about the problem. This should include:
|
||||
|
||||
* Exactly the call that is causing the problem
|
||||
* Exactly what happened, including any error messages or related log messages
|
||||
* Exactly what you were expecting to happen
|
||||
* What you have done so far to find the problem and any clues that you have discovered while troubleshooting
|
||||
|
||||
|
||||
|
||||
Sometimes this is a lot of information, but trust me, it is really annoying trying to pry information out of someone piecemeal. Try to be concise, but complete.
|
||||
|
||||
### 7. Ask for help
|
||||
|
||||
I often find that just writing down all the information triggers a thought about something I have not tried yet. Sometimes, of course, I realize what the problem is immediately after hitting the submit button. At any rate, if you still have not thought of anything after writing everything down, try sending an email to someone. First, try colleagues or other people involved in your project, then move on to project email lists. Don't be afraid to ask for help. Most people are kind and helpful, and I have found that to be especially true in the Python community.
|
||||
|
||||
Maria McKinley will present [Hunting the Bugs][3] at [PyCascades 2019][4], February 23-24 in Seattle.
|
||||
|
||||
--------------------------------------------------------------------------------
|
||||
|
||||
via: https://opensource.com/article/19/2/steps-hunting-code-python-bugs
|
||||
|
||||
作者：[Maria Mckinley][a]
|
||||
选题：[lujun9972][b]
|
||||
译者：[译者ID](https://github.com/译者ID)
|
||||
校对：[校对者ID](https://github.com/校对者ID)
|
||||
|
||||
本文由 [LCTT](https://github.com/LCTT/TranslateProject) 原创编译，[Linux中国](https://linux.cn/) 荣誉推出
|
||||
|
||||
[a]: https://opensource.com/users/parody
|
||||
[b]: https://github.com/lujun9972
|
||||
[1]: http://www.pythontutor.com/
|
||||
[2]: https://betterexplained.com/articles/a-visual-guide-to-version-control/
|
||||
[3]: https://2019.pycascades.com/talks/hunting-the-bugs
|
||||
[4]: https://2019.pycascades.com/
|
||||
@ -0,0 +1,110 @@
|
||||
[#]: collector: (lujun9972)
|
||||
[#]: translator: (LazyWolfLin)
|
||||
[#]: reviewer: ( )
|
||||
[#]: publisher: ( )
|
||||
[#]: url: ( )
|
||||
[#]: subject: (7 steps for hunting down Python code bugs)
|
||||
[#]: via: (https://opensource.com/article/19/2/steps-hunting-code-python-bugs)
|
||||
[#]: author: (Maria Mckinley https://opensource.com/users/parody)
|
||||
|
||||
7 步检查 Python 代码错误
|
||||
======
|
||||
了解一些技巧助你减少代码查错时间。
|
||||
|
||||
|
||||
在周五的下午三点钟。为什么是这个时间？因为事情总会在周五下午三点钟发生。你收到一条通知，客户发现你的软件出现一个错误。在有了初步的怀疑后，你联系运维，查看你的软件日志以了解发生了什么，因为你记得收到过日志已经移动了的通知。
|
||||
|
||||
结果这些日志被转移到了你获取不到的地方，但他们正在导到一个网页应用中——所以你将可以用这个漂亮的应用来检索日志，但是，这个应用现在还没完成。这个应用预计会在几天内完成。我知道，这完全不符合实际情况，对吧？然而并不是，日志或者日志消息似乎经常在错误的时间出现缺失。在我们开始查错前，一个忠告：经常检查你的日志以确保他们在你认为它们应该在的地方并记录你认为它们应该记的东西。当你不检查的时候，这些东西往往会发生令人惊讶的变化。
|
||||
|
||||
好的，你找到了日志或者尝试了呼叫运维人员，而客户确实发现了一个错误。甚至你可能认为你已经知道错误在哪儿。
|
||||
|
||||
你立即打开你认为可能有问题的文件并开始查错。
|
||||
|
||||
### 1. 不要碰你的代码
|
||||
|
||||
阅读代码，你甚至可能会想到一个假设。但是在开始修改你的代码前，请重现导致错误的调用并把它变成一个测试。这将是一个集成测试，因为你可能还有其他疑问，目前你还没能准确地知道问题在哪儿。
|
||||
|
||||
确保这个测试是失败的。这很重要，因为有时你的测试不能重现失败的调用，尤其是你使用了可以混淆测试的 web 或者其他框架。很多东西可能被存储在变量中，但遗憾的是，只通过观察测试，你在测试里调用的东西并不总是明显可见的。当我尝试着重现这个失败的调用时，我不准备说我创建了一个新测试，但是，对的，我确实已经创建了新的一个测试，但我不认为这是特别不寻常的。从自己的错误中吸取教训。
|
||||
|
||||
### 2. 编写错误的测试
|
||||
|
||||
现在，你有了一个失败的测试或者可能是一个带有错误的测试，那么是时候解决问题了。但是在你开干之前，让我们先检查下调用栈，因为这样可以更轻松地解决问题。
|
||||
|
||||
调用栈包括你已经启动但尚未完成地所有任务。因此，比如你正在烤蛋糕并准备往面糊里加面粉，那你的调用栈将是：
|
||||
|
||||
* 做蛋糕
|
||||
* 打面糊
|
||||
* 加面粉
|
||||
|
||||
你已经开始做蛋糕，开始打面糊，而你现在正在加面粉。往锅底抹油不在这个列表中因为你已经完成了，而做糖霜不在这个列表上因为你还没开始做。
|
||||
|
||||
如果你对调用栈不清楚，我强烈建议你使用 [Python Tutor][1]，它能帮你在执行代码时观察调用栈。
|
||||
|
||||
现在，如果你的 Python 程序出现了错误，接收器会帮你打印出当前调用栈。这意味着无论那一时刻程序在做什么，很明显错误发生在调用栈的底部。
|
||||
|
||||
### 3. 始终先检查 stack 的底部
|
||||
|
||||
你不仅能在栈底看到发生了哪个错误，而且通常可以在调用栈的最后一行发现问题。如果栈底对你没有帮助，而你的代码还没有经过代码分析，那么使用代码分析非常有用。我推荐 pylint 或者 flake8。通常情况下，它会指出我一直忽略的错误的地方。
|
||||
|
||||
如果对错误看起来很迷惑，你下一步行动可能是用 Google 搜索它。如果你搜索的内容不包含你的代码的相关信息，如变量名、文件等，那你将获得更好的搜索结果。如果你使用的是 Python 3（你应该使用它），那么搜索内容包含 Python 3 是有帮助的，否则 Python 2 的解决方案往往会占据大多数。
|
||||
|
||||
很久以前，开发者需要在没有搜索引擎的帮助下解决问题。那是一段黑暗的时光。充分利用你可以使用的所有工具。
|
||||
|
||||
不幸的是，有时候问题发生得比较早但只有在调用栈底部执行的地方才变得明显。就像当蛋糕没有膨胀时，忘记加发酵粉的事才被发现。
|
||||
|
||||
那就该检查整个调用栈。问题更可能在你的代码而不是 Python 标准库或者第三方包，所以先检查调用栈内你的代码。另外，在你的代码中放置断点通常会更容易检查代码。在调用栈的代码中放置断点然后看看周围是否如你预期。
|
||||
|
||||
“但是，玛丽，”我听到你说，“如果我有一个调用栈，那这些都是有帮助的，但我只有一个失败的测试。我该从哪里开始？”
|
||||
|
||||
Pdb, 一个 Python 调试器。
|
||||
|
||||
找到你代码里会被这个调用命中的地方。你应该能够找到至少一个这样的地方。在那里打上一个 pdb 的断点。
|
||||
|
||||
#### 一句题外话
|
||||
|
||||
为什么不使用 print 语句呢？我曾经依赖于 print 语句。有时候，他们仍然派得上用场。但当我开始处理复杂的代码库，尤其是有网络调用的代码库，print 语句就变得太慢了。我最终得到所有打印出来的数据，但我没法追踪他们的位置和原因，而且他们变得复杂了。但是主要使用 pdb 还有一个更重要的原因。假设你添加一条 print 语句去发现错误问题，而且 print 语句必须早于错误出现的地方。但是，看看你放 print 语句的函数，你不知道你的代码是怎么执行到那个位置的。查看代码是寻找调用路径的好方法，但看你以前写的代码是恐怖的。是的，我会用 grep 处理我的代码库以寻找调用函数的地方，但这会变得乏味，而且搜索一个通用函数时并不能缩小搜索范围。Pdb 就变得非常有用。
|
||||
|
||||
你遵循我的建议，打上 pdb 断点并运行你的测试。然而测试再次失败，但是没有任何一个断点被打到。保留你的断点，并运行测试套件中一个同这个失败的测试非常相似的测试。如果你有个不错的测试，你应该能够找到一个测试。它会击中了你认为你的失败测试应该击中的代码。运行这个测试，然后当它打到你的断点，按下 `w` 并检查调用栈。如果你不知道如何查看因为其他调用而变得混乱的调用栈，那么在调用栈的中间找到属于你的代码，并在其中堆栈中代码的上一行放置一个断点。再试一次新的测试。如果仍然没打到断点，那么继续，向上追踪调用栈并找出你的调用在哪里脱轨了。如果你一直没有打到断点，最后到了追踪的顶部，那么恭喜你，你发现了问题：你的应用程序拼写错了。没有经验，没有经验，一点都没有经验。
|
||||
|
||||
### 4. 修改代码
|
||||
|
||||
如果你仍觉得迷惑，在你稍微改变了一些的地方尝试新的测试。你能让新的测试跑起来么？有什么不同的呢？有什么相同的呢？尝试改变别的东西。当你有了你的测试，可能也还有其他测试，那就可以开始安全地修改代码，确定是否可以缩小问题范围。记得从一个新提交开始解决问题，以便于可以轻松地撤销无效地更改。（这就是版本控制，如果你没有使用版本控制，这将会改变你的生活。好吧，可能它只是让编码更容易。查阅“版本控制可视指南”，以了解更多。）
|
||||
|
||||
### 5. 休息一下
|
||||
|
||||
尽管如此，当它不再感觉起来像一个有趣的挑战或者游戏而开始变得令人沮丧时，你最好的举措是脱离这个问题。休息一下。我强烈建议你去散步并尝试考虑别的事情。
|
||||
|
||||
### 6. 把一切写下来
|
||||
|
||||
当你回来了，如果你没有突然受到启发，那就把你关于这个问题所知的每一个点信息写下来。这应该包括：
|
||||
|
||||
* 真正造成问题的调用
|
||||
* 真正发生了什么，包括任何错误信息或者相关的日志信息
|
||||
* 你真正期望发生什么
|
||||
* 到目前为止，为了找出问题，你做了什么工作；以及解决问题中你发现的任何线索。
|
||||
|
||||
有时这里有很多信息，但相信我，从零碎中挖掘信息是很烦人。所以尽量简洁，但是要完整。
|
||||
|
||||
### 7. 寻求帮助
|
||||
|
||||
我经常发现写下所有信息能够启迪我想到还没尝试过的东西。当然，有时候我在点击提交按钮后立刻意识到问题是是什么。无论如何，当你在写下所有东西仍一无所获，那就试试向他人发邮件求助。首先是你的同事或者其他参与你的项目的人，然后是项目的邮件列表。不要害怕向人求助。大多数人都是友善和乐于助人的，我发现在 Python 社区里尤其如此。
|
||||
|
||||
Maria McKinley 将在 [PyCascades 2019][4] 发表[代码查错][3]，二月 23-24，于西雅图。
|
||||
|
||||
--------------------------------------------------------------------------------
|
||||
|
||||
via: https://opensource.com/article/19/2/steps-hunting-code-python-bugs
|
||||
|
||||
作者：[Maria Mckinley][a]
|
||||
选题：[lujun9972][b]
|
||||
译者：[LazyWolfLin](https://github.com/LazyWolfLin)
|
||||
校对：[校对者ID](https://github.com/校对者ID)
|
||||
|
||||
本文由 [LCTT](https://github.com/LCTT/TranslateProject) 原创编译，[Linux中国](https://linux.cn/) 荣誉推出
|
||||
|
||||
[a]: https://opensource.com/users/parody
|
||||
[b]: https://github.com/lujun9972
|
||||
[1]: http://www.pythontutor.com/
|
||||
[2]: https://betterexplained.com/articles/a-visual-guide-to-version-control/
|
||||
[3]: https://2019.pycascades.com/talks/hunting-the-bugs
|
||||
[4]: https://2019.pycascades.com/
|
||||
Loading…
Reference in New Issue
Block a user