From eb38a8eb1194c4977def428962457b940df5aa81 Mon Sep 17 00:00:00 2001 From: LazyWolf Lin Date: Fri, 15 Feb 2019 13:31:57 +0800 Subject: [PATCH 01/14] Translating 7 steps for hunting down Python code bugs. --- ...steps for hunting down Python code bugs.md | 114 ++++++++++++++++++ 1 file changed, 114 insertions(+) create mode 100644 translated/tech/20190208 7 steps for hunting down Python code bugs.md diff --git a/translated/tech/20190208 7 steps for hunting down Python code bugs.md b/translated/tech/20190208 7 steps for hunting down Python code bugs.md new file mode 100644 index 0000000000..3441e6d9e6 --- /dev/null +++ b/translated/tech/20190208 7 steps for hunting down Python code bugs.md @@ -0,0 +1,114 @@ +[#]: 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 代码错误 +====== +了解一些技巧来减少你花费在寻找代码失败原因的时间。 +![](https://opensource.com/sites/default/files/styles/image-full-size/public/lead-images/bug-insect-butterfly-diversity-inclusion-2.png?itok=TcC9eews) + +在周五的下午三点钟。为什么是这个时间？因为事情总会在周五下午三点钟发生。你收到一条通知，客户发现你的软件出现一个错误。在有了初步的怀疑后，你联系运维，查看你的软件日志以了解发生了什么，因为你记得收到过日志已经转移了的通知。 + +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/ From b8c5596bdeed5537376f746040999f35c9669648 Mon Sep 17 00:00:00 2001 From: LazyWolf Lin Date: Mon, 18 Feb 2019 13:34:59 +0800 Subject: [PATCH 02/14] Translating 7 steps for hunting down Python code bugs. --- .../20190208 7 steps for hunting down Python code bugs.md | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/translated/tech/20190208 7 steps for hunting down Python code bugs.md b/translated/tech/20190208 7 steps for hunting down Python code bugs.md index 3441e6d9e6..2c83e02fe1 100644 --- a/translated/tech/20190208 7 steps for hunting down Python code bugs.md +++ b/translated/tech/20190208 7 steps for hunting down Python code bugs.md @@ -12,9 +12,9 @@ 了解一些技巧来减少你花费在寻找代码失败原因的时间。 ![](https://opensource.com/sites/default/files/styles/image-full-size/public/lead-images/bug-insect-butterfly-diversity-inclusion-2.png?itok=TcC9eews) -在周五的下午三点钟。为什么是这个时间？因为事情总会在周五下午三点钟发生。你收到一条通知，客户发现你的软件出现一个错误。在有了初步的怀疑后，你联系运维，查看你的软件日志以了解发生了什么，因为你记得收到过日志已经转移了的通知。 +在周五的下午三点钟。为什么是这个时间？因为事情总会在周五下午三点钟发生。你收到一条通知，客户发现你的软件出现一个错误。在有了初步的怀疑后，你联系运维，查看你的软件日志以了解发生了什么，因为你记得收到过日志已经移动了的通知。 -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. +结果这些日志被转移到你获取不到的地方，但他们正在转移到一个网页应用中——所以你将可以用这个漂亮的应用来检索日志，但是，这个应用现在还没完成。它应该会在几天内完成。我知道，这完全不符合实际情况，对吧？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. From d78eb42a616629ac4bf7ff9991e3f7cefbafabd6 Mon Sep 17 00:00:00 2001 From: LazyWolf Lin Date: Wed, 20 Feb 2019 13:30:59 +0800 Subject: [PATCH 03/14] Translating 7 steps for hunting down Python code bugs. --- ...0208 7 steps for hunting down Python code bugs.md | 12 ++++++------ 1 file changed, 6 insertions(+), 6 deletions(-) diff --git a/translated/tech/20190208 7 steps for hunting down Python code bugs.md b/translated/tech/20190208 7 steps for hunting down Python code bugs.md index 2c83e02fe1..4781e06f9b 100644 --- a/translated/tech/20190208 7 steps for hunting down Python code bugs.md +++ b/translated/tech/20190208 7 steps for hunting down Python code bugs.md @@ -14,19 +14,19 @@ 在周五的下午三点钟。为什么是这个时间？因为事情总会在周五下午三点钟发生。你收到一条通知，客户发现你的软件出现一个错误。在有了初步的怀疑后，你联系运维，查看你的软件日志以了解发生了什么，因为你记得收到过日志已经移动了的通知。 -结果这些日志被转移到你获取不到的地方，但他们正在转移到一个网页应用中——所以你将可以用这个漂亮的应用来检索日志，但是，这个应用现在还没完成。它应该会在几天内完成。我知道，这完全不符合实际情况，对吧？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 +### 1. 不要碰你的代码 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 +### 2. 编写错误的测试 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. @@ -44,7 +44,7 @@ If you are fuzzy on the stack, I highly recommend playing around on [Python Tuto 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 +### 3. 始终先检查 stack 的底部 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. From 4ca61bf760d6b7fe3a89bdf4c0f2451fc1b5f5dd Mon Sep 17 00:00:00 2001 From: LazyWolf Lin Date: Thu, 21 Feb 2019 13:31:19 +0800 Subject: [PATCH 04/14] Translating 7 steps for hunting down Python code bugs. --- .../tech/20190208 7 steps for hunting down Python code bugs.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/translated/tech/20190208 7 steps for hunting down Python code bugs.md b/translated/tech/20190208 7 steps for hunting down Python code bugs.md index 4781e06f9b..16620f78ad 100644 --- a/translated/tech/20190208 7 steps for hunting down Python code bugs.md +++ b/translated/tech/20190208 7 steps for hunting down Python code bugs.md @@ -22,7 +22,7 @@ ### 1. 不要碰你的代码 -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. From 0c5b88454df00ca55cb40f645c31fef8aa168744 Mon Sep 17 00:00:00 2001 From: LazyWolf Lin Date: Fri, 22 Feb 2019 13:32:14 +0800 Subject: [PATCH 05/14] Translating 7 steps for hunting down Python code bugs. --- .../tech/20190208 7 steps for hunting down Python code bugs.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/translated/tech/20190208 7 steps for hunting down Python code bugs.md b/translated/tech/20190208 7 steps for hunting down Python code bugs.md index 16620f78ad..45423c44da 100644 --- a/translated/tech/20190208 7 steps for hunting down Python code bugs.md +++ b/translated/tech/20190208 7 steps for hunting down Python code bugs.md @@ -24,7 +24,7 @@ 阅读代码，你甚至可能会想出一个假设。但是在开始修改你的代码前，请重现导致错误的调用并把它变成一个测试。这将是一个集成测试，因为你可能还有疑问，目前你还没能准确地知道问题在哪儿。 -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. +确保这个测试是失败的。这很重要，因为有时你的测试不能重现失败的调用，尤其是你使用了可以混淆测试的 web 或者其他框架。很多东西可能被存储在变量中，但遗憾的是，只通过观察测试，你在测试里调用的东西并不总是明显可见的。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. 编写错误的测试 From d898eadcff49e308d29ef440ce1b66482a7bc335 Mon Sep 17 00:00:00 2001 From: LazyWolf Lin Date: Sun, 24 Feb 2019 14:02:00 +0800 Subject: [PATCH 06/14] Translating 7 steps for hunting down Python code bugs. --- ...8 7 steps for hunting down Python code bugs.md | 15 ++++++--------- 1 file changed, 6 insertions(+), 9 deletions(-) diff --git a/translated/tech/20190208 7 steps for hunting down Python code bugs.md b/translated/tech/20190208 7 steps for hunting down Python code bugs.md index 45423c44da..276a32c3c0 100644 --- a/translated/tech/20190208 7 steps for hunting down Python code bugs.md +++ b/translated/tech/20190208 7 steps for hunting down Python code bugs.md @@ -24,19 +24,16 @@ 阅读代码，你甚至可能会想出一个假设。但是在开始修改你的代码前，请重现导致错误的调用并把它变成一个测试。这将是一个集成测试，因为你可能还有疑问，目前你还没能准确地知道问题在哪儿。 -确保这个测试是失败的。这很重要，因为有时你的测试不能重现失败的调用，尤其是你使用了可以混淆测试的 web 或者其他框架。很多东西可能被存储在变量中，但遗憾的是，只通过观察测试，你在测试里调用的东西并不总是明显可见的。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. +确保这个测试是失败的。这很重要，因为有时你的测试不能重现失败的调用，尤其是你使用了可以混淆测试的 web 或者其他框架。很多东西可能被存储在变量中，但遗憾的是，只通过观察测试，你在测试里调用的东西并不总是明显可见的。当我尝试着重现这个失败的调用时，我不准备说我创建了一个测试，但是，对的，我已经创建了，但我不认为这是特别不寻常的。从自己的错误中吸取教训。 ### 2. 编写错误的测试 -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. From ec8fb1fc90effa57732a630b826dfde1797e2e59 Mon Sep 17 00:00:00 2001 From: LazyWolf Lin Date: Wed, 27 Feb 2019 13:31:01 +0800 Subject: [PATCH 07/14] Translating 7 steps for hunting down Python code bugs. --- ... 7 steps for hunting down Python code bugs.md | 16 ++++++++-------- 1 file changed, 8 insertions(+), 8 deletions(-) diff --git a/translated/tech/20190208 7 steps for hunting down Python code bugs.md b/translated/tech/20190208 7 steps for hunting down Python code bugs.md index 276a32c3c0..ae9840b05f 100644 --- a/translated/tech/20190208 7 steps for hunting down Python code bugs.md +++ b/translated/tech/20190208 7 steps for hunting down Python code bugs.md @@ -35,23 +35,23 @@ * 打面糊 * 加面粉 -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. +如果你对调用栈不清楚，我强烈建议你使用 [Python Tutor][1]，它能帮你在执行代码时观察调用栈。 -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. +现在，如果你的 Python 程序出现了错误，接收器会帮你打印出当前调用栈。这意味着无论那一时刻程序在做什么，很明显调用栈的底部发生了错误。 ### 3. 始终先检查 stack 的底部 -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. +你不仅能在栈底看到发生了哪个错误，而且通常可以在调用栈的最后一行发现问题。如果栈底对你没有帮助，而你的代码还没有经过代码分析，那么使用代码分析非常有用。我推荐 pylint 或者 flake8。通常情况下，它会指出我一直忽略的错误的地方。 -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. +如果对错误看起来很迷惑，你下一步行动可能是用 Google 搜索它。如果你搜索的内容不包含你的代码的相关信息，如变量名、文件等，那你将获得更好的搜索结果。如果你使用的是 Python 3（你应该使用它），那么搜索内容包含 Python 3 是有帮助的，否则 Python 2 的解决方案往往会占据大多数。 -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. +那就该检查整个调用栈。问题很可能在于你的代码而不算 Python 核心或者第三方包，所以先检查调用栈内你的代码。另外，在你的代码中放置断点通常会更容易检查代码。在调用栈的代码中放置断点然后看看周围是否如你预期。 "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?" From 339456790e4d427f3d04fac090a5c7fb10a50e7b Mon Sep 17 00:00:00 2001 From: LazyWolf Lin Date: Thu, 28 Feb 2019 13:31:22 +0800 Subject: [PATCH 08/14] Translating 7 steps for hunting down Python code bugs. --- ...190208 7 steps for hunting down Python code bugs.md | 10 +++++----- 1 file changed, 5 insertions(+), 5 deletions(-) diff --git a/translated/tech/20190208 7 steps for hunting down Python code bugs.md b/translated/tech/20190208 7 steps for hunting down Python code bugs.md index ae9840b05f..5be6735dc7 100644 --- a/translated/tech/20190208 7 steps for hunting down Python code bugs.md +++ b/translated/tech/20190208 7 steps for hunting down Python code bugs.md @@ -53,15 +53,15 @@ 那就该检查整个调用栈。问题很可能在于你的代码而不算 Python 核心或者第三方包，所以先检查调用栈内你的代码。另外，在你的代码中放置断点通常会更容易检查代码。在调用栈的代码中放置断点然后看看周围是否如你预期。 -"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. +Pdb, 一个 Python 调试器。 -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. +找到你代码里会被这个调用命中的地方。你应该能至少找到一个这样的地方。在那里打上一个 pdb 的断点。 -#### 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. +为什么不使用 print 语句呢？我曾经依赖于 print 语句。他们有时候仍然派得上用场。但当我开始处理复杂的代码库，尤其是有网络调用的代码库，print 语句就变得太慢了。我最终得到所有打印出来的数据，但我没法追踪他们的位置和原因，而且他们变得复杂了。 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. From 6ddc8fcf8b0d84173ea14974103adc3c91114df8 Mon Sep 17 00:00:00 2001 From: LazyWolf Lin Date: Sun, 3 Mar 2019 14:21:31 +0800 Subject: [PATCH 09/14] Translating 7 steps for hunting down Python code bugs. --- .../20190208 7 steps for hunting down Python code bugs.md | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/translated/tech/20190208 7 steps for hunting down Python code bugs.md b/translated/tech/20190208 7 steps for hunting down Python code bugs.md index 5be6735dc7..b63da1ba8d 100644 --- a/translated/tech/20190208 7 steps for hunting down Python code bugs.md +++ b/translated/tech/20190208 7 steps for hunting down Python code bugs.md @@ -61,9 +61,9 @@ Pdb, 一个 Python 调试器。 #### 一句题外话 -为什么不使用 print 语句呢？我曾经依赖于 print 语句。他们有时候仍然派得上用场。但当我开始处理复杂的代码库，尤其是有网络调用的代码库，print 语句就变得太慢了。我最终得到所有打印出来的数据，但我没法追踪他们的位置和原因，而且他们变得复杂了。 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. +为什么不使用 print 语句呢？我曾经依赖于 print 语句。他们有时候仍然派得上用场。但当我开始处理复杂的代码库，尤其是有网络调用的代码库，print 语句就变得太慢了。我最终得到所有打印出来的数据，但我没法追踪他们的位置和原因，而且他们变得复杂了。但是主要使用 pdb 还有一个更重要的原因。假设你添加一条 print 语句去发现错误问题，而且 print 语句必须早于错误出现的地方。但是，看看你放 print 语句的函数，你不知道你是怎么调用它的。查看代码是寻找的好方法，但看你以前写的代码是恐怖的。是的，我会用 grep 处理我的代码库以寻找调用函数的地方，但这会变得乏味而且匹配一个通用函数时不能缩小范围。Pdb 就变得非常有用。 -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. +你遵循我的建议，打上 pdb 断点并运行你的测试。然后测试再次失败，但是没有任何一个断点被打到。保留你的断点，并运行测试套件中一个同这个失败的测试非常相似的测试。如果你有个不错的测试，你应该能够找到一个测试。它会击中了你认为你的失败测试应该击中的代码。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 From 84a862dac58480aef37e618be4d041cdbd1782ef Mon Sep 17 00:00:00 2001 From: LazyWolf Lin Date: Mon, 4 Mar 2019 13:31:13 +0800 Subject: [PATCH 10/14] Translating 7 steps for hunting down Python code bugs. --- .../20190208 7 steps for hunting down Python code bugs.md | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/translated/tech/20190208 7 steps for hunting down Python code bugs.md b/translated/tech/20190208 7 steps for hunting down Python code bugs.md index b63da1ba8d..9fe0e40a3d 100644 --- a/translated/tech/20190208 7 steps for hunting down Python code bugs.md +++ b/translated/tech/20190208 7 steps for hunting down Python code bugs.md @@ -63,11 +63,11 @@ Pdb, 一个 Python 调试器。 为什么不使用 print 语句呢？我曾经依赖于 print 语句。他们有时候仍然派得上用场。但当我开始处理复杂的代码库，尤其是有网络调用的代码库，print 语句就变得太慢了。我最终得到所有打印出来的数据，但我没法追踪他们的位置和原因，而且他们变得复杂了。但是主要使用 pdb 还有一个更重要的原因。假设你添加一条 print 语句去发现错误问题，而且 print 语句必须早于错误出现的地方。但是，看看你放 print 语句的函数，你不知道你是怎么调用它的。查看代码是寻找的好方法，但看你以前写的代码是恐怖的。是的，我会用 grep 处理我的代码库以寻找调用函数的地方，但这会变得乏味而且匹配一个通用函数时不能缩小范围。Pdb 就变得非常有用。 -你遵循我的建议，打上 pdb 断点并运行你的测试。然后测试再次失败，但是没有任何一个断点被打到。保留你的断点，并运行测试套件中一个同这个失败的测试非常相似的测试。如果你有个不错的测试，你应该能够找到一个测试。它会击中了你认为你的失败测试应该击中的代码。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. +你遵循我的建议，打上 pdb 断点并运行你的测试。然后测试再次失败，但是没有任何一个断点被打到。保留你的断点，并运行测试套件中一个同这个失败的测试非常相似的测试。如果你有个不错的测试，你应该能够找到一个测试。它会击中了你认为你的失败测试应该击中的代码。运行这个测试，然后当它打到你的断点，按下 `w` 并检查调用栈。如果你不知道如何查看因为其他调用而变得混乱的调用栈，那么在调用栈的中间找到属于你的代码，并在其中堆栈中代码的上一行放置一个断点。再试一次新的测试。如果仍然没打到断点，那么继续，向上追踪调用栈并找出你的调用在哪里脱轨了。如果你一直没有打到断点，最后到了追踪的顶部，那么恭喜你，你发现了问题：你的应用程序拼写错了。没有经验，没有经验，一点都没有经验。 ### 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.) +如果你仍觉得迷惑，在你稍微改变了一些的地方尝试新的测试。你能让新的测试跑起来么？有什么不同的呢？有什么相同的呢？尝试改变别的东西。 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 From e736dc9903d856deca1b4ff22143ecca62cdade3 Mon Sep 17 00:00:00 2001 From: LazyWolf Lin Date: Tue, 5 Mar 2019 13:31:27 +0800 Subject: [PATCH 11/14] Translating 7 steps for hunting down Python code bugs. --- ...steps for hunting down Python code bugs.md | 28 +++++++++---------- 1 file changed, 13 insertions(+), 15 deletions(-) diff --git a/translated/tech/20190208 7 steps for hunting down Python code bugs.md b/translated/tech/20190208 7 steps for hunting down Python code bugs.md index 9fe0e40a3d..ab4c13c862 100644 --- a/translated/tech/20190208 7 steps for hunting down Python code bugs.md +++ b/translated/tech/20190208 7 steps for hunting down Python code bugs.md @@ -65,32 +65,30 @@ Pdb, 一个 Python 调试器。 你遵循我的建议，打上 pdb 断点并运行你的测试。然后测试再次失败，但是没有任何一个断点被打到。保留你的断点，并运行测试套件中一个同这个失败的测试非常相似的测试。如果你有个不错的测试，你应该能够找到一个测试。它会击中了你认为你的失败测试应该击中的代码。运行这个测试，然后当它打到你的断点，按下 `w` 并检查调用栈。如果你不知道如何查看因为其他调用而变得混乱的调用栈，那么在调用栈的中间找到属于你的代码，并在其中堆栈中代码的上一行放置一个断点。再试一次新的测试。如果仍然没打到断点，那么继续，向上追踪调用栈并找出你的调用在哪里脱轨了。如果你一直没有打到断点，最后到了追踪的顶部，那么恭喜你，你发现了问题：你的应用程序拼写错了。没有经验，没有经验，一点都没有经验。 -### 4. Change things +### 4. 修改代码 -如果你仍觉得迷惑，在你稍微改变了一些的地方尝试新的测试。你能让新的测试跑起来么？有什么不同的呢？有什么相同的呢？尝试改变别的东西。 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 +### 5. 休息一下 -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 +### 6. 把一切写下来 -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 +### 7. 寻求帮助 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. +Maria McKinley 将在 [PyCascades 2019][4] 发表[代码查错][3]，二月 23-24，西雅图。 -------------------------------------------------------------------------------- From c20d2b40c0e64ea77b2d805a83b12d82af73614d Mon Sep 17 00:00:00 2001 From: LazyWolf Lin Date: Wed, 6 Mar 2019 13:30:03 +0800 Subject: [PATCH 12/14] Translating 7 steps for hunting down Python code bugs. --- ...steps for hunting down Python code bugs.md | 25 ++++++++++--------- 1 file changed, 13 insertions(+), 12 deletions(-) diff --git a/translated/tech/20190208 7 steps for hunting down Python code bugs.md b/translated/tech/20190208 7 steps for hunting down Python code bugs.md index ab4c13c862..04d302964c 100644 --- a/translated/tech/20190208 7 steps for hunting down Python code bugs.md +++ b/translated/tech/20190208 7 steps for hunting down Python code bugs.md @@ -9,37 +9,38 @@ 7 步检查 Python 代码错误 ====== -了解一些技巧来减少你花费在寻找代码失败原因的时间。 +了解一些技巧助你减少代码查错时间。 ![](https://opensource.com/sites/default/files/styles/image-full-size/public/lead-images/bug-insect-butterfly-diversity-inclusion-2.png?itok=TcC9eews) 在周五的下午三点钟。为什么是这个时间？因为事情总会在周五下午三点钟发生。你收到一条通知，客户发现你的软件出现一个错误。在有了初步的怀疑后，你联系运维，查看你的软件日志以了解发生了什么，因为你记得收到过日志已经移动了的通知。 -结果这些日志被转移到你获取不到的地方，但他们正在转移到一个网页应用中——所以你将可以用这个漂亮的应用来检索日志，但是，这个应用现在还没完成。它应该会在几天内完成。我知道，这完全不符合实际情况，对吧？然而不，日志或者日志消息似乎经常在错误的时间出现缺少。在我们追踪错误前，一个忠告：经常检查你的日志保证他们在你认为它们该在的地方并记录你认为它们该记的东西。当你不看的时候，这些东西会发生令人惊讶的变化。 +结果这些日志被转移到了你获取不到的地方，但他们正在导到一个网页应用中——所以你将可以用这个漂亮的应用来检索日志，但是，这个应用现在还没完成。这个应用预计会在几天内完成。我知道，这完全不符合实际情况，对吧？然而并不是，日志或者日志消息似乎经常在错误的时间出现缺失。在我们开始查错前，一个忠告：经常检查你的日志以确保他们在你认为它们应该在的地方并记录你认为它们应该记的东西。当你不检查的时候，这些东西往往会发生令人惊讶的变化。 -好的，所以你寻找了日志或者尝试了呼叫运维，而客户确实发现了一个错误。可能你甚至认为你知道错误在哪儿。 +好的，你找到了日志或者尝试了呼叫运维人员，而客户确实发现了一个错误。甚至你可能认为你知道错误在哪儿。 -你立即打开你认为可能有问题的文件并开始寻找。 +你立即打开你认为可能有问题的文件并开始查错。 ### 1. 不要碰你的代码 -阅读代码，你甚至可能会想出一个假设。但是在开始修改你的代码前，请重现导致错误的调用并把它变成一个测试。这将是一个集成测试，因为你可能还有疑问，目前你还没能准确地知道问题在哪儿。 +阅读代码，你甚至可能会想到一个假设。但是在开始修改你的代码前，请重现导致错误的调用并把它变成一个测试。这将是一个集成测试，因为你可能还有其他疑问，目前你还没能准确地知道问题在哪儿。 -确保这个测试是失败的。这很重要，因为有时你的测试不能重现失败的调用，尤其是你使用了可以混淆测试的 web 或者其他框架。很多东西可能被存储在变量中，但遗憾的是，只通过观察测试，你在测试里调用的东西并不总是明显可见的。当我尝试着重现这个失败的调用时，我不准备说我创建了一个测试，但是，对的，我已经创建了，但我不认为这是特别不寻常的。从自己的错误中吸取教训。 +确保这个测试是失败的。这很重要，因为有时你的测试不能重现失败的调用，尤其是你使用了可以混淆测试的 web 或者其他框架。很多东西可能被存储在变量中，但遗憾的是，只通过观察测试，你在测试里调用的东西并不总是明显可见的。当我尝试着重现这个失败的调用时，我不准备说我创建了一个新测试，但是，对的，我确实已经创建了新的一个测试，但我不认为这是特别不寻常的。从自己的错误中吸取教训。 ### 2. 编写错误的测试 现在，你有了一个失败的测试或者可能是一个带有错误的测试，那么是时候解决问题了。但是在你开干之前，让我们先检查下调用栈，因为这样可以更轻松地解决问题。 -调用栈包括你已经启动但尚未完成地所有任务。所以，比如你正在烤蛋糕并准备往面糊里加面粉，那你的调用栈将是： +调用栈包括你已经启动但尚未完成地所有任务。因此，比如你正在烤蛋糕并准备往面糊里加面粉，那你的调用栈将是： + * 做蛋糕 * 打面糊 * 加面粉 -你已经开始做蛋糕，你已经开始打面糊，而你现在正在加面粉。锅底抹油不在这个列表中因为你已经做完了，而做糖霜不在这个列表上因为你还没开始做。 +你已经开始做蛋糕，开始打面糊，而你现在正在加面粉。往锅底抹油不在这个列表中因为你已经完成了，而做糖霜不在这个列表上因为你还没开始做。 如果你对调用栈不清楚，我强烈建议你使用 [Python Tutor][1]，它能帮你在执行代码时观察调用栈。 -现在，如果你的 Python 程序出现了错误，接收器会帮你打印出当前调用栈。这意味着无论那一时刻程序在做什么，很明显调用栈的底部发生了错误。 +现在，如果你的 Python 程序出现了错误，接收器会帮你打印出当前调用栈。这意味着无论那一时刻程序在做什么，很明显错误发生在调用栈的底部。 ### 3. 始终先检查 stack 的底部 @@ -86,9 +87,9 @@ Pdb, 一个 Python 调试器。 ### 7. 寻求帮助 -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. +我经常发现写下所以信息会引发我对还没尝试过的东西的思考。当然，有时候我在点击提交按钮后立刻意识到问题是是什么。无论如何，当你在写下所有东西仍一无所获，那就试着向他人发邮件。首先是你的同事或者其他参与你的项目的人，然后是项目的邮件列表。不要害怕向人求助。大多数人都是友善和乐于助人的，我发现在 Python 社区里尤其如此。 -Maria McKinley 将在 [PyCascades 2019][4] 发表[代码查错][3]，二月 23-24，西雅图。 +Maria McKinley 将在 [PyCascades 2019][4] 发表[代码查错][3]，二月 23-24，于西雅图。 -------------------------------------------------------------------------------- @@ -96,7 +97,7 @@ via: https://opensource.com/article/19/2/steps-hunting-code-python-bugs 作者：[Maria Mckinley][a] 选题：[lujun9972][b] -译者：[译者ID](https://github.com/译者ID) +译者：[LazyWolfLin](https://github.com/LazyWolfLin) 校对：[校对者ID](https://github.com/校对者ID) 本文由 [LCTT](https://github.com/LCTT/TranslateProject) 原创编译，[Linux中国](https://linux.cn/) 荣誉推出 From adb60499d7f8a9ef314b81c6f877c0b11ed6a13b Mon Sep 17 00:00:00 2001 From: LazyWolf Lin Date: Thu, 7 Mar 2019 13:11:55 +0800 Subject: [PATCH 13/14] Delete 20190208 7 steps for hunting down Python code bugs.md --- ...steps for hunting down Python code bugs.md | 114 ------------------ 1 file changed, 114 deletions(-) delete mode 100644 sources/tech/20190208 7 steps for hunting down Python code bugs.md diff --git a/sources/tech/20190208 7 steps for hunting down Python code bugs.md b/sources/tech/20190208 7 steps for hunting down Python code bugs.md deleted file mode 100644 index 77b2c802a0..0000000000 --- a/sources/tech/20190208 7 steps for hunting down Python code bugs.md +++ /dev/null @@ -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. -![](https://opensource.com/sites/default/files/styles/image-full-size/public/lead-images/bug-insect-butterfly-diversity-inclusion-2.png?itok=TcC9eews) - -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/ From bb7af13016aa53733a6e17d92b0a59bd7d135bca Mon Sep 17 00:00:00 2001 From: LazyWolf Lin Date: Thu, 7 Mar 2019 13:29:39 +0800 Subject: [PATCH 14/14] Check translation of 7 steps for hunting down Python code bugs. --- ...08 7 steps for hunting down Python code bugs.md | 14 +++++++------- 1 file changed, 7 insertions(+), 7 deletions(-) diff --git a/translated/tech/20190208 7 steps for hunting down Python code bugs.md b/translated/tech/20190208 7 steps for hunting down Python code bugs.md index 04d302964c..5f280ae17c 100644 --- a/translated/tech/20190208 7 steps for hunting down Python code bugs.md +++ b/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，于西雅图。