So, I started learning to code in Python and later Django. The first times it was hard looking at tracebacks and actually figure out what I did wrong and where the syntax error was. Some time has passed now and some way along the way, I guess I got a routine in debugging my Django code. As this was done early in my coding experience, I sat down and wondered if how I was doing this was ineffective and could be done faster. I usually manage to find and correct the bugs in my code, but I wonder if I should be doing it faster?
我通常只使用Django启用时提供的调试信息。当事情确实像我想象的那样结束时，我用一个语法错误破坏了代码流，并查看流中那个点的变量，以找出代码在哪里做了与我想要的不同的事情。
但这种情况还能改善吗?是否有一些更好的工具或方法来调试Django代码?
有很多方法可以做到这一点，但最直接的是简单
使用Python调试器。只需在Django视图函数中添加如下一行:
import pdb; pdb.set_trace()
or
breakpoint() #from Python3.7
如果您试图在浏览器中加载该页，浏览器将挂起，并提示您对实际执行的代码进行调试。
但是也有其他的选择(我不推荐):
* return HttpResponse({variable to inspect})
* print {variable to inspect}
* raise Exception({variable to inspect})
但是对于所有类型的Python代码，强烈推荐使用Python调试器(pdb)。如果您已经开始使用pdb，那么您还需要了解使用ipython进行调试的IPDB。
对pdb有一些更有用的扩展
pdb++，由Antash建议。
pudb，由PatDuJour建议。
在Django中使用Python调试器，由Seafangs建议。
从我的角度来看，我们可以将常见的代码调试任务分解为三种不同的使用模式:
Something has raised an exception: runserver_plus' Werkzeug debugger to the rescue. The ability to run custom code at all the trace levels is a killer. And if you're completely stuck, you can create a Gist to share with just a click.
Page is rendered, but the result is wrong: again, Werkzeug rocks. To make a breakpoint in code, just type assert False in the place you want to stop at.
Code works wrong, but the quick look doesn't help. Most probably, an algorithmic problem. Sigh. Then I usually fire up a console debugger PuDB: import pudb; pudb.set_trace(). The main advantage over [i]pdb is that PuDB (while looking as you're in 80's) makes setting custom watch expressions a breeze. And debugging a bunch of nested loops is much simpler with a GUI.
啊，是的，模板的问题。最常见的问题(对我和我的同事来说)是错误的上下文:要么你没有变量，要么你的变量没有某些属性。如果你正在使用调试工具栏，只检查“模板”部分的上下文，或者，如果这还不够，在你的上下文填充后，在视图的代码中设置一个断点。
就这样。
正如在其他文章中提到的，在你的代码中设置断点，然后遍历代码，看看它是否像你预期的那样运行，这是学习像Django这样的东西的好方法，直到你对它的所有行为以及你的代码在做什么有很好的感觉。
要做到这一点，我建议使用WingIde。就像其他提到的ide一样，很好很容易使用，布局很好，也很容易设置断点，计算/修改堆栈等。完美的可视化你的代码正在做什么，因为你逐步通过它。我是它的超级粉丝。
我还使用PyCharm——它有出色的静态代码分析，有时可以帮助你在意识到问题之前发现问题。
如前所述，django-debug-toolbar是必不可少的- https://github.com/django-debug-toolbar/django-debug-toolbar
虽然不是一个明确的调试或分析工具，但我最喜欢的一个是SQL打印中间件，可以从Django Snippets (https://djangosnippets.org/snippets/290/)上获得
这将显示视图生成的SQL查询。这将使您很好地了解ORM正在做什么，以及您的查询是否有效，或者您是否需要重做代码(或添加缓存)。
我发现它对于在开发和调试应用程序时监视查询性能非常有用。
还有一个技巧——我为自己的使用对它进行了稍微修改，只显示摘要而不显示SQL语句....所以我总是在开发和测试时使用它。我还补充说，如果len(connection.queries)大于预定义的阈值，它会显示一个额外的警告。
然后，如果我发现发生了一些不好的事情(从性能或查询数量的角度来看)，我会返回SQL语句的完整显示，以查看到底发生了什么。当你与多个开发人员一起开发一个大型Django项目时，这非常方便。
